Geoff Huston 0:00 Well, my point is, I suppose real control rests with the party that can undo it. Dot-net has a unilateral ability to erase potaroo. Just remove it from the zone file and it no longer exists as a name. I can't stop them from doing so, apart from via contracts. There's no other way. The protocol won't do it. The delegation structure won't do it. They have control of the fact that that label is a delegated label in their zone. George Michaelson 0:43 You're listening to ping, a podcast by APNIC discussing all things related to measuring the Internet. I'm your host. George Michaelson, I'm talking to Geoff Huston from APNIC labs again in his regular monthly spot on ping. This time, Geoff and I talked about the boundary between places in the DNS, the delegation zone cut point. If you look at a fully qualified DNS name or FQDN, every dot between words is a potential zone cut but where the actual zone boundaries lie isn't clear until you ask. Who do you ask? and who determines? clearly, given the nature of delegation, the answer to the question has to originate downwards from the root. After all, that's what delegation means, the authority to say what lies below you and where the boundaries are. The DNS Working Group in IETF has given birth to a new initiative and a newly chartered working group called DELEG, which is looking into this space and at the potential additions to the DNS to make the mechanism of delegation more trustable, more clear and more amenable to future protocol changes. Geoff, welcome back to ping. What should we talk about today? Geoff Huston 1:59 Well, thank you, George, and it's good to be back. You know, it's been an interesting few weeks. So lots of topics have come up, part of which is, of course, the never ending saga of v6 various themes. Why is it taking so long? You know? Why isn't this happening, or they're happening, etc. There's been, you know, bunch of topics about Internet governance and so on. But as usual, the one that's kind of taken up a lot of my time, and a lot of my sort of thinking has actually been your friend and mine, the name system, the DNS, George Michaelson 2:29 it's always the DNS Geoff. Geoff Huston 2:31 This is it. This is not only a popular meme, but it's true. You know, everything if you do on the Internet, is actually name related. And I suppose it makes sense in some ways, trading around hello, 2.3.4.5 Yes. How are you 57 Yeah, and so on. It just doesn't work, does it? George Michaelson 2:51 No, people want to have names. They want to have familiar handles, and they want scoping and zones and all these wonderful behaviors. Geoff Huston 2:58 It's a human thing. And quite frankly, it's important. And interestingly, it kind of pervades everything. The entire structure of am I talking are my packets going to where I meant them to go? Security, is based on names, not addresses, nothing else, but just the name. And when I do the little handshake and the lock comes up, that's all based on the fact that the people behind the name my-bank.com.au, have gone to someone who theoretically never lies and always, you know, tells the truth. George Michaelson 3:38 Yeah, I'm rolling my eyes at this point, but we'll go with it. We'll, we'll go with it for the time being. Geoff Huston 3:44 Yeah, no, but this is it's, it's a trust thing. Suspend all disbelief. They've gone to these ruthlessly honest people and say, I can show that I own my-bank.com.au, and they say, prove it. Put this little token in your DNS zone file I go, go find it. They go, Ah, you will put our token in your zone file that proves that you control that name. Good enough for me. I will counter sign your pri- your key pair, public, private key cryptography. I will counter sign that and issue a certificate to say, anything you do with your keys, I'll vouch for you. Now, it's kind of interesting, George, that I do something, and let's say I do it on April the first, and you have to trust me thereafter for many days into the future. It's kind of a do it once and trust in the future, which is a bizarre model of security. But there we go. George Michaelson 4:41 It comes with some behaviors that have recently undergone a bit of change in the community of people who issue certificates. Originally, when I was a systems administrator, the cost of doing this process to say, believe me, when I say, I am this company, please give me a cert. We all drove to here's your cert. It's valid. For a year. If you give me extra money, I'll make it valid for two years. And now we've gone completely the other way. And people say, Oh, I believe you are who you say you are, come back and get another cert in 20 days time, or 40 days time, or in the most extreme case, six days time. Come back and recertify in six days time. And it does make this question, why do we think we have to do that so often? Geoff Huston 5:28 Ah, let's say that my bank has gone through the process and got itself this certificate to say my private key is really cool. It's all about mybank.com.au. Key. Domain Name, solid relationship. Unfortunately, I wrote down my key on a piece of paper and screwed it up and threw it out into the street George Michaelson 5:52 where it was picked up by somebody Geoff Huston 5:54 picked up by a naughty person. And interestingly enough, if they get my private key, they can be me. They can, in effect, do a whole bunch of things in my name, because most of the security is based around keys, right? [George: Yeah]. Now I panic, of course, and a bit like a stolen credit card, I go straight to the certificate issue and say, revoke that key. And they go, why? Certainly, sir, we will add the Key Tag, the identity, the serial number of that certificate to our key revocation list. Wonderful. George Michaelson 6:28 Yeah, there's a problem coming, isn't there? Geoff, I'm about to hear the problem Geoff Huston 6:33 my trusty browser when it says, here's a key. That's the key for mybank.com.au, you you should trust it does not get given the rather large Certificate Revocation List, the list of all the bad certificates that that certificate issue is actually issued. I don't know if it's been revoked or not, [George: right] Oh, well, maybe you should go back and check with them. Okay, I could do that. But guess what? That list is only published about every week for most certificate authorities. So if I, if I did the bad thing this morning and threw out my key and it got compromised, the bad people have at least seven days to be as naughty as crazy, and nobody notices here, but it's worse than that, because most browsers, most users of certificates never check for revocation, [George: never] never. So if I have a three year certificate and no one's checking for revocation, not only can I be awfully bad, but I can awfully be awfully bad for an awfully long time. What's the compromise? Well, we tell the bad people. You've got 60 days to be as bad as you like, and then that's it. You kind of go, Is this any better than where we were? And the answer, yeah, well, that's their answer, yes, it's a lot better. Um, quite frankly, if you can't do a digital heist in about 45 minutes, you don't deserve to be a digital criminal. [George: Yeah] You know, the Amazon Bitcoin hijack took exactly 45 minutes, and that's pretty much par for the course. George Michaelson 8:07 Are we heading down to a world where certificate lifetimes might be as short as a day or less? I mean, if we've already hit 47 days because the CAB forum have decided to bring them back, and if Let's Encrypt are testing six is one day in the future, is one hour in the future? Geoff Huston 8:25 I didn't mean to go here George in this particular conversation, but it is a remarkably good story and an interesting story, because the more you want this kind of security to be an instant check immediately, the more you've got to spend time actually going and asking, you know, hi, certificate authority, do you still stand by this certificate now the certificate authority says, Well, I stand by it because a month ago, someone came along and showed me that they can control that name. Well, what about today? Oh, should I get them to do it again? And the answer kind of is, well, maybe you should George Michaelson 9:03 yeah, because the idea of every single web transaction requiring me to go and test is this certificate still okay? That's clogging up the system with a lot of traffic. Geoff Huston 9:13 Most certificate authorities could not cope with the traffic, because you are talking a massive black hole of just enormous numbers of queries. So yes, we have the online certificate status protocol, but it has kind of two problems. One, everybody, when they go and check online, is telling the CA that they using that certificate. Oops, huge privacy leak, [George: yeah] because my favorite spying agency says I want to be a CA, and then I'll know when everyone uses these sites, etc, etc, etc, not a good idea. Huge privacy leak. B, that's an awful lot of queries, and kind of, frankly, they're a CA, they're not even a service platform. Everything will melt, George Michaelson 9:54 yeah, but as you said, we're down in a hole that we didn't intend to be in because we. Going to talk about the DNS, although it does kind of relate, doesn't it? Geoff Huston 10:05 Well, it ends up relating and in a whole bunch of ways that are as usual on the Internet, kind of typical of the way we've cross related, cross made, cross dependencies in funny and typically undocumented ways. Now, when you get back down into what is the DNS? It's this massive distributed database. No one has managed to collect all the domain names and stash them somewhere. We don't even know how many domain names are out there. It's all just, ah, it's just a distributed database. So how many are there? Well, I don't know. I'm going to walk the entire DNS. Good luck. George Michaelson 10:48 There are parts of the DNS that don't want you to do that, and there are parts of the DNS that have wild cards that if you start walking in them, it's 63 characters of random string under that label to be tested to see if they exist. Geoff Huston 11:04 Well, they're also honey traps, where you dynamically generate answers. As long as you keep on asking me, I'll keep on telling you stuff, [George: yeah], and it's kind of well, how many times can you do that? Well, my computer can count to billions very quickly. So it's not a question that makes sense anymore. George Michaelson 11:19 And also it means that we are now irreversibly in a world where this is a distributed database. There's no single authority, there's no single point of all knowledge. Answering questions in the DNS necessarily requires people in the service provisioning side to go and ask questions. Where do I go to get the answer? And then go there to get the answer. It's just unavoidable, Geoff Huston 11:44 right? So you know, where do I go to get a bus ticket from Turin to Florence? And the answer really is not outside my door, because I'm in Australia, you need to be somewhere in Italy to go and do that, etc, etc. Now, what about the DNS? Where do you go to ask about my website, www.potaroo.net it's kind of well, ask your closest authoritative name server. The answer is, I have no idea, George Michaelson 12:11 authoritative name server. Now, that's an interesting term of art. There authoritative for what? Geoff Huston 12:19 that's okay, so this is the nature of the distributed database. You got to go all the data is everywhere. No, the data is somewhere, and there are a bunch of servers for that data. So how can I explain this? George, your name server is Fred, my name server is Jim, and so on. Every name is actually contained with a name server, and there might be a number of name servers for a particular name, but a priori, in advance, I have no idea which of the millions of possible name servers serve your name. George Michaelson 12:57 If we move from names to the idea of zones, we might be at a point where what we're saying is the central question of a zone is which name servers serve that zone, Geoff Huston 13:09 right? And one way is what we call flat name spaces, where I ask every name server who can tell me about www.potaroo.net, and the silence will be deafening, apart from a couple of machines that go, Yeah, that's me, but I've asked millions of machines, and the number of DNS queries per second is kind of frightening. And if all the people asking DNS questions ask all of the authoritative name servers if they happen to be authoritative, no, it's just not worth contemplating heat death of the universe. You know, this doesn't scale. So when you've got a problem like that in computer science, where you've got this sort of unstructured space, the last and worst possible answer is ask everyone, [George: yeah] we tend to forget that in protocol, sometimes, you know, broadcast is your enemy. It's not your friend. Asking everyone is the last resort of the desperate. What we do instead, classic computer science is to structure the data. George Michaelson 14:11 Useful level of indirection. That's the phrase, a useful intermediate level of structure, Geoff Huston 14:17 structure. And structure kind of allows you to walk through this space in a manner that is deterministic, that doesn't blow everyone up in the process. It doesn't create, you know, collateral casualties as you go and hit random things. So the way we structure the DNS is actually mirrored against the structure of the name space itself, you know, why do we have dub, dub, dub.potaroo.com, why do we have www.apple.com, what? Why were the dots? Why do they all seem to have a very similar, small set of final labels? And the answer is this structure, right? It. Now, the way this works is those dots are critically important. They're cuts in authority. George Michaelson 15:08 They're potential cuts in authority. Geoff Huston 15:15 Oh, you've gone from a beginner's course to an advanced doctorate in DNS in one sentence. George, George Michaelson 15:22 all right, let's put that to one aside, the point at which it changes from being a thing you know to a thing you know about someone else. Geoff Huston 15:30 Somebody else knows, and I don't know. So you know, if you look at the common point and it is a hierarchy, there is an apex, and at this apex, oh, don't tell me what the exact number is. I've forgotten 3100 about a few 1000 of these names that are at the top of the hierarchy. Yeah, George Michaelson 15:50 there were initially a far smaller set that we all knew and loved.com.edu, 252 letter codes that align with the UN ISO. 3166, country guides. But a decision was made to open up a market there, and we had an initial tranche of about 1400 and I'm guessing there's now a second tranche, which means that we've have got up to somewhere about 3000 top level things. Geoff Huston 16:16 They're expensive beasties. There's a complicated process run by ICANN and so on. But in the end, what it means is you can only sort of a valid domain name, one that works in the DNS that final label is one of those, you know, select 3200 names, like .com .net I think dot Bugatti still exists, and a bunch of others, George Michaelson 16:39 3000 subdivisions directly under the top of the tree. Actually isn't a bad way of dividing it up. I mean, you know, this is 3000 infinitely large shelves in the library, 3000 categories of different things. Wow, you could actually manage the information space quite well with 3000 labels. So I'm comfortable that a machine on my behalf, could know all of those 3000 and where to go to ask them what they know about things under them. This is starting to feel more tractable. Geoff Huston 17:12 Well, we could do it that way. Your machine would actually know all 3000 all of the time, and then you would not need these specialized machines who maintain the magic List of 3000 names. But at the moment, we're not in that world. We're in the other world where a small group of people, 12 of them, 12 entities for free, and you've got to give them kudos for being so altruistic, maintain a collection. I think it's around 5000 machines, a carefully number of machines, each of which has a faithful replica of those 3000 names and the name servers that are responsible for them that actually can tell you about labels inside those zones. George Michaelson 18:06 So we've come to the magic point. There's a root and it has labels, which are the things that are in it, the root zone. And the thing that is held about those labels is if a name ends with this string, if it ends with .com if it ends with .org if it ends with .uk go and ask these name servers. So for each of those labels, it has a list of name servers and says, beyond here, I don't know, but if you ask them, they're the ones who have the authority to tell Geoff Huston 18:41 as a innocent party, as a user of this system, you don't know where the changes in authority, the cuts, the zone cuts occur. George Michaelson 18:52 So change of authority, you're meaning something quite specific here. Geoff Huston 18:57 Well, inside the root zone, I could actually put an entry that says A dot B as a label, not B as a delegated zone. Go ask the server for B about A. You actually have the full string A, dot B. George Michaelson 19:14 You could do that. Geoff Huston 19:16 And in advance, you don't know what you're asking for. Oh, I thought I meant to ask for the name servers of B, and the answer is, Na, there aren't any. It's not what you think it is. I want an A dot B. Oh, I know the answer for that. There's no cut. George Michaelson 19:31 You can do this so you can embed a thing that has the literal character full stop in the string that is the thing you're talking about. And although earlier we said that's where the change in authority is, it's possible for it to not be a change in authority. Geoff Huston 19:50 That's the anomaly you accurately identified, which makes this all the weirder and perhaps all the harder. So we're circling around to what do you do? And. The answer, oddly enough, is incredibly simple. Let's say I'm trying to find www.potaroo.net, it's got three labels, and I have no idea where its name servers are, but I do know one thing. I know the IP addresses of those 12 magic entities that have a copy of the root zone the top level. So I ask anyone at random, hopefully the closest one, but anyone and I say, tell me about www.potaroo.net, now the poor old root name server says, joking, I have no clue, but in answer to your query, I will give you a referral. So you asked for a particular name, and I will give you the best redirection, a referral that says you know what's going to help you is the servers that are authoritative for .com or .net what do we ask for? potaroo.net .net, and so I now get a new set of people that I can ask my original question, George Michaelson 21:05 And you have implicitly been told in that string, dub, dub, dub.potaroo.net, no matter what lies further down, you know, there is now a zone cut at .net [Geoff: right] You learned both who to ask for the next part and where is the zone cut Geoff Huston 21:23 valuable pieces of information. So I don't actually ask, is there a zone cut between potaroo.net I actually asked for the full name and the root server conveniently says, Look, I don't know what's going on below that, but I do know .net is a delegated zone. It's a cut point. Here are the servers for .net George Michaelson 21:43 and so you, implicitly, you're going to go to those servers and say, here is the full name I need to know. Dub, dub, dub.potaroo.net, what do I do? And if it turned out that was directly in .net they wouldn't have to tell you to go and ask anyone else. They just tell you, but this is another place where there can be a zone cut. And so they say, Hmm, dunno, but I will tell you. The people who have potaroo under me, [Geoff: yes] can help you. They do the same thing. So it's a turtles all the way down world here, isn't it? Geoff Geoff Huston 22:16 turtles all the way down. And the process is called delegation. And you know the word is as it means I'm not responsible for the labels below this point, I've delegated it to somebody something else. And here are the name servers. You should ask about those names. And I don't know if that's the end of the chase, or you might go chasing further, but in essence, it's a delegation point. George Michaelson 22:42 I have so many questions Geoff. I mean, I probably need to try and keep them in control, because I might be getting ahead of the game here. But the thing is, how, how Geoff, did the root know what the name servers were for .com who told them who controls that decision? Geoff Huston 23:03 Well, there is a little group, PTI. It was what we used to call the IANA George Michaelson 23:09 public technical identifiers. Geoff Huston 23:12 Ah, your fingers are faster than me, yes. And it's their job to actually maintain what we call a zone file for the route. And that zone file is actually remarkably simple. It's a collection of top level labels, com, net, org, AU, AP, you know, US a collection of labels and the name server records that tell you the names of who can serve each of those delegated zone. And that's not all. That's not all. It also contains, just to help you, some ancillary what we call glue records. And so we know you're going to ask for it. I tell you the name of the name server, and as a helpful hint, I say on by the way, their IP address, we've been told, is this, you should send the packet to this IP address, George Michaelson 24:07 right? So first of all, it's a group called PTI, and what they're doing sounds like a function that I know, and you know would call registry. So it's not I speak port 53 DNS UDP. It's I know this information because someone registered it in me, and I construct the zone file, and I push it out to these root servers, and they don't change it. I'm the point of authority that says what's going to be in this file, and the things that are going to be in this file include this name server and the glue where I say, Oh, if you're looking for that name server, here's the address, but Geoff, I can ask the same question again. How do they know those values? How do they get to decide what those values should be? Geoff Huston 24:57 The people who are the subjects of that delegation. Hi, my name is AUDA. I run the registry for .au Hi, PTI, we have some new name servers for .au their names are blow.me.down, you know, and so on and so forth. And their IP addresses are as follows. Can you please add this information to the root file, the root data file, and PTI goes, here's some super secret questions to distinguish you from someone being an imposter. George Michaelson 25:31 You mean the same as the certificate dance that we were talking about in the beginning. Geoff Huston 25:36 Oh, I don't know. I don't work for them, but I assume they have some secret squirrel handshake that says that these are real requests. And once they establish that this is a real request, they make the change. They change that zone file because the people who are being described asked for it. George Michaelson 25:52 So we're going through a rather interesting loop of behavior here. Geoff, this AUDA mob. They have to be the ones who determine where their name servers are, because they have to pay them money. It's a contract in them, and it's about their zone. So they ultimately have to be the people who say, these are the values, but they can't scribble them into the file that is the zone of the root to say that the only people who can scribble values in there are PTI, which means AUDA have to tell PTI to do it, then PTI write it into the zone file, and the root servers serve it. They supply it over DNS protocol, and they have to be able to say, because I said it, it's true, and so it's something they're saying that they are asserting. But the actual Why is it true quality is because AUDA passed it through this weird machinery. It's a bit circuitous. Geoff Huston 26:49 Well, it's bit circuitous. And while most of the time it works, sometimes it doesn't. Sometimes the information that IANA get was right on the day but goes wrong the day after. Sometimes, you know things happen, and it's the name is difficult to resolve, and sometimes even unresolvable, because the data in the root zone has fallen off the tree, it's gone out of date, George Michaelson 27:12 and It's turtles all the way down. So this behavior we're talking about for AUDA an .au is exactly the same kind of behavior that you, as the delegate of potaroo, have to do with some intermediary that supplies the services in.net it's the same dance, right? Geoff Huston 27:30 It's all the same dance. You have to tell your parent who your name servers are and their IP addresses. That's the game. George Michaelson 27:37 And your parent has to tell the world those values, Geoff Huston 27:42 yes, whenever you ask for a name that's in my zone, the referral answer that they generate from their name servers says, I don't know anything about it, you should ask this name. And by the way, they have these addresses, v4 v6 you have any number of addresses you want, but you know, normally only a few, and that is a replica in theory of what I told them originally out of there. George Michaelson 28:08 Okay, so I mean proof by existence, the DNS is working. This is mostly Okay, and we're all happy as larks. I mean, this is a good world. Geoff Huston 28:16 No, no. Hang on a second. Hang on a second. Who said that potaroo was a delegated label in .net George Michaelson 28:25 Well, you told the registry, who runs .net you told them that Geoff Huston 28:29 I don't own .net [George: No], I could be lying. I could have nothing to do with them. Some random person knocks on their door saying, potaroo, can you delegate that name? And they go, who are you? And that's a very good question, who owns the fact in .net who owns the fact that there are delegated labels, recognized real labels? Whose decision is it? George Michaelson 28:51 Well, I know what I want it to be, but there's this gap between what we want and reality. So what I want it to be is somebody who can prove they have control of the idea. Potaroo.net exists as a name. There's the original applicant, and they have secret passwords and tokens, and if they pass it on, they give it to someone else, it should be in that someone else's hands, and they change the tokens. And that process should be using mechanisms that stop bad actors intruding and saying, no, no, no, I can tell you where potaroo should be. All of that should happen, but that starts to become a massive layer cake of complexity. So I am wondering, is there a way we could sort of do this better? Geoff Huston 29:35 Well, my point is, I suppose real control rests with the party that can undo it, and .net has a unilateral ability to erase potaroo. Just remove it from the zone file and it no longer exists as a name. I can't stop them from doing so, apart from buyer contracts, there's no other way the protocol. Won't do it. The delegation structure won't do it. They have control of the fact that that label is a delegated label in their zone, George Michaelson 30:10 right? It's kind of definitional that all other qualities aside of how I prove I want this, the decision on their part to say, Yep, I accept those changes absolutely vests with them. Only they can modify that zone is inherently the way that zone is correct. It's correct because they do it Geoff Huston 30:28 okay. So the other thing I told them, because they don't run the name servers I do, is I told them the name servers and the IP addresses for that delegated zone. Who owns that information? George Michaelson 30:41 I smell a trick question coming Geoff. Geoff Huston 30:45 It's it's slowly forming question and answer we will get there George Michaelson 30:50 that depends what the name of the name server is, doesn't it? Because there's no rule here that says the only name that can serve potaroo is a name under Potter that isn't the rule. Geoff Huston 31:04 Well, it's as bad as the rule that says the only names that can serve as delegated zones in .net happen to be .net servers. You can't do that in the DNS. You can't enforce that. So the traditional view has been the delegated child has the ability to define who the name servers are. George Michaelson 31:26 It is certainly true. When I look at the zones I administer, apart from this initial record called Start of authority, that is the magic setting, timers and time to live and version numbers of the zone, I add extra labels after that, immediately after that, I add a label to say how mail is delivered. I add a label to say if I want the zone itself to have an IP or not, because some people do. And I can add an infinity of NS records in me, saying, yeah, those things that you were told to ask they exist. I accept that. But here's another 20 that I've decided exist too. They're in me. Geoff Huston 32:08 I've found a couple of zones with 200 you know, just proving stupidity exists in all kinds of dimensions. George Michaelson 32:14 And those labels never, ever go up into the parent do they? They're not in the parent glue. They're just inside the child zone. Geoff Huston 32:23 Well, hang on a second, because you just mentioned the magic piece of semantic overload, the NS record. Now, the NS record is used in referrals. What the root zone actually contains is 3000 NS records. It's a special kind of piece of information that says that label I know nothing about, you should go and ask the subject of the NS, because the subject of the NS is the name of a name server, and you're gonna have multiple NS records. So the fact that an NS record exists in a zone is actually a parent decision. George Michaelson 33:02 The fact that some NSs exist in a zone is a parent decision. But they aren't the only NSs that can exist. Geoff Huston 33:12 Well, what we did because we're lazy and not by we, I mean Paul Mockapetris and Paul Vixie, I guess if they're listening, you know, yeah, right, you were to blame. What we did is we actually overloaded it. And the NS record says potaroo.net ns, and then the name server of the zone potaroo.net and I can have a number of such records, if you see that record in the.net file, in the parent file, it's all about saying this label is a delegated zone. It's a cut point, yeah, I'm not authoritative anymore. Go ask these other people, George Michaelson 33:54 and if you go and ask one of them, they can say, why? Yes, I know that zone. Here are a list of other NSs that also know that zone. Geoff Huston 34:06 Oh, you naughty person, George. They're meant to be the same. George Michaelson 34:09 Are they? Geoff Huston 34:11 Well, I said mint. And as we know, on something like the Internet, whenever you duplicate information, you can never be quite sure if the duplicate is an original, faithful duplicate of the original, [George: right] It just, it doesn't work that way. George Michaelson 34:25 So we are introducing the complexity that there have to be NSEs that are in the parent and they have to be able to answer for the zone, or it goes into a state where we use the horrid term lame, lame delegation, [Geoff: right] But they aren't the only NSS that can exist, because I, as the zone owner, can add all these extra NS records in the zone file about me, and I don't have to tell my parent that list. I don't even have to keep the list in the parent up to date. Geoff Huston 34:59 Well, you. Should, you should, and that's capital s capital. It's a standard should. It kind of says, If you don't do this, stupid things will happen. Might possibly okay. So now let's introduce the next complication, called DNS security. Every zone in this game, the DNS SEC game, every zone has a key pair, has multiple key pairs, if you want, and all information is signed. So this is wonderful question, and it's the one that's been driving everyone nuts for years. Who signs the delegation records these NS record. And the real answer is, you both can't sign it. I'm sorry. You just can't. One's meant to be a copy of the other. Who's the primary source? Ooh, good point. George Michaelson 35:57 Now let's just drop back a minute to something you said earlier. There aren't multiple hands who can make things exist in a zone that's delegated to somebody. So if we're talking about potaroo.net, and signatures, about the string potaroo, there's only one hand that can write those signatures into the file .net it's the people who own the .net zone file. They're the only ones who can write it, but you're saying, Never mind who writes it there. Who makes the secrets that make the signature that go with that label? Geoff Huston 36:31 Whom should you believe as to the authenticity of that data when push comes to shove, the parent or the child. George Michaelson 36:41 Well, if you trust the child, and you've been led to someone who's lying about being the child, you're now getting to trust me because I said it, I'm the child. Oh, okay, I'll believe you are who you say you are. That's a bit dodgy, isn't it? Geoff Huston 36:55 Well, the fact that the delegation exists, only the parent can actually say that that's true, but the name servers is actually falls under the authority of the child. They should be the people signing those NS records, and because one is a copy of the other, you're left with this weird choice that either the parent signs it or the child signs it, and you can't have both. So you find this odd anomaly in the DNS that in the parent zone, none of the name server records, these referral records that everyone uses are signed. You cannot, a priori, check their authenticity. You just have to believe, George Michaelson 37:41 I'm sorry, but my jaw has hit the keyboard at this point. We're trying to construct a .... Geoff Huston 37:47 we wouldn't be the first. George Michaelson 37:48 We're trying to construct a world of security, and we're creating things that are signed assertions. And we're in this parent saying, I'm about to tell you who to go and ask to find out who the child is, and the one thing I'm not going to do is give you any reason to trust that thing. I'm telling you to go to its label and how it maps to an address. I'm not doing it. Geoff Huston 38:10 I'm not going to give you a digital signature, nothing. You just go and trust me, George Michaelson 38:13 that is very strange. Geoff Huston 38:15 You wouldn't be the first to go. This is bat shit crazy. It's just weird. You know, never seen anything like this before, and you're right. And it was always one of these bones of contention about, when we introduced security, did we kind of think about this in the right way? Where should that information be, and why? Right? And there's been a number of efforts to try and change that balance. Why don't we buy fiat simply say, as a rule, the parent shall be authoritative for all NS records. George Michaelson 38:48 It's a decision. I mean, I guess we could take that decision. So every time Geoff Huston 38:53 I want to change my zone, I need to have a conversation with the parent, going, Hi, I'm Geoff. I'm real. Make these changes. What if I outsource the operation of my zone to the big DNS company.com Do they have to come back to me to prove to that, you know, and so on, how long and circuitous does this process get? Have we just buried the DNS in realms of bureaucracy and created even more problems to ourselves? Because realistically, who gets to say that they're the delegated zone operator? George Michaelson 39:26 Right? So we're coming to this point of the difference between things that we believe we want to do in terms of authority to act and hold pens and write statements and outsourcing. Because if I've entered an arrangement with somebody like Amazon, route 53 to work on my behalf. Just because they're very big doesn't mean they should automatically be believed, does it? They actually need to have some proof of intent. I can't know what IP addresses day to day, hour to hour, they use to administer their service to do the job that I'm trying. To get them to do they need to be able to say, no, no, no, no, no. That's changed. He's over here now. So I kind of need a way to make this work Geoff Huston 40:09 but to get the.net people to listen to route 53 they've either got to impersonate me bit of a no no, or somehow expose the relationship between me and them to say where the they're the agents of Geoff under our authority, to do this, which is again, kind of messy, and it doesn't work very well. It's actually easier for route 53 to assume control of my domain, in which case they can assume control of the NS records and they need to consult nobody. So there's kind of good arguments to say the child should be authoritative for everything except the delegation itself. And that's kind of the first part of the NS record. Yes, this is delegated. But the second part to whom is kind of getting a little bit weird, because although it's part of the same record. The to whom bit is legitimately a child problem. George Michaelson 41:05 I sort of want to go, Yeah, this is details. This is crap. DNS is working fine. And in the back of my head, I'm thinking, this actually, Geoff Huston 41:15 sorry I've left my chair on the floor. Let me pick it up. George Michaelson 41:19 Isn't details and it isn't crap, right? This is kind of legalistic nonsense that somebody has to pin down because it fundamentally alters the whole equation of efficiency and trust. In this framework we need this Geoff Huston 41:33 delegation is at the heart of a distributed system. The act of saying, it's not me, it's over there, and having trust in that delegation is actually at the heart of most of the DNS. So this is not a light conversation. So let's go down what the thinking has been and why. Because you can't have a flag day for the DNS. There's too much out there, right? Everyone. We're going to change the DNS, all those millions of pieces of DNS software that exist on billions of devices you're going to change on Monday, midnight, UTC, yeah, right. Ain't going to happen. Somehow, every single change you need to introduce in the DNS today has to be gentle, incremental. Everything still works, even when the change is sort of being rolled out. It's all piecemeal. There's no control channel. George Michaelson 42:25 Yeah, this is the changing the engines in flight continuously moment, isn't it? We don't get to go to land and put a new engine on. We have to walk out on the wing and play with what we've got, because no one's prepared to turn it off and turn it on again. Geoff Huston 42:41 Oh, no, you have to walk out on the wing. I'm on the ground looking at you. But yeah, no, that's exactly the problem, and it's a not insignificant problem. So how do you change things in the DNS? And again, it's a very abstract thing that there's sort of two answers we all go to. One is a new data entry, a new data type, an A record is an IPV4 address and quad A record is a v6 address. An NS record is a delegation. And there are a bunch of these different types of records for DNSSEC. We have digital signatures,RRSIGS etc. So here we are. Let's add a new record type to handle who's got delegated authority to set things for this zone. Yeah, let's, let's make a new record called, well, why not call it DELEG and let's actually say this is authoritative at the parent. That's interesting. George Michaelson 43:39 Ah, now comes the point. We're making a decision in this soup of his is, is it in the child? Is it in the parent? We're saying it's going to be in the parent. Geoff Huston 43:51 Well, you know, you have a choice. You can make it one or the other, and we've decided to make it the other. Now, if you describe a new resource record type, you also get to define what its value is, how is it structured? And there's this recent, oh God, I'd call it a fad, but I think that's actually that's actually trivializing its true intent, the service binding record, George Michaelson 44:15 right? That was a quite complicated record that had rules for semantic structure in the string value, you could actually embed inside that all kinds of complex processing logic using regular expression matches on strings. You could do things with that record. Geoff Huston 44:35 Oh, not the regular expression, but what you could say is, rather than simply translating a name to an address. How banal. I want to know how I can reach this service. Oh, fascinating. So www.potaroo.net, and I say, look, I would prefer that you use the QUIC protocol, HTTP3 So that's my application letter. Protocol, HTTP3. I would prefer that you contact me this way, so I'll give that a high preference. Here's a hint about a v4 address. Here's a hint about a v6 address. Here's some keys, maybe if I'm doing encrypted client, hello for TLS. Here's a whole bunch of attributes about that service, and I'm going to bundle it up, tie a pink ribbon about it, and punt it back to you as the answer to your service query. Here is how you reach my service. The next packet you send is a TCP hello or a quick hello or whatever, George Michaelson 45:36 But it's kind of in standards terms, a useful level of indirection. These SVCB records are a family of things, and it's possible to do many things inside them. You just have to move to a different room and say, this is the set of rules I want to construct for a new type of SVCB record, and the DNS service doesn't actually need to know a lot about that in general function. It's just passing these things as strings. Here's the value that's in that record done. The people who need to know can now look inside it and unpack the elements to deliver the function they want. So you described it being used for things like, here's the TLS mechanism. Here's how to do QUIC talking to me. It sounds like you're heading to here's an SVCB record that is about the DNS. Geoff Huston 46:28 Let's just point out that you haven't just crossed the road. You're teleported to a slightly different solar system. Because the original idea was, you want something, you get something. And we even wrote an RFC that said every single query can only query about one resource, record type for one label. So if you wanted to know the v4 and v6 addresses of a name, guess what? That's two different things, two different queries. Every single thing in the DNS was meant to be atomic, that each attribute of a name was a separate resource record, and queries are cheap. They're free. Just keep on asking til you get it. And then along comes SVCB that says, nah, I'm going to bundle stuff up and gratuitously give you a whole bunch of things you may or may not want them. That's not my problem. Here's the bundled answer v4 address v6 address, relative preference, all that stuff is inside one answer. George Michaelson 47:28 But we do that because this thing of questions are cheap is only true if you ignore time. Asking questions is a linear process that stacks up the cost of time if you are predictably going to be coming back asking me six questions, and instead of you having to ask them, I give you a bundle. I get rid of the cost component of time. Geoff Huston 47:50 So isn't it amazing, the DNS folk, for 40 years didn't care about time. There's even an implementation of a DNS recursive resolver out there that says, If I can reach you within half a second, you're the same as everyone else who I can reach within half a second. George Michaelson 48:06 Wow, half a second, that's a lifetime. Geoff Huston 48:10 Yeah, I want to differentiate in milliseconds. I want the closest. Nah, if it's within half a second, it's close enough. And the current view of time is every millisecond counts the billion dollars rests every single time you take longer than you should. So giving you a whole bunch of answers quickly, even if you didn't want all of them, is actually way, way better than saying I'm going to tell you exactly what you asked for. If you want any more, ask some more fascinating. George Michaelson 48:38 Wow. This is not your mother's DNS. This is complicated. Geoff Huston 48:43 Well, it's kind of this model between a structured database where you ask for exactly one thing and you get exactly one answer, and the other one is, I ask for, how do I reach this name thing? And you tell me all the ways I can get there and your preference, you're packing more information in. George Michaelson 49:02 I can actually sort of see this as properly net beneficial in the changing the engines in mid flight model, because if I can bang a box in the system that knows how to say, oh, here are the NSs, but what it asks is, where is the SVCB record? And then unpacks from that the info to make what I need as NS records. I might have got what I needed as a dumb client on the edge, if I don't understand this technology, an intermediary can properly do it for me, so I could see partial upgrade in the network, kind of working here. And Geoff, you said something that is really important to me, this vagary, is it in the parent? Is it in the child? You said, No, we've made an absolute decision. This is in the parent. It's authoritative because the parent signs it and says, This is correct. Signed me the parent. Geoff Huston 49:57 Because when you're building new resource records, you. Have the ability to define that because it is just a stroke of a pen. George Michaelson 50:05 So we might be making a simplification, in one sense, adding a massively complex new record type in another sense, but we're simplifying a different quality. Geoff Huston 50:17 Well, as usual, there are many ways of doing things, and so now we get proposal B. George Michaelson 50:25 There had to be two, right? Geoff Huston 50:27 There did have to be two. And this is what got to be called idyllic in the past. You see, the other way of doing things is to make use of these. I don't know there's a magic character out there, the underscore. The underscore character, and they used it a bit to say, if I want to connect to someone using TCP and port 443, I can create a label, underscore 443, dot, underscore TCP, dot, service name, and then gives some attributes of connecting to a service using TCP port 443, George Michaelson 51:07 So it's not doing complex record structure in the record the way SVCB does. It's doing complicated records as labels in DNS name, Geoff Huston 51:17 in the query name, in in the query name, [George: okay], oh, can we make the name servers reachable via these kinds of underscore DELEG queries? George Michaelson 51:31 I don't see why not. Could we do that? I think we could do that. Geoff Huston 51:35 We can do that. And, you know, there's even some running code. And so now you get the conundrum, do you stash the information in specialized labels that aren't delegations, that aren't delegations, they're just labels, and put all the information you want about how to reach name servers, etc, in those specialized labels? Or do you simply go, No, I'm going to increase the information density of referral, I'm going to use a delegate record to describe a referral, you know, a delegation, and by the way, it has a bunch of other stuff as well as the delegation. So I'm either going to drive a truck back down as an answer, or you're going to have to figure it out by using specialized query names. George Michaelson 52:20 I'm tempted to say we might actually not want to have two different ways of doing this Geoff. I can understand that it's good to consider two ways, but aren't we going to come out the door having picked one? Geoff Huston 52:32 Well, I would hope so, because the lesson with the v6 transition is having 35 different ways to do the same thing just confuses people. And if we'd had one transition mechanism, there might have been a fair few grumbles about it, but there'd be very little confusion about how you do a transition. Implementing a million different ways to do something does not exactly do anyone a benefit in the long run. So selection and development is good, and so the theory was, in the DNS world, let's pick one, [George: right] And after some tortuous debate and a number of tortuous meetings, they appear to have got close to picking one. [George: But], well, there are some pretty cluey people in the DNS. I would say I'm not one of them, but, you know, there are some clues. And someone said, look, let's, let's pull these two threads apart. What you're trying to say is that the parent side, this is a cut point. And you might even want to say these are the name servers that are authoritative for the delegated zone. That's Information Model A but how you reach them is not a property of the delegation. If I set up a name server that is authoritative for 50 zones, and it's reachable by QUIC, the QUIC protocol, DNS over QUIC, then it's reachable for all 50 it's not, oh, you're not part of the blessed zone set. I'm not going to answer your query, so you've got to distinguish between the properties of the delegation and the connection properties of the authoritative server. George Michaelson 54:06 So if we go back to the idea of the NS record when you delegated potaroo and said Ns is Joe, there could have been 100 other places that said Ns is Joe. And if you learn Joe is reachable on an IP address, you don't have to ask again for all of those 100 delegations, you just know. So it's in similar spirit, right? You're saying, if you learn these properties of can be reached over. QUIC has these TLS parameters, uses large packets, speaks modern DNS. You don't have to retest just because it's serving another zone. It told you it can do it Geoff Huston 54:41 right. So why do you need to stuff that information into DELEG? George Michaelson 54:46 Oh, wow. Oh, so we talking an NS record plus plus, or some other fancy way of denoting NS behaviors. Geoff Huston 54:57 We have a service record for HTTP. And it is indeed an SVCB record type, but we called it HTTPS. And you can imagine in your head having a name server, an authoritative name server, record a SVCB, record one that describes what it can do. I can do DNS over TLS. I can do DNS over HTTP, you should use these addresses for me. I'm not real. I'm an alias for this one over here. I can do lots of things if I can play with that name, server name as a service, lots of things I can't do with an NS record. So why are we trying to add all these nuts, bolts, bits of tinsel and everything else to a relatively simple thing that says this is a cut point. You should go and ask the following service points. Maybe, as was pointed out, maybe we should be instead.. instead focusing on, well, it's all the same. It's just a service. Why don't we put all the adornments in? How do I reach that name server and ignore the fact that there's a delegation? I am incredibly attracted to this personally, I think, trying to solve all the same problems again and again and again in different ways. In the DNS has been a never ending nightmare. George Michaelson 56:25 Yeah, I don't think we want to do that. Geoff, Geoff Huston 56:29 well, I think we do because we're complication merchants, and we tend to focus very deep, very quickly, and all of a sudden, everything we come up with has to solve all the known problems. It's kind of Oh god. DELEG is kind of hard, George Michaelson 56:42 but this ultimately is going to surface with some decisions being made. There might be grumpy people in a room, but we are coming to a point of an improvement in complex ways to deliver a slightly more certain, and I'd argue, safe DNS outcome. This sounds safe. Geoff Huston 56:58 Well, I think there's kind of two parts to this, as always it is. We need time to think and time to pause and reflect, and this sort of frenzied activity of comparing the relative attributes of solution A versus Solution B. And then in this particular case, someone's come along with what have you forgotten? What you're trying to do? Maybe it's solution C. I'm kind of struck with that. It sort of appears to be in a very perverse way. Yeah, well, tunnel thinking, George, tunnel thinking, George Michaelson 57:27 watch this space. Geoff. I look forward to hearing more about this Geoff Huston 57:30 one. Oh, there's more to come. Undoubtedly, as we try, we've increased the diversity and capability. The more we encrypt, the more we use agents, the more we outsource, the more we try and make the Internet at an infrastructure level leap over higher hurdles and different kinds of hurdles, the rich that the infrastructure has to be to describe how so the clients aren't constantly going well. Should I try this? Should I try that? Should I try this? Our infrastructure has got to say, if you're capable of x, go to x. If you're not, there's y, the and so on. There's all these alternatives. And that's the underlying architectural change that's going on. And quite frankly, I think that's really good that we're thinking that way, that you know, as we try and make this faster and more secure and more capable, obviously the infrastructure has to come along with us, and bits of the DNS certainly have to change. So yes, look out for the DNSOP Working Group and the DELEG Working Group as they try and wrestle this tiger to the ground. George Michaelson 58:32 Yeah, interesting times indeed. Thank you Geoff. Geoff Huston 58:36 Thank you George and thank you dear listener. I hope you've been able to stick it out. We haven't been too jargon, heavy on the way. George Michaelson 58:43 If you've got a story or research to share here on ping, why not get in contact by email to ping@apnic.net or via the APNIC social media channels. Also remember the measurement@apnic.net mailing list on orbit is there to discuss and share relevant collaborative opportunities, grants and funding opportunities, jobs and graduate placings, or to seek feedback from the community on your own measurement projects, be sure to check out the APNIC website for All your resource and community needs until next time you