Join us as we gather around the hedge,
where we dig into technology,
business, and culture with the finest minds in
computer networking.
Well, hello, Tom.
Hey, Aris. It's been a while.
The plant
have you been turning the plant? It looks
more even.
I think my wife's been turning the plant.
Oh, because it does look more even. That's
a good thing. Yeah. Basically, if it looks
good, it's her. If it looks like it's
in need of help, it's probably me.
So
we missed a couple of recordings and
stuff like that because I've been out of
pocket for three weeks, and I need to,
like, actually start editing and publishing again because
we have, you know, I haven't published
an an episode in three weeks now.
So as we record this, there's a few
episodes in the backlog that need to be
recorded
or edited and posted,
and I need to find more people to
record. I almost just told George was gonna
record once a week.
You're dropping that on me like, that's just
a thing.
Fine. Let's do three now.
Let's do three now. It'll be fine. So
we're being joined by George
Michaelson,
and he is upside down. You can't see
it, but he is. Yep.
He is. He's hanging from the ceiling having
fun. It's lovely to be here again, Ross.
Nice to see you eating Tom again.
And the plant.
Don't forget the plant. The plant's gonna feel
bad.
Yeah.
That's that's the important thing.
Alright. So, George, how are you? Everything okay
in Australia?
Yeah. Things are going alright.
We've got a bit of flooding going on
down in New South Wales, and that's a
heavy trip. But you know what? That's what
goes on in this part of the world.
But it's a lovely time of year here
for me. It's just beautiful outside, and things
are buttering along as normal. All is good.
So it's fun. When it's fun. When it
floods in Australia, does the water swirl the
other way?
Yeah.
We're kind of busy dealing with rescuing people
off their ruins. There's not really a lot
of time to,
experiment
with that. And I think that underlying
force of coralis is perhaps
overlaid with more dominant forces that have directional
qualities.
So
wouldn't wanna wouldn't wanna argue the case strongly.
It actually flows up towards the sky time.
The rain comes from the ground
Yep.
Because they're upside down. Anyway
Velcro was invented for a reason.
So, George,
let's talk about Deleg. What is it's d
e l e g. Right? It is. So
look.
We can just say it's the DNS, and
we're out of here. Right? I mean, the
DNS is crazy. It's crazy.
Normal life, you wanna fix something, you pull
off the side of the road, you get
the jack out, you jack up the car,
you fix the tire, you put the car
the jack away, you drive off again. It's
cool. DNS,
you don't stop. We're tinkering with this machine
while we're running the baby.
DAG is
So so DNS has gone from being NP
hard
to NP complete.
Oh, you can calculate in the DNS for
sure.
I mean, it's it's crazy town.
But the thing is,
we feel like we could do better.
And it would be lovely if we could
move into the house next door and do
some work and kind of expand a bit.
And people for a long time have been
thinking of a number of different qualities in
DNS
they'd like to explore and do different.
And the problem
is how do you retrofit
all this new technology
into a system that is so fundamental? It's
one of the three critical legs that drives
the internet properly, the most important one. And
Delek
is an attempt to spin up
a way of changing
one,
pretty much one,
critical component of behavior in the DNS,
which has lots and lots and lots of
downstream consequences. And it's kind of fun.
Okay. So
what can you describe, like, what you're trying
to do to DNS?
What are you trying to do, George?
Make it
a joint.
A joint.
No.
That's actually not what we're trying to do.
So you got to understand
two things that we're gonna be talking about.
And one of them is domains
and the concept of encompassing
domains,
and the other
is distributed.
So let's start with domains.
DNS names,
the d part is domain,
Domain name system.
Fully qualified
domain
name. Yep. Sorry.
D, domain.
You gotta think the lion king is is
being held up in the sky, and his
daddy lion is saying, see all those lands
down there, son? That's all ours. That encompassing
behavior in the lion king, all the things
that are yours, that's your domain.
Right?
So in a domain name,
it's working
right
biggest thing to left
most local thing.
So if we're talking about
www.foo.com,
the biggest thing here is .com. It's the
domain of all names that end
in .com.
And the next biggest thing is
food.com.
It's the domain of all things that have
food.com
at the end. And www,
the very last bit, which we could say
was the terminal bit, it's the smallest itty
bitty bit. But the thing is, you kind
of need to understand
how do I find
who knows
all the information
at any given point?
So in a domain model,
it starts at the top.
So say I wanna
find www.foo.com.
I've got to know howtofind.com,
and somebody has to be able to tell
me, okay. Here's how you find.com.
That gap of asking the question, who knows
about,
and being told, here are the people who
know about it, that is
delegation.
The know about it is
I'm delegated
to tell you everything about
that bubble of stuff.
So
.com is
delegated
from the root, and the people who run
.com
have
systems that are called name servers, and they
are absolutely
the ground truth authority
for everything that is in .com.
And when you go to one of those
name servers and say, hey .com name servers,
can you tell me who's got foo?
They have to do a lookup in a
system,
find the name servers for foo, and say,
sure. Here are the list of name servers
we've been told about who can tell you
about foo.
And then you go, thanks. Bye. And you
go and ask those name servers, hey, nameserversforfood.com.
Can you tell me about www.food.com?
And they have to go, why sure. That's
us. We can tell you that. We know
exactly how to tell you that. Job done.
Okay.
Building blocks, simple pieces,
had to ask a lot of questions.
There's like three, four sets of questions being
asked here. But the thing is, that's how
DNS has worked
for centuries
and centuries since DNS was invented in 1762
in a small island off the coast of
France. I actually think you're wrong. That's how
it works. I think you're wrong. I think
it was invented by the Egyptians. I think
there are Egyptian hieroglyphs.
Yeah. That say this is my DNS server.
Yes. Yes.
So
couple of things come to the surface when
you start talking about this.
The first thing is,
gee, the DNS is funny.
And so this quality of what is my
name server,
you're asking the people one level above you.
We often use
hierarchies
in family sense. So we might say grandfather,
father, son, or grandmother, mother, daughter.
You have to ask the grandfather
to be told the name servers for
the for the father, and you ask the
father for the name servers for the son.
You have to start at the top.
But
if you happen to know
the name servers for the father, and you
go, hey, dad. What are your list of
name servers for your son?
They can tell you
different things.
They could tell you one thing or two
thing or three things or 10 things.
And if you go to the sun and
say, are these your name servers?
The sun could say, oh, yeah, but I've
got 20 other ones I didn't tell my
dad about.
You can have a disconnect
between what the top down path says, other
set of things, and what the child itself
knows, other set of things that know about
it. So this is where
distribution comes to the table.
Everybody loves to think it's easy to make
something run better by splitting it in two
and having two of them. And, you know,
if all you're doing is sending out static
information,
gee, it's a wonderful world. You've got twice
as many things to give the answers. What
happens when people start changing things?
Is one of them authoritative, or is both
of them authoritative?
And if they, for some reason, can't talk
to each other, what happens if you change
one and you don't change the other? So
why
would
an authoritative
server
or yeah. Why would an authoritative
server
have a different
set or
I guess this would be authoritative servers.
Yeah. Yeah. Have a different set Introduce introduce
the word there. Authoritative.
Yes. Authoritative server have a different set
of authoritative
answers
than or places you could go to get
an authoritative
answer
than,
say, the TLD
server does. Okay.
So, Tom, do you ever use
a post office box somewhere? You ever used
a service like DHL?
Sure. Sure.
So
you've got a real address. Right? Mhmm.
And you tell that real address to some
people, don't you? Right.
But you tell some people if they wanna
ship stuff to you to send it to
PO Box 59 at the local DHL office.
Sure.
And sometimes you use FedEx because some people
ship you stuff where they do a better
job. So you tell them to use PO
Box 692 of FedEx, don't you?
Sure.
So do you tell FedEx the PO box
number at DHL?
No.
So right off the bat, there are reasons
why people segment information they share about themselves
and pass out into the world. So
when you come into existence as a DNS
name, oh, I bless thee as a DNS
name existing in the global DNS system.
How do you do that?
You do that by going outside the DNS
and doing two important transactions.
Transaction number one, you hand over some dinero
because nothing happens in the DNS these days
without small payments of money to people who
provide commercial services to do things in the
DNS.
And number two, you tell them the name
servers that you want them to publish
design DNS,
the magic record
that actually says I am a zone under
this other thing,
that is legally
where those name servers reside. The list of
things that are the name servers live in
there.
So
you would think that we're all really good
people, and every time we change those name
servers and add another five or six, we're
going to tell our parent up in the
place that delegates down to us. People don't
do that.
They told them to. And as long as
you don't change those two, those two will
direct people down.
But this is a huge worldwide distributed systems.
And people acquire knowledge that then gets caged
in the other half of the deal, not
the part which is about delegating down, the
part which is about serving it out into
the world. And those people, the global public
resolvers and the caching resolver systems,
they sometimes walk into you and say, hey.
What's your list of name servers? And you
go a, b, c, d, e, f, g.
But you don't give them all because,
first of all, you're load balancing things, and
you're controlling
geographically
where they enter your network, for instance. You
right. So you're telling people answers based on
qualities that are coming at you to try
and optimize their experience.
And what you just said five paragraphs ago
in this monologue is,
how come there's a difference here? Well, the
difference is that you don't want to be
telling your parent
all of these changes that you're having to
make. They're operational changes in you. Now there's
another story here, which I haven't brought to
the table,
outsourcing.
You're my parent, Russ. Hi, dad. And you're
delegating a name to me. Well, I haven't
got time to run it over here in
Australia. I'm hanging on to the ceiling for
dear life. I pass the job off to
Tom.
So Tom's gonna do all the service delivery
for me. Now remember, I'm the child. I'm
the one who has authority to tell you
things are gonna change here. Tom's the guy
who's actually charged with doing it. And I
said to him, I'll give you a lot
of money to make it efficient in Europe
and Asia and the Pacific Islands and Antarctica.
You work out how to do that. And
he's now looking at my domain going, holy
gee. I've gotta get a lot of changes
going on here. So he comes back to
me and says, could I have that magic
token that lets you change data in your
parent, Russ?
Well, this is a real moment, Russ, because
that magic token doesn't have degrees of freedom.
It's an all or nothing token.
If I give that token to Tom, he
can change everything about me,
every single thing, because we didn't design this
system to intrude third parties into the machine.
There isn't a limited permit token to let
him modify only the thing he needs to
modify. Tom, can I trust you?
Of course.
Yeah. But you don't tell DHL the things
you tell FedEx, so I'm kind of feeling
like you're less trustable than I want here.
You see what I mean, Russ? We've we've
taken a simple system, parent, child, delegate, record,
and we've started to say, oh, the parent
needs to know to delegate, but the info's
in the child. And then we've done, oh,
the child needs a third party to manage
it. Oh, we haven't designed how to make
third parties run that system. We've added a
lot of complicated corners.
So so what we've done is taken what
was effectively in the first place, a unidirectional
database distribution system,
made it bidirectional,
and now almost omnidirectional
in all sides. And along the way, we
forgot that the cap theorem exist.
Yep.
So it's time for a reset.
And there's a couple of different things that
have come into play.
The first one, for me at least, other
people might say the other one is more
important. But for me, the first one is
this primary question. How do I find delegation?
And this bi facing problem, the parent has
to know, but the child has the authority.
We're about to swing this round and say
the authority vests in the child to say
it, but the record about it is solely
gonna exist in the parent. This Del egg
record
is no longer going to be magically in
the child,
but held by the parent. It's gonna be
held in the parent.
So the parent holds it, but only the
child is allowed to modify it? It's a
property of the child, and those qualities of
modification
are going to have to be defined.
So most things about a zone
are attributes that are stored in the zone
and therefore are functionally
contained in the zone and can be defined
by the holder of the zone. And the
Delleg record is going to be about the
zone, but it's going to be in the
parent.
You are right to say, how does that
work?
And that's why there's going to be a
lot of standards documents. Right? So none of
this would kind of matter if we were
talking a simple world of simple DNS. But
when you come to DNSSEC,
there's an additional burden here. Cryptographic
signing over data
has to come top down in this model.
That's the way the world works. The NS
records
that are about
the child,
okay, if they're contained in the child,
as they currently legally are, the only person
who can sign them is the child.
But in order for them to exist, they
have to be in the parent using a
horrible mechanism we call
glue.
Glue,
which is where you tell the parent something
and they just glue it into their mind
and know it. And it's about something else,
but it's not. It's kind of like the
hack to bootstrap things.
Delek, because it's going to be defined as
being in the parent, it's kind of losing
this weird property,
and the parent's going to be able to
sign over it. Currently,
the NSs, the name servers that are the
authority for a child, the parent can't sign
over them because they're magical glue. They have
to be signed by the child, and it
breaks the trust regime. And moving it means
they can be trusted.
Yeah. So today, glue lives as a text
record
Yeah. In your a, right, or your quad
a?
It has no existence in the DNS in
any strict formal sense. It's a magic extra
piece that comes along for the ride and
has all kinds of weird, horrible behaviors polluting
the system.
Hey, Russ. You're my parent. Here's my n
s's. Oh, I'm gonna store that as glue.
So now when questions come in, you go,
here is George. Here's the authoritative
statement of George. Here's some info that's gonna
help you. That's the glue. And I'm going,
can I trust that info?
And you go,
oh, George told it to me, but I
can't sign it.
It's not mine to say if it's true
or not. With Delag, you're gonna be able
to say, yeah. I know this is true.
I sign over it. Believe me when I
tell you.
Interesting. So,
yeah, in the past, blue records have always
been a text thing. Right? They're just part
of a some text record. You do a
search. You pop back a text
a text record for the FQDN,
and you say, what's in that text record?
Well, it could be anything because it's a
text record. It could be anything
at all.
That was the way that we managed to
jam new behaviors into a system like DNS.
Right. So It was an opaque LSA in
in OSPF.
So
new jargon.
Yes. We love jargon. So comes the second
thing.
Tom,
when you're using
DHL,
do you like to have an electric truck
deliver that package?
I don't care
myself. Oh, man. Come on. Be kind to
the environment.
Sure. Sure. Electric.
Okay. So if you wanna stipulate it's an
electric truck doing the job, you need a
way to tell people, we like you to
use the electric truck. Right? I mean, what's
the point in paying for batteries if you
don't push people there? FedEx, who are stuck
on diesel, you need a way to say,
well, it exists and you can use FedEx
with me, but I'd really prefer you use
the electric truck. One day, FedEx gets an
electric truck. So you then have to be
able to say, hey. Wonderful world, guys.
Everything in my life is electric. You wanna
ship me packages? Use the electric truck method.
Transport. Is it transported on electric truck, or
is it transported on a diesel truck?
DNS has a transport problem. Right now, DNS
is using this wonderful protocol called UDP,
and UDP,
the protocol, has some amazing properties.
It's
dumbass stupid.
And if it drops stuff on the floor,
nobody knows because it's not keeping count on
what's going on here. Oh, and to make
things more confusing, if UDP fails,
most the DNS implementations will switch to TCP.
Yeah. To do follow ups. So now you
have not a single protocol, but you have,
like, this fallback thing
that's
confusing.
Is that Russ but, Russ, if I can
twist the meme, porque no los tres,
because we not only have TCP,
but we have QUIC, which is UDP,
but with a bit of TCP session and
with privacy. And we have DNS over HTTP,
which goes on to the wonderful acronym of
DOL.
The Homer Simpson protocol of names. DOL.
So because we've now got DNS over HTTP,
DNS over TCP, DNS over TLS, DNS over
QUIC, DNS over UDP, five, count
them, five ways of doing DNS.
Wouldn't it be nice if we had a
way to say which one we really want
to use? Wouldn't that be cool?
Electric trucks, Tom. You gotta get with the
electric trucks.
And the right answer is what?
Is the right answer quick?
That is a wonderfully subjective
question.
Okay?
So the right answer in classic Internet form
is
meta.
We're not gonna tell you which one is
right, but we're going to construct
all the artifice of beauty, the coruscating
beauty
of a defined way to say,
if there is a right one, you're going
to know what it is.
You're going to know all the magic properties.
You're going to be able to ask
one simple question. Hey, Russ.
How do I find George? And you are
going to give me back the Whitaker's
almanac
of information
about the various ways George can be found
in one lump, and you're gonna say to
me, you work it
out. So so in this case,
Delek also includes the ability to select a
transport is what you're saying. It goes beyond
the text record and the glue,
and it gives you transport. Okay.
And
it intrudes
mechanistic
ways to say,
from here on in,
George has given authority to Tom
to do all the things that relate to
provision of service in naming.
Geographic
specific location,
outsourcing, all of those behaviors
now vest with Tom, and here is a
signature
that proves
Tom is entitled to say these things. Now
is this going to be more fine grained
than everything?
Because everything seems like a problem.
Well,
I kind of wanna say maybe, and I
kind of wanna say I think you could
be wrong here, Russ.
And I'll start with I think you could
be wrong here, Russ. You know TLS. Right?
Transport layer security. Yeah. Mhmm.
It's a dance.
It's a dance that means we have to
sniff each other a bit like dogs out
for a walk and work out which thing
we trust and which thing we wanna use
and then go into a magic new state
where everything's private between us because humans don't
do scent and we're speaking dog scent language.
That exchange involves a lot of backwards and
forwards. That is the best explanation of TLS
I've ever heard. Anyway I have a
I have a picture in my mind, but
I'm not going to try and draw it.
So the thing is the thing is, Russ,
there's a shortcut where instead of doing the
dance, you can preload certain stuff. It's kind
of close to what we call zero RTT.
If I give you a whole bunch of
the data that I know you're gonna need
three steps ahead in this chess game,
you can get there so much more quickly.
That's why this blob is growing big because
giving people a lot of information in one
go is absolutely more complex. And I can
see why you're saying, do we really wanna
do that? But everything
everything in the modern Internet is about saving
time,
shaving time. And if I don't tell you
questions, I can foresee you're gonna ask me.
If I don't give you the answer now,
you have to ask the question.
I take something that could have been done
in you using your CPU,
and I turn it into a stretch of
time until you work out you need to
ask me. Why don't I just give it
to you now? And then when you think,
oh, I need to know that extra information
to bootstrap TLS,
it was in the Delek block.
So
this complexity
isn't necessarily
about DNS.
It's about the downstream
consequences
of the things that are going to happen.
So I wanted the outsource, and I wanted
Tom to be able to do the direct
answering,
but I needed to give Tom the certification
chain information
so that Tom could then say when he
gives the DNS name that is actually the
website for me, hey, dude. Here's the blob
of info that will let you bootstrap that
TLS session,
one packet exchange.
I can do that without having to give
Tom the keys to the kingdom.
Tom can't remake certificates in me. Tom can't
change my delegation.
Tom can't steal my business and give it
to a third party because I can do
limited permits
of the bits of stuff I need Tom
to know to do this.
Okay. So so it is more fine grained
than everything?
It can be because it's a structured block.
It's it's likely to be some denoted structure
like JSON or some other possible structure.
And it's likely that people will be looking
at it going, hey. My role's DNS. I'm
focusing on this bit.
And other people will go, DNS did its
thing. I'm looking for the TLS bootstrap record.
And other people are going, I'm the outsource
agent. Where's my permit token to let me
do downstream things? People are gonna take different
qualities from it.
But the truly lovely thing is that it's
going to all be capable of being signed,
which means the trust component,
which couldn't be done because of jumping over
this gap,
because of the fact that DNS uses name
servers that have to live in the child
but have to exist in the parent and
glue,
we got rid of that problem.
That's cool.
Okay. So I have I have a sort
of a forward looking question.
I remember a a while ago, it was
a long time ago, the maximum message size
for BGP was increased to something huge.
And at the time, I remember thinking if
I had some time, I would I would
write and I would create an address family
just grab f r r and create an
address family for for jpegs and put a
photo in there and make a photo album
on BGP just for you know just for
giggles
and
you know it was just sort of silly.
So my question for you is what
what what do you foresee as some of
the,
ridiculous things that people will do once delegates
in place? What kinds of, what kinds of
novel let's call them novel use cases.
Secondary things you never thought of.
So I do have a couple of thoughts
there. The first one is that there's this
constant battle over shorter is better and longer
is easier to delegate.
I mean, in reality, there are there's only
three domains,
dubdubdub.google.com,
dubdubdub.akamai.com.
I mean,
names in some ways are actually tending to
get a lot shorter.
You go look at the name that you
wind up on, and you suddenly magically see
that the intrusion of the third party,
your real name that you're really living under
that's really serving this, it's not actually a
pretty name anymore. It's a hash string.
And so I think one of the things
that's probably gonna happen here is that there
won't be
a huge amount of DNS happening anymore because
deleg is gonna be used to say, oh,
man. This name stuff is just crazy. Can
we move the whole thing to a different
universe?
And I think it's likely that having fetched
the Delek record, there is no DNS
afterward.
There's something else.
And do you know what I think that
something else is?
Hosts.
Text.
No.
Seriously.
I think that the Delek record is gonna
say for the purposes of all future conversations
involving you and this domain name, here is
the pre sorted list of names that you
will ever need to look for and the
addresses that you should expect to use.
I think people are gonna be given an
entire blob of all of the advertising domain
name feeds, all of the image farm domain
name feeds, that special cache of Google for
the font that they use on their web
page. Every one of those things right now,
you have to go out and do a
third party DNS to resolve that to draw
the web page.
I think we're gonna give people
all of that magic info
inside a block of data you get through
a Delek mechanism.
Which is gonna make it infinitely harder to
troubleshoot
problems.
It's gonna make it horrible if you're the
person trying to say,
oh, this part of the web page is
slow and that part is fast in this
application.
I'm sorry. So can you send me the
Delek record that you specifically
fetched?
Yeah. Not anyone else.
That's gonna be terrible.
So so that's the first part. The second
part is that this whole dance
around
authoritar,
who has the authoritar
to register things.
Register
isn't a word that exists in DNS. Right?
Register is a word that was invented in
this public management space,
which we call
registry.
There's a place that is the registry, and
they run a machine,
steam engine, that pumps out a zone file,
and you change who is records in registry,
and they run over them to do that.
And that registry
is like where all the public interest stuff
is. What is your real name? What is
your real address?
What is the carrying capacity of a swallow
in summer?
You know, these questions are solved in registry.
And I have a feeling
a side effect of Deleg is that an
awful lot of this stuff won't exist in
registry anymore, because who needs a registry?
Yeah. It's gonna happen in band
in DNS or whatever is the bigger thing,
and it's going to say, no. We don't
do registry here, guys. That's crude stuff.
Because after all, it isn't me running it.
Right? It's Tom running it. And I didn't
want Tom owning my registry entry.
He's out of the loop. Once you give
people an opaque LSA,
in fact,
I think what then happens OSPF
speaker. Yes.
Is
that people make up their own proprietary records
to make their services faster.
And then it's it's an opaque
Yeah.
Delag So
filled with JSON blobs that no one else
knows how to interpret. So
I might be sounding happy happy joy joy,
but you are right to say there are
many risks to the public commons here, Russ.
There are. We could make some really bad
mistakes here.
We gotta think about this.
Yeah. That this this actually worries me a
little. So r is the format you're speaking
as though
Delek,
the signature bits of it are already defined,
but the format itself
is not. You're talking about JSON blobs or
whatever.
So we're now entering we're now entering this
wonderful world where I'm going to struggle with
one acronym because there's a magic acronym that's
existed for a very long time.
Akamai, who are in the business of being
intermediaries
supplying service to people,
discovered
an interesting quirk in DNS that could be
fixed, and they and a number of other
people developed this thing called
s v
c
b,
service
something
binding, service binding,
SV for service
binding records,
SVcb.
And they've been out there for a long
time, and they already have
structural semantics to say, oh, this is how
we do indirect referencing.
Yeah. You need to say something and you
want to alias it. Okay. We're gonna do
that over here. So Google and Akamai worked
on that spec with a bunch of people
in DNS.
Delek is going, we're not reinventing the world
here, guys. We're gonna construct a variant of
the SVCB
record and call it a Delek record, but
it is going to look
structurally
like SVCB.
Interesting.
So that that is pre JSON, so I
assume it won't be a JSON blob.
Well,
I mean, come on.
Once we're in a world where you've got
a large
field and you're broken free of constraints and
people put ideas on the table, JSON is
base 64. It's just a text record, man.
It's just x. It's all bits, man.
I mean, I wouldn't say it's not gonna
be JSON. What do I know?
This is I I have the feeling
this is gonna be like ADA.
When when I was in the air force,
we had all these projects that were tossed
at us
that were ADA projects. Because because the department
of Defense, you know, US Department of Defense
said, thou shalt use ADA. Thou shalt not
use yeah. Thou shalt not use,
IP, you know, just like thou shalt use
IP v six. And so in both those
situations, what we got most of our proposals
were
I p v four mapped into I p
v six address space,
and that was
I p v six. And then Yes. You
you you look at the source code for
something that's been proposed in ADA, and it's
like pound to find c.
And the rest of the program is in
c,
and at the end of it, it's pound
to find ADA.
But they did it in ADA. It compiles
in an ADA compiler.
Yeah. Oh, totally legal ada. Totally. It's like
the a it's like the ASM
construct in c. I mean, inside the c,
you do stuff that, you know, the machine
code, you put ASM and you write the
machine code, and you've done it in machine
code. I mean You're not machine code, but
it's in c.
But it's c. Right? Ted? You you should
go look. Anyone listening to this should go
look for a story that's resurfaced
Edgar
Dijkstra's
comments on every single one of the ADA
candidate languages,
because he was in the review committee. And
there were four candidates. They were named for
different colors,
blue, green, red, orange, whatever. And for every
one of them, he's like, I wouldn't use
this language to butter my toast. This language
has been designed by a hedgehog. This language
is totally useless. It's it's insanely
bad. I never want to see anything implemented
in this language. You know, if this language
is a safety language, I'm not getting on
an airplane written with this language.
So
we should we should repurpose that for DNS.
If you think this is DNS, you need
to go somewhere else because this is not
DNS anymore.
Oh,
this is always the danger with opaque
data.
Just and this is this is what happened
with address families in BGP too. Oh, it's
we treat address families like opaque data, and
we just shove whatever we want to in
them. No. That's not. So There is a
method. Yeah. No.
So the thing is we are at very
early stages. Right? I mean, the IETF is
a machine that grinds exceedingly
fine, but it grinds exceedingly
slow. So
the Delek working group has only just bootstrapped,
and it's only just got its marching orders,
and it has the base camp definitions, what
problems
are we trying to solve. So people have
leaped ahead, and they've put candidate models in
the air.
It's early
days. Who knows what will come out the
door on the other side? Okay. So there's
a part of this, which is we kind
of leaped ahead of the real story.
The second thing is the real problem exists.
I mean, it is a real problem
that we don't have signed authority
over mechanisms to do things. And Port 53
has had so many things jammed in it,
intruding a bubble to say,
can we just do this slightly differently
high in the system?
That's a really good idea.
But do you remember I said that we're
not driving off the side of the road
and putting the jack on to lift the
wheel off, that we're changing the engine while
the car's still in motion?
Well, we have to continue
to support
the existing delegation
mechanisms while we're proposing the Delek record, which
means we're also having to bolt into this.
Oh, yeah. Here is where the bit of
information is gonna live that you need to
know to do it old school. We're actually
gonna have to bring the past with us
in the basement of the new house.
So this this reminds me of quit in
many ways.
This really does. It it's Yeah. It's and
like I said before, like, address families in
BGP,
like,
we create
this thing,
and then we transfer all the because because
the base protocol is so complex,
we transfer all the functionality
of the base protocol
into this sub piece of the base protocol
itself
because it can be simpler because we're starting
over. And in the end, it actually doesn't
turn out to be simpler. In five years,
that little base piece becomes
just as
complex. And and then just like, you know,
you said 53, like,
everything is over, like, five ports in the
Internet now.
Yeah. Well, we're just about to say one
of those ports. We might be pointing it
back into some of the other four because
it's going to be if you wanna know
about me, go ask someone using Quik over
here.
Yeah. Yeah. That's and that's yeah. That's
wow. Okay.
So
the glue that holds the Internet together just
became
well, whatever.
But there was
but but, Russ, there was never one kind
of glue. You wanna fix it at the
sole of a shoe, you need a flexible
glue. You're banging wood together, you need a
rigid case in glue. You're gluing glass to
concrete, you need a glue that works for
that context. There were always
many kinds of glue. So the glue that
holds the Internet together, yeah, it was originally
one kind of glue, but we don't boil
horses' hooves to make that glue anymore.
We're baking glue a different way.
Wow. Okay. Another interesting illustration.
Yeah. There's a very fine British jazz musician
called Lowell Coxhill, and he has a monologue
on one of his jazz records where he
talks about his prior life. And before he
became a jazz saxophonist,
he had the job
throwing dead cow's hooves into the crushing machine
for a glue factory.
And I've always thought that's quite an odd
monologue to intrude into a laid back jazz
album. But,
you
know, jazz. Welcome to late night radio DNS
jazz.
I may have to ask you for that
name again so I can anyway. Alright. So
yeah. So okay. So this is where we
are with it. This is what's going on.
This is what we're trying to get to.
We're trying to get to a world that
reflects the reality of complexities in modern Internet
practice.
Okay.
Interesting.
So
I kinda think we've beat this poor little
horse dead, and somebody's gonna take its screws
and make glue out of me now. Glue?
Yeah.
DHL's gonna be ringing me up asking for
Tom's address so they can ask him why
he's using FedEx.
Yeah. Exactly.
So alright. So this is really cool. If
people wanna keep up with this or get
involved in it, because it's early days. If
you wanna get involved in this message now
the ITF. Go to the ITF and search
for d e l e g, Del Ag
working group, where the foundation documents have just
been published,
and track people who are smarter than me,
who are gonna explain things a heck of
a lot better than I did. There is
a blog on APNIC that's talking about it
with Geoff Huston, and it's an interesting conversation
as well.
The design group that are involved in this,
they're all lovely, approachable people. It's a really
nice bunch of people. Good guys.
Okay.
Alright. Awesome. Tom, you have any more any
more questions? Or
No. Just a snarky,
when you were talking about, how we're gonna
troubleshoot this and people are like, well, I
don't know. So here's what we do. We
create another record type, call it a PCAP
record. And when there's a problem, it does
a packet capture of you on the host
and then sends that person in the DNS.
In the DNS.
There you go. Yes.
I'm sold. You can put patience on that
right now. Yeah. You you could put a
p cap,
address family in BGP too. There you go.
There you go. Both. Let's do both. Yeah.
Let's do both. Yeah.
Oh, wow. DNS over BGP and p cap
in BGP over p cap in DNS. Yeah.
Oh, yeah. Tunnels.
Tunnels.
I I see tunnels.
I see tunnels everywhere.
Everywhere, I see tunnels. Wow. Yeah. But now
Russ is never gonna ask me that question
again.
This has been really fun, Russ. Thanks for
having me come on and
tell people things.
Okay. Alright.
Let's see. George, where can people find you
if they want to find out more?
Just follow what you're working on? I know
you do the ping podcast.
Yep. If you go to blog.apnick.net,
you'll find everything I'm currently doing and pointers
to the more
I don't
know. I don't know. It can't be true.
He didn't start it with humbled.
Alright. So I'm Russ White. You can always
find me here at the hedge.
You can find me at rule eleven dot
tech.
You can find me on LinkedIn.
I do log in to x every now
and again, not very common. I really
social media, I have, like, a a a
love hate thing with of course, I did
my dissertation on social media, so that's that's
part of the reason that I have a
love hate thing with it. But anyway,
again, we know that attention we live in
an attention driven economy
and that you spending the time to listen
to this whole crazy conversation about Delek,
was good of you to listen to all
of this. Thank you for listening all the
way to the bitter end, and we will
catch you
next