IETF 108: Technology Deep Dive on DNS

so good morning afternoon evening night everyone um welcome to technology deep dives on the dns um the technology deep dives are a series of books where we discuss a topic in depth and provide a focused exploration of the technology um they are designed to be interactive but this is likely to be a little yeah to do virtually but we're going to give it a try um this session is being hosted both on meet echo and is also being streamed on youtube it is also being recorded and will be posted later um but we're only going to be handling comments and questions in meet echo we're not likely to see any questions that you post in youtube so previous deep dives were on modern router architectures and how network interface cards work today at the end of those sessions we set up surveys and dns was the most requested topic for a future session so while preparing a session on dns we realized that there's more than enough content to fill many many many hours um the session is only 90 minutes and so it's mainly going to have some introductory stuff um and some deep dive but we're likely to have at least one more session on the internet including things like myths and misconceptions um that will likely happen at ietf 109 or ietf110 and with that out of the way um and because we have more content that we have time for i'm gonna hand it over to wes take it away all right thanks warren uh hopefully everybody can see my slides i think barry indicated that he could so uh the three of us are going to go over stuff we'll we'll start sort of high level but we'll dive pretty deep into various parts um we will do in the future security related stuff this is a ietf um a ietf event part of ietf 108. uh welcome everybody to ietf108 this is besides the hackathon this is one of the earlier things that are happening i hope you have a great week next week please do note that the notewell for the idtf does cover this event as well i'm not a lawyer so i won't attempt to summarize it for you but you had to go read it on the ietf website if you have not done that before today we're going to be going over sort of three major topics i'm going to talk about dns basics and beyond the basics jeff is going to talk about the resilience of the system and joao is going to talk about the dns software and the apis uh there's a lot that we are leaving out that we will uh cover at possibly a future session as warren indicated so this is how the internet user average internet user sees it we've at the ihf we've designed things well enough that you know we hide a lot of the complexity in many protocols that dns included they want to go to a website they type a website in and they think they get everything back from you know some machine they don't understand quite how it works and you know the technical person typically knows a little bit more right they know that they have to look up you know an address in the dns first translating the name into an ip address and that's done by dns and then they do http or https to you know a server to actually get the answer the dns is a lot more complex than that and we're going to go over bits and pieces of this whole diagram but there's there's lots of devices and boxes involved and lots of servers involved just to even complete one web page and and actually as an example of that example.com as many people know as a as a domain or owned specifically to deal with documentation and things like that it's one of the things we put into ietf documentation and this is what a web page generates if you open your web browser and you go to www.example.com these are all the dns requests that get fired off each line is a individual dns requests none of them are http um the resolver in this case is is actually sort of the node in the middle and the edge node is a note that there's actually only one line from the edge node which was my laptop to the other one the ietf.org website actually has more resources on it and the end result is it causes a whole lot more a whole lot more dns requests you get to some of the bigger websites that have tons of things including ads and javascript and all sorts of external resources and it actually causes a huge number of dns requests and most people have no idea that this is happening behind the scenes caching which uh jeff is going to talk a lot about later really helps this where uh dnns actually the the resolvers actually memorize answers for a while based on the data we'll talk about that and the time to live values later but there's still a huge number of requests coming from you to your isp most of the time or you to your resolver most of the time and even with caching you can see that there's a lot of other bubbles that were new that were not cached information from uh dynamic content and things like that that pop up new new data so we're going to break things down at first i'm going to go into the underlying distributed model of the dns the dns is a very distributed protocol and it was really created as a replacement for just static hosts files way back in the beginning of the internet um it was you know it was people were shipping around these static host files of addresses and names associated with them and then they'd have to update them on a regular basis and that got unwieldy and clearly doesn't scale to the millions of names and addresses that we have out in the world today so the uh the envision was we created this tree of information um tree is sort of a misnomer because it really looks more like a root structure than a tree but it's still called the dns tree with the root at the top a lot of people don't even know that the root exists they think that net com org and all the top level domains are really the top but there actually is a system above that which we'll talk a little bit more about and then there's second level domains uh things like example.com is one at ietf.org and icann.org as some other examples um this diagram is going to repeat a lot i am not showing all of the other components of the netcom org and root zones uh because the dot net zone for example has 13 name servers associated with it would be other bubbles around and so does common and org has 6 and the root has 13 as well uh but to simplify it we're going to limit these diagrams mostly to just be talking about the lower level leaves in terms of complexity and their content so what is the resolver well you when you type something into your web browser or you open any sort of internet connection because the web is not the only thing that uses the dns or the internet for that matter uh it opens a a request to your isp typically your dns resolver and the isp and though the job of those boxes including the cloud-based ones that are talked about a lot in the ietf lately and in other places the job of them is to go actually traverse this tree to find the answer that that you need and then return it back to you there's a good number of types of resolvers and there's a good number of boxes that also may exist your wireless box often acts as a resolver uh the hotel uh paywall type you know thing where you have to prove that you're in the room or a coffee shop or something like that acts as a resolver as well and treats them differently joao is going to talk a lot more about them later but there's stub recursive forwarder and validating he'll talk more about what each of those are the near the end of the talk priming queries bootstrap resolvers when you're when a resolver starts up it really doesn't have any clue about you know what the world looks like uh so it the only thing it has is a hard-coded list of addresses of where do i get started and it the first thing it does is it starts up and asks the root hey you know is my list up to date where do i get started where are the the 13 points on the um or six really 20 excuse me 26 4 13 for ipv4 and 13 for ipv6 where do those exist in the world how can i contact them so i can find the rest of the tree so this is called a priming query you'll see that in a lot of documentation and in a lot of discussion the dns is a distributed protocol and it does that by delegations and so each zone is allowed to delegate any sub portion of its name structure within it to a different zone where a zone is sort of a collection of names and information associated with one particular point in the tree and delegations occur lower so for example the dot net zone delegates iana servers the name label iana servers to ianoservers.net and it does this using name server records which we'll talk a lot more about by tel by giving clients uh references to here's where you need to go so a quick a little bit of dmns terminology looking at the same sort of diagram um the apex of a zone is another commonly mis heard and misunderstood name it is the top level name associated as sort of the entry point into a particular zone it's the the name of which a delegation actually arrives at uh oops wrong key uh other nodes of course can exist the leaves if it's the end of a if it's the end of a tree right is the the bottom node in a tree you'll find that it is called a terminal node or a leaf sometimes but they're terminal nodes meaning they're they terminate the tree whereas you can actually have nodes in the middle you don't have to have each name be subdelegated and so empty nom terminals are things like the a in b.a.example.com where there's actually no data there but there is stuff underneath it and it's actually within the same zone so when you read the documentation you'll see things like terminal and empty non-terminal you can come back to this slide if you ever get stuck a couple of important things duplicate records are needed in both the parent and the child zones so for net to be able to tell clients that come to it hey where is ianaservers.net it has to have a list of where to send people so there are three name servers for ianaservers.net there's a b and c dot nanoservers.net and those get those are need to be in the dotnet zone to say this is where i'm going to send people and it needs to be in the authoritative list for iana servers will actually also respond with its name servers list and these need to be in sync so what happens if they're not in sync what happens if dotnet actually has a and b and uh the ios server zone has b and c and you can see that these particular zone records actually don't match does this actually work well yes but it definitely has problems and causes timeouts as a resolver might go to a a and you know a will either answer or it won't but it's still the wrong place they'll eventually go to anna servers.net at least sometimes there's a whole paper studying whether that's actually true or not and ask them for the authoritative list and hopefully update their records if a won't answer if a will not answer and it doesn't actually have the information for the client they this is called a lame delegation another term that confuses people because it's uh sort of obtuse in terms of what it actually means but but essentially a lame delegation means uh that the there's a disconnect between the parent and the child and the parents still holding on to a name server record that the child no longer uses so the important takeaway of this slide is if you are running uh if you own some domains make sure your parent and your child are in synchronization so if you're running your own name servers if you update your infrastructure you need to tell your parent uh so let's talk a little bit about how this actually happens how the parent actually refers stuff so let's query.com servers about example.com and so this dig is a popular tool that comes with iscs bind there's a number of others that are similar including k-dig for not for example they operate in a similar way where you can direct a request at a particular server like i am doing here with a dot gt dlcs dl gtldservers.net is a server for dot com so if we send that server a request for www.inkexample.com and we ask it for an a record which is an ipv4 address we'll get into that later it will give back an authority section full of information so it's going to give back two answers it's going to say hey you need to go talk to a.i.a servers.net and b.i.n.servers.net for to get to example.com so only those servers know where www.example.com.com of course doesn't actually know the depth of the tree it only knows where example is but it does know where to send you it wants to send you to ianaservers.net but where is ianaservers.net so you can see a resolver starts getting this whole chain reaction of well okay now i have to go find this other part in the tree and oh a quick interjection so you'll see these numbers a lot in uh in all of these slides where there's this random number in the middle that ttl value we'll get back to you later and jeff will talk about caching later uh 17 280 is a two-day ttl which is really common for the higher level nodes and how long to keep information but uh there's a big chicken and an egg problem right how do i how do i get to some place in the net if it keeps referring to other places in the tree so pictorially dot com is basically telling you when you want to go to ianaservers.net you're going to jump over to a and b anaservers.net if you want to get to example.com so you you actually redirect you to a completely different part of the tree this happens all the time so there's another interesting one if we ask.net server for where is ianaservers.net and we say where's the name servers for for inservice.net it is going to answer well there are four a c and b and n s that icann.org so completely different part of the tree again so how do i talk to my to a ianoservers.net if it's inside ionservers.net itself you're actually telling me to go find something inside the zone that i'm trying to get to how do i do that so it gives back an additional section that contains glue records so you can see that in addition to giving you just the names of the name server is actually going to hand you addresses as well these addresses need to be in sync with the parent and the child as well if you change addresses of your name servers you'd better tell your your parent if they're within the zone in question these are called glue records another name that you will see frequently in the dns literature so the glue records are required when you have delegations to when you have name servers within the zone that you're actually delegating to the parent has to have the the list of addresses as well and of course they should match um so pictorially about glue nets name servers as i said know where the authoritative source for anna servers.net is there are three a b and c that are within the zone itself this is called in ballywick another uh term that you will see in dns literature a lot the red lines are in ballywick a b and c uh iana servers the other arrow to the right is pointing to an out of ballywick name server in other words it's handled by a completely different part of the tree so that's sort of the overview of how tree navigation works at a very high level in how resolvers actually have to you know find different parts of the tree we're going to dive into the dns packet and how it sort of evolved the stuff on the left is actually the total packet count or the total uh packet this the box on the right is what each uh the recursive uh excuse me which each uh portion of the data that's transferred around is uh shown as we'll dive more into that so the dns itself is a very very simple protocol it ships around these things called resource records which was the diagram on the right and a resource record is composed of a triplet it's composed of a query name which is the actual name that most people think of as a query type for example uh a quad a record or four a's is a ipv46 address and it's composed of a query class which is i n for internet and that makes up the 99 of what exists on the internet uh the rest of the classes aren't really used with the exception of a ks class which is a special case and we won't go into that today resource record sets all um they all match each of those three as a is a triple match an atomic unit of data you can't ask for just a sub-comportion of it if you want you know a a name for www.example.com and you want the ipv6 address for it in the internet you you get back all the answers you can't ask for just one or just a couple or even hand back just parts of them their atomic units are considered complete uh this becomes important for security later and it becomes important for caching as well uh note that they are not ordered the answers that you get back may be completely different than when you ask from uh one time to when you ask for the next uh some people think that they are ordered they are not and clients don't necessarily have to keep them ordered so even if you return them in the same order they may not be treated that way uh response records also contain a time to live that will come into play later as well as the data itself what the address actually is or possibly multiple addresses actually are the dns packet components consist of sort of two main sections there's a header with a transaction id which is unique per transaction or it should be uh there are flags uh we'll talk about a couple of them but not all of them and then there's the number of resources records in each section and then there are four sections following that so there should be of course a number indicating how many uh how many pairs are in each of the following sections like the question answer authoritative and additional we'll come back to that uh one real quick point uh you note that the number of resources in each section includes the question so you so the number of questions in the original request has to be there well there can really be only one um [Music] except that that's not actually true it turns out if you look at the original rfc it actually says that you can have a qd count or a question count of greater than one but that is not used today though the packet form actually format actually allows for it it's not actually usable and really there's a number of problems that people realized early on uh like you know how what happens if you're querying for multiple things well do you wait for all the answers to come back before you return to the client what happens if you know one has an answer and one has an error what happens if there are two different errors and they're not even the same error code and they realize the complexity of that it would be better to fire two questions off in different packets and different requests than to try and bundle them into a single one a quick point uh note there's probably a few people that get both of these references on the right if you're if you're uh over if you don't understand the bottom one go out somebody over 40 if you don't understand the top one go out somebody under 20. uh anyway dns packet sections so the question where the single question goes uh that's that's where the question goes in in the packet and it's repeated in the response so the client that gets the response back should have the question that can look up and say oh yeah that's what i asked uh the answer to the question of course would go into the answer section there can be multiple answers of course there's the authoritative section this is a really critical section that says what is the owner where are the name servers that own this portion of the tree who should i go talk to to make sure that this is this is the authoritative source or you know maybe the authoritative source is who you're talking to but it's it references who actually owns that portion of the tree and then there's an additional section there's lots of uh helpful stuff that goes into the additional section we'll talk about some of them today and as anything else you want you should want to know but you really can't trust so if for example glue needs to go in there but you should really go ask the authoritative source for what they believe their answers are if you remember the whole notion of cache poisoning it used to be that servers would trust anything you put in there so you could completely overwrite somebody else's addresses on the internet if they asked if you asked a um a authoritative server for a particular question and they give you a bunch of other data you just cache it for a while that's no longer true so i first stopped doing that when we ran into huge issues with cash poisoning so what happens in the dns when things actually go wrong so what how do we handle the errors in the dns what happens when um you know a resolver can't do something or an authoritative server can't do something well the good news is that there is a response code in the field and one of the mis understandings about the response code is what we're going to go into next and how it is actually handled and it gets a little bit complex because we've really kind of tinkered with it over the years you'll notice that the r code on the right hand side is the last four bits of that packet header for dns right there the problem is is there's only four bits so uh we have come up with a lot more reasons for having errors than i think was originally envisioned and there are certainly way more than 16 problems and way more you know response codes that could indicate something so people got creative about the whole r code problem and about other problems how do we extend the dns in general when we're there's no more packet space uh this is true for a lot of protocols there's not a lot of extension room well what if now hear me out what if what if we stuck those extra bits somewhere else and then we smashed them all together later right we just extended the packet and so thus a very creative hack called the opt resource record was created and it was put in a specification called eating s0 which is rfc 2671 it is an extended pseudo resource record that adds an additional that adds data to the additional section clients have to say that they support it they have to send one first before servers will send one back and it's required by um some protocol modifications like dns sec dnsx simply won't work without eating serial support uh most software these days does support it and it reuses the resource record byte format so it actually is a resource record in itself but it's sort of a pseudo one because software strips it out and it changes many of the fields to mean completely different things so for example the features of it in two include a much larger error code that comes out to 12 bits now it supports additional protocol flags that are needed for things like dnsec and it adds um a sort of an mtu path like discovery for uh for max message sizes that software can actually handle uh based on what it thinks that you can get through its local network for example at the application level not at the ip level it adds support for additional dns extensions and there's a few of those that exist today i did not enumerate the whole list but client subnet is a common one that a lot of people know about which is used by cdns as well as extended errors which we're going to talk about very shortly so the opt resource record field reusage as i said they they take the the resource record field and then they just reuse various components of it because so it can still be parsed easily there's a name but it must be empty so the name is actually blank it's a null name basically uh the type value is 41 that is the opt type code assigned by an ayanna there's a class so instead of putting in class which i said was internet before for most resource records it actually transform it into the udp payload size instead so you get 16 bits to say this is the maximum payload size that i can accept please don't send me anything bigger than that the ttl which is normally 32 bits of of how long you can cache data turns into three different fields there's an extended response code which is the other eight bits that i talked about and a version field which should always be zero that's the ed and s0 version field with specification for the for the opt extension and 16 more flag bits which are some of them which are now used and then everything else is just tag attribute value pairs and variable lengths and more multiple things can be added so you can have multiple extensions exist within one op field so what happens one of the bits um in the original thing is is the response is um i'm sorry one of the the original bits in the original header is called the truncation bit and it basically says you tried i i can't send you as much information as you asked for you're gonna have to you know come back with a different question a smaller question or a comeback over tcp so with a bigger payload size so this happens for example when the opt uh resource records max message size was going to be overflowed so the first thing that happens is the truncation bit is set and then different implementations do different things um some try and remove the unimportant items and shift the rest of the information back so hopefully you get at least something some servers actually drop everything and just tell you to come back over tcp and note that uh response rate limiting is a ddos defense that is commonly deployed these days that uh triggers the tc bit if you start asking sort of the same question over and over and over from a single address because that used to be used heavily over udp to do packet reflection and that's actually stopped a lot of the packet reflection attacks anyway clients have to come back over tcp to get the full answers it turns out that jeff has measured that some of them don't they they got enough information that they saw in the answer and they didn't need to come back to get the rest all right so what happens if you get more if you need more errors uh the just the response codes themselves aren't necessarily always enough uh what happens if you have you know like multiple errors or two exist or you want to augment some debugging text well uh what if we actually kind of stuck that data somewhere else too uh so coming up soon as an extended error so there's another uh opt resource record that goes inside the opt research record which means that we have the header with the first four bits the x the opt record with four bit with an additional eight bits and now we're putting other errors inside of that so it's really errors all the way down you sandwich stuff into protocols where you can when you need to extend them so let's dive into some of the other resource record types the opt was a special case but let's look at the more normal ones for a bit so resource record types the obvious ones most people know most of these there is a a record which is an ipv4 address there's a quad a record which is an ipv6 address there is a soa which gives sort of some zone information and it's at the tip of the apex and it talks about negative caching and a bunch of other stuff in the serial number of the current zone and things like that i won't dive into the details uh there's a text record which is really just a free-form text blog we'll talk a lot more about that one in a second but first let's talk about happy eyeballs which is 8305. so happy eyeballs you know people realize as we're trying to deploy ipv4 and ipv6 how do we decide which you know address family to use how do we you know deal with the fact that users really don't want to wait a long time so you can't you know query for v4 and then wait and that didn't work so then go to v6 or vice versa so the solution is we're going to follow this step we're going to go send a quad a query out to say hey where is www.example.com and the resolver will start chugging away at that at the same time the client is going to send another request immediately thereafter it's going to start with v6 and then it's going to send another one saying oh and i want the i want the a record too the ipv4 record too uh just give them back to me when you got them and that resolver is going to work on both of those at once and then it's going to then your client should wait for the answers from either query if the response that came back was a ipv6 record and quad a record you get to open the connection yay we're done if the response is a is an ipv4 record an a record then you're supposed to wait a bit like 50 milliseconds is what the document recommends for a quad a record and if you don't give one get one then you just you know give up and continue with ipv4 you know with sadness but either way you profit because you have a dual stack deployment that actually is able to do both and you do them you know in flight at the same time with minimal delay the other common thing that is frequently misunderstood is how to properly use c names and d names so c names are really aliases for other portions of the tree uh they can be in the same zone or they can be in a different zone and d names are aliases for the zones themselves sort of their the entire zone so here's an example of a cname record in red the top line which is js.example.org with a ttl of 3600 seconds is a cname to javas.example.com so it's pointing from one zone into a completely different zone saying if you want to get to js.example.org you should really use this other name a lot of resolvers will also return the address for the other one too if it's within zone or they know it a d name on the other hand is aliasing an entire zone so it's aliasing one apex to another so example.org may say well i actually you know just if you come to me i really want you to go to example.com where alias is for each other so anything inside of me should go over there important rules c names must exist at a alone at a name it shouldn't have other information and you know associated at the same name except for dns sec records which sort of uh change that a little bit and then c names point to all other types you can't just have a c name for just an a or a quad a record if you have a c name it points everything to the other name that includes name servers mx records serve records you know anything else that might exist text records um mx records are mail exchange records and they really kind of answer the question where should email for a domain name be sent it's a prioritized contact list of where mail should be sent and so they can exist at you know leaf nodes so for example www.example.org has this long ipv6 address it all uh it doesn't have this this one in red but it's an example of pseudo example um we're saying instead of sending the mail to me because i actually am not a mail server i want you to send it to smtp.example.org instead so this other box is going to handle mail for me you can also it's very very common to have you know if you have wes at example.org where does that mail go and you know the mail server doesn't exist typically at the top level the apex of the zone now it is handled by something else but more importantly it can be handled by a completely different zone it's very common this is how outsourcing of mail happens when organizations outsource their mail to some mail provider of which there are you know many and in fact that's much more common than hosting your own mail server these days and this is done with mx records wild cards uh nobody seems to understand and get right i'll be honest i don't use them much myself because they can be kind of complex but if you go read rfc 4592 you'll find it's actually very clean and very well written much better than the original text but it generates responses for missing data the leftmost label must be an asterisk and only an asterisk you can't have fu star or star foo it has to be star dot period end of end of sentence it matches any label that doesn't exist underneath it including sub-labels underneath it it causes a name server to synthesize an answer should be an answer not and answer it synthesizes an answer on the fly and it'll answer for anything the client asks for there's really good examples in 4592 i've included some down below that are sort of the minimal ones but 4592 has much much better ones including what happens when you have a label against an empty num terminal using a term from before so in these two examples are star.example.com which says uh for an mx record for if anybody asks for an mx record in star.example.com i want you to return mail.example.com unless uh that record already had an mx record associated with it it doesn't uh wild cards don't overwrite existing things so there's some example responses down below where the mx records match for either one because neither one of those hosts had an mx record by default but asking for an a record never matches under underbar labels are another uh was there a question nope underwear labels are another thing that has been really popping up a lot lately in fact if you look at the rfc numbers it's 85 5 2 and 5.3 they're much more recent rfcs um a long time so the right thing to do is when you're adding new information to the dns a new type of information is really to create a new r type um you can ask guyana for one you need a specification i think it has to go through expert review it doesn't have to be an rfc if i recall and uh but they're slower to deploy it's slower for resolvers actually understand them immediately because it's just a number it's actually not necessarily a name and uh almost everything can understand them immediately but it's harder to put into his own file because there's not a when you're writing dns records there's not a name you can associate with it so you have to put in something strange like type one two three six or something like that um but so people started putting in text records instead and and it became a little overwhelming because they were putting text records in at the apex of zones we had some for spf and originally dkim and domain key and dns ownership verification which is used by google and facebook and docusign and a bunch of things well these all end up a text record at the top of the zone the apex of its own and you can imagine when when things go off in query for these that packet's getting bigger and bigger and bigger the more you know people try and stuff in there so the right solution we decided was to use a new um was to use a to reserve under bar as a prefix to special case names so that instead of using spf at the apex of his own it should be underbarspf.example.com it's considered a special case and resolvers and authoritative servers are beginning to deal with them a little bit especially as well um but the the top example on the bottom four there is sort of the right new way for spf you're not supposed to put it at the apex you should put it at underbar spf.example.com and there's a whole ayanna registry that contains all of the underbar labels that have been uh defined today under our domain key being another one for dkim underbar25.underbar tcp you'll see those types of things as well as underbar tcp for referring to specific things for a particular type of service uh service host discovery for email example is an example of the last one where you type in your email address into a smart mail reader and it can actually go find all of your settings for you by by looking up under our imap s dot under bar tcp to figure out where your imap server is so the client actually doesn't have to know it uh in summary dns is a globally distributed identifier database um the important takeaways here note that it is distributed it it you know it is owned by the entire world and there's this big network of who owns different sections of the tree and delegation happens the amazing thing to me is that how in the world did this scale so well that we are handling this much infrastructure all over the world and uh it works you know almost continuously yes there's been some outages but it's amazingly resilient um i don't i have no idea how it scales so well i have an idea let's go ask jeff so jeff is going to dive into uh that next right jeff that's a theory um error screen and uh we will now talk about how it scales or not um if someone can give me a screen you should have it there's a screen share button in the upper left thank you so um good morning all um it's not even five o'clock in the morning oh my god and i'm awake oh the things i do for the ietf um behind me is all black it's not a coincidence um so this morning i'm going to talk a little bit about how the dns has actually managed to scale and what's going on behind the scenes how do we engineer resilience into the dns and as usual i make the tools that we have to actually engineer resilience is actually really simple it's just replication if a doesn't work choose b now some ways you can go well let's ask a and b both together it's just a race who cares the first one wins b's hanging around in case a doesn't answer and the other way is a little bit slower but certainly tames the system down in terms of noise ask a wait if you get no answer after a while ask b in the one case the first ask everyone it's really snappy and fast but it overloads the system in the second case you actually put the the onus on the end user the one who's serializing the requests the system is under less strain you end up using all of these resources if you have to as backups for the originals but the order in which you do it and the amount of strain and stress you put on the system and the time you need to actually execute that differ according to each of these approaches so of course if you're considering this um you really have to think about what does a unitary dns look like with absolutely no replication at all and you get back to to wes's slide that here's this end result this stub resolver at the end it's configured with one recursive resolver out there somewhere that does all the heavy lifting and that recursive resolver at least at the start doesn't know anything other than a root zone priming query so it asks authoritative servers where should i ask to find the answer eventually it finds the right authoritative server there's only one of them too gets back the answer and sends it back to the user so this is a unitary dns the problem with the unitary dns where every stub resolver has only one each stub resolver uses only one recursive each domain is only served by one authoritative server with one address ipv6 or ipv4 pick one and each recursive resolver only sends a single query the problem with that of course is you can touch any part of that and it all falls over so you have these massive numbers of multiple single points of failure if your recursive resolver stops answering it's too busy it's decided that it's a sunday whatever the reason your toast equally that one authoritative server if it fails everything fails in terms of all the zones that it serves and even down in transport because it's udp and every datagram is indeed an adventure then if you don't get the answer what do you do and so each of these single points of failure make the dns incredibly vulnerable to not even hostile attack it's almost casual vandalism would take out huge amounts of the infrastructure so this kind of model doesn't work i mean it just simply cannot work in any real sense and so so the answer is just simply pump up the number and so your stub resolver there's only one u might be configured with a number of recursive resolvers now each authoritative server might actually have a number of replicated authoritative servers and obviously the spaghetti on the right is what happens when things go sort of badly awry because the theory is you can ask any of these recursives or all of them at once if you're feeling adventurous and each of those recursive resolvers when it's trying to find an answer from an authoritative name server could ask one or two or all of them and so you can send up with a massive cascading set of messages and so the issue is where can you put it and why um most systems use resolve.conf or an anagram thereof this is an original unix-based construct actually in the resolver library but most systems have some kind of configuration option for your stub resolver if you actually look at the man page for resolve.conf which is is not a bad example point what you actually find is stub resolvers will be typically configured in resolve.com with the addresses of up to three recursive resolvers you can add more but not necessarily a good idea now in a dual stack world if you actually use the name of those recursive resolvers they actually have ipv4 and ipv6 addresses and the libraries will discover that now resolve.conf actually claims that those queries in the in using those protocols are made in parallel well i'm not exactly sure that's the case um often they're just simply made in order but if they have v4 and v6 you'll send out both queries at the same time well paste by 10 milliseconds at once which i don't think happens um the order in resolve dot conf is usually important and so if you have um resolver a resolver b resolver c normally you will find resolver a is is hammered resolver b is only used if you don't get an answer from a resolver c is only used if the other two are dead on dead on arrival or whatever so that's usually the case that order is important although i have noticed some pieces of application software including the chrome browser at some points in time uh started doing round-robining there's nothing wrong with round robining it's just what do people assume when they put stuff in resolve.conf is are the others backups for the first or is everything important and the other thing is when do you use those next ones it's either a udp timeout which is most typical you're asking a question you get no answer i'll go and ask the next one but sometimes you actually get an error code and in particular serve fail that says you know i didn't answer because i didn't want to i failed i i didn't fail bad enough that there's no answer but i failed enough to tell you i haven't got an answer for you go try somewhere else so either timeout or serve fail sends you on to other resolvers in resolve.conf what about authoritative servers um it's certainly fashionable to use more than one authoritative server and the root zone is a typical example it had 13 for the anachronistic reason these days that you could stuff 13 names and 13 ipv4 addresses and fit the entire priming query answer of these 13 names and 13 before addresses into one packet no larger than 512 octets but that was a different age in a different world as soon as we added v6 to the root zone that doesn't work anymore so 13 is a very very big number these days most folk use between two and four if you actually look and sort of comb the world's authoritative servers one way or another it's rare to find four or five hundred authoritative servers and indeed insane because you can't put them and list them in a response packet and equally it's kind of brave or or should i say foolhardy to simply have only one most of the time except for any cast and we'll get to that later um so the rule of thumb um which in this case is not a bad rule of thumb five is probably you know too many and larger than five is probably you know way too many and one is certainly too few now when you have all these authoritative servers do you always hammer the first or do you round robin well it's up to the recursive resolver it's up to the the query out not the server and it may round robin it may not it depends on who what's going on here the list itself that the authoritative server gives back when you ask for an ns record and it sends back a list you might get the same list all the time the server itself might rotate that list of servers because it wants to display the load across all of them so when you've got authoritative servers one is too few 13 is probably excessive somewhere between is probably good enough most of the time what about resilience in transport itself well we use udp for the dns and resilience and udp are not things you often say in the same sentence in fact you never do because it isn't um all bets are off now the issue is of course that when udp dies it dies silent oh i'm dead no you don't you just nothing happens crickets and so what the udp sender actually uses is a timeout and depending on what it thinks it should have got an answer back in that time period it goes well that's dead ain't going to happen now what timeout is being used a lot of these timers in a lot of this code is actually based around the behavior of dial-up modems and 10 kilobit lines 9.6 kilobit lines and to be perfectly frank we never changed anything and so what you find uh timers that these days seem like eons paleolithic periods where entire continents will move so your stub resolvers use timeout values between one and five seconds oh my god uh recursive resolvers are more with it and they typically seem to use timeout values between 300 milliseconds and up to one second happy eyeballs for example uses a biasing of only 50 milliseconds so you can see that these normal timeout periods for udp are generous uh perhaps to a fault but they're certainly very generous so what happens when you get a timeout what happens when you send a query you get no answer should you ask the same server again didn't ask the first time but maybe the second time because optimism is effective or maybe i should just change the address or the protocol if i ask in v4 maybe try on v6 or if i've got multiple addresses for that named name server i should flip to a different address for the same server or maybe the timeout says something else and i should ask a different server up to you there are no rules and of course when do you give up well the number of timeouts is typically limited and normally in resolve.com it says to but you can configure it up to five it says the man page when does people normally give up somewhere between two and four is typical so it depends on the the actual library that you're using and the way you've configured it but it will try a few times but not forever what about resilience in tcp well tcp once you've done the handshake you've got a connection and you're sending each other packets so if you can establish a section a session then normally you can reasonably expect a response or an error code there are times of course when tcp will hang and all bets are off but that's less than reasonable now if you get back an error code like serve fail what do you do again asking the same server and you've got a tcp connection it's kind of pointless because that server gave you that answer it's kind of optimistic in the extreme to expect that if you ask again you might get the same answer what if i set up a new tcp session to the same address would that give me a different answer ah that's a different question because sometimes what you get is different recursives hiding behind the same name or even the same you know protocol address and the same protocol and that happens a lot these days with compound resolver farms and so oddly enough you can actually set up a second tcp session and you may or may not see the same server and you may or may not get the same answer what should a poor stub resolver do i don't know um typically though if you get back an answer like serve fail or maybe refused you might try again even with tcp you might like to try again with a different authoritative name but you might try again on the other hand you really are thrashing at this point and maybe the optimism is unwarranted bad is bad move on with your life there are other things to do there are other transports these days and i've said the magic words here dot do and the unpronounceable doq all i need to say here at this point is that we have a very limited amount of time left um and the universe is only a finite about time left before it all decays that is probably not enough time to discuss these transports in detail so i won't so the answer is yes if more is better when is too much well none of us really know but replication certainly has its limits um what what you typically do as a client is not ask all at once you serialize to avoid flooding and clients typically limit the number of queries adding more resolvers to resolve.conf adding more name servers adding more addresses adding more more protocols typically adds time and delay but doesn't necessarily improve resilience because if you really want resilience it's not necessarily adding more entries into the replication lists that just makes life slow if the answer was no and so there are other ways we can do this which are way way better the first the dns would collapse if it didn't do it is actually caching so the dns queries have a strong component of self-similarity all of you went to ietf.com to find an answer but not all of you hammered that server because often the recursive resolve that you used simply cashed the answer here's the answer i received if that matches your question i'm just going to serve it here locally um and without that kind of cashing the dns as we know it wouldn't now cashing is always a bit of a balance between well i'd like to serve you the answer that's current and if i cash it for all five years it might be the wrong answer because five years is indeed an eternity on the other hand if i do case it for five years the case becomes very effective i'm like i just don't ask the authoritative anymore so the resolution infrastructure prefers to cache it prefers to keep it for longer because it can instantly give you the answer that's faster and the cache becomes more effective i take the pressure off the dns servers name publishers however want to give you the answer and if they want to change that answer they want that answer be picked up by the system so the publisher prefers short even if the dns doesn't like it the dns itself prefers long because that's what makes it work so that tension actually sits inside caches and ttls but before i move to ttls let's just understand who caches um everyone stub resolvers recursive resolvers forwarding resolvers even your browser will cache because caching is faster but it's not mandatory so who doesn't folk who don't cage it's entirely optional so what is cached um it doesn't actually catch the entire response it cases the resource record itself and its associated time to live value um what should not be cashed well as we've learned to our to bitter experience uh additional sections are generally not trustable you should not tr you should not cash those so that's a sort of a bigger should not but there are a number of other corner cases where caching is kind of interesting uh with that opt section commonly referred to as edna zero there is an option for the client to place their subnet or if the client is deranged their entire protocol address into the query and that query is passed all the way through the dns infrastructure right up to the authoritative server and so if you're using client subnet which you shouldn't the answers cache the client subnet value and the cache can only be used if the subnet value and the query name both match you can't reuse a resource record when the client subnet value does not match but you shouldn't be using it anyway so what the hell um should you cash in s records from the parent well you should really case the ones from the child because the parent ones aren't authoritative i always love the word baileywick it's such a wonderful word in this case keep your records in baileywick case from the child and you are better what if it fails dns sec validation the local recursive resolver performs for the nsx validation this one failed should you cache it well typically you do but you only serve them if the client says don't check set the checking disabled bit in the query give me any garbage you'll send back the garbage in your case what if the query has no edns extensions and the local recursive resolver knows that it's invalid yeah um dns insect records can be cached they're different records to many others because they span a range rather than an individual name so oddly enough the names that don't exist is much much larger than the set of names that are if you actually case those gaps the cache becomes incredibly effective because it starts to cache the entire zone not only what's in there but what's not in there now that range is based on the alphabetically sorted list of names so that you know that all the names between a and d don't exist so b.example.com and so on the insect record will tell you no if you're using insect 3 bad idea you actually sort the hashes of the names and perform entirely exactly the same function so insect and then sec 3 both work in this set how long do you keep them um the cache time to live the ttl which is actually given by the zone publisher says to the rest of the infrastructure you should case these names for this long in seconds now it's merely a suggestion you can ignore it you can use it but that's what the publisher said so the recursive resolver the server the stub whatever may shorten the length of that case time according to their own predilection most caching resolvers do have a max ttl setting so if you say cache this name for i don't know 20 eternities the caching resolve will go nice try i'm going to use a day or two days or some of the value that's more reasonable you can't use negative numbers of course but you can use zero and if you set a ttl of zero it says this is a one-off answer enjoy it but don't reuse it keep on asking me and of course every single cache is not infinitely sized so in some ways if the cache fills older answers may get thrown out so cash my lifetime might be a lot lower than the ttl even under high load um replication is course replication simply says if you don't like the answer a gave you try b but in some ways we can do better and use the routing system and while this was incredibly contentious at the time back then don't remember when anycast is now part and parcel of why and how the dns operates so what we do now is set up exactly the same address at multiple locations within the topology of the internet and actually rely on the routing system to take you to the closest instance of that replicated address now the beauty of this is as long as you inform the routing system you can bring new instances up on the same address or you can take them down as long as you inform the routing system what you're doing but the clients don't need to know so new instances can come up instances can be removed effectively seamlessly and the client simply goes to the closest active element that's currently serving it and so from the client's point of view serial enumeration try a try b try c god this is boring try d try e are we dead yet try f try g doesn't work i'm like with any cast you just go right any of these give me the closest here's the question give me an answer so if we can do this on servers we can do this on recursive resolvers of course and you know quad one quad two core three port four quart five quad anything even up to quad 101 and they're probably still going um often has recursive resolvers that all respond to the same address so you can do any cast in a number of places and it basically just works the other way where we have parallelism is in a slightly different sense where these days the amount of dns and the density of query often receive exceeds the capacity of single engines no matter how big the silicon and so a bit like the web server systems that we use these days we've done the same in the dns and a massive amount almost 75 of the visible recursive resolvers sit inside a subnet with other recursive resolvers that the authoritative server sees so what's going on is that a huge amount of resolution machinery is actually sitting inside farms where you have a common front end that takes the queries the service address and these workers out the back where you distribute the queries that you get to one of these workers but then goes off and actually does the query sends the answer back from or through the source address of the front end i don't even need to go through the front end i can just fake the source address and so the resolvers actually each can run their own cache and so what i've done is sort of split the load invisibly how do you split the load there's no rfc there's no standard go figure you can use the conventional five tuple hash source and bad destination address and port numbers and of course the protocol id tcp or udp and simply hash on that you can simply take the source address and nothing else if you're really willing to unpack the packet and look deeply inside the packet and pull apart the query name you can hash on that too or indeed you can do adaptive hashing where you load up engine one as hot as it will take and once that's loaded up additional names or additional queries you then load up on the next and the next so you constantly try and make the engines run hot not balanced because often as we've been told hot caching is more effective than balanced low valve low level caching so that resolver query farm distribution is actually an interesting question because if they're all they've got independent caches then q name hashing is really effective because all the queries for the same name go to the same engine but what about insect what about range well that doesn't work because if you're trying to cache a range and you're doing q name hashing the query will get sent to a different of these farm engines rather than the one that actually holds the insect record if you've got independent caches ip source address hashing is more efficient than five tuple because if the query the stub resolver is constantly changing the source port address you might find you're going to different machines again and again and again and you're actually using every single engine is actually running in the long run the same case replicated which is less efficient but that might be what you want and there are certainly mechanisms that share the case across all these resolver farm entities using some kind of multiple of broadcast or multicast technology to maintain all of them with the same cache but of course that's challenging to implement reliably so all of these mechanisms have strengths and weaknesses there is no rfc standard about this go pick your favorite solution and deploy it and for that joao will help you because that's his job to talk about that thanks so i'll spin this over to joao okay thank you jeff let me see if i can publish the screen publish the screen yes okay you can see that now i think you can if only if only i could switch on video as well i'll get the hang of these one days okay so hopefully you'll be seeing this i cannot see the comments because i just went full screen um my my last my section will be shorter it's just an overview of uh if you wanted to play with this whole thing that was being talked about up to now where do you get go get your toys so according to what they do what role they play different pieces of software classified in the dns have stop resolvers forwarders recursive resolvers authoritative servers and things that do it all or at least more than one function uh picking uh was his previous diagram so that you can relate to what he thought in an easy way let's start with stop resolvers these are the things that rely that living end end nodes in laptops and computers perhaps inside browsers or other applications initially they came into existence as just another part of the bsd unix api and the calls that were used and that is still in use were ghost get hosts by address by name that was 10 set hotel functions they appeared in 1983 in 4.2 bsd which incidentally implemented the dns that was specified in rc882 and aa3 which is not the current version of dns so they actually this api calls predate modern day dns which came into existence two years later uh it's they are still the most used frequently uh mostly frequently used uh calls in when you're working in on unix but other assets have these and some other layers of abstraction on top so windows has its own mac os ios have their own [Music] you can also get different locations there are more modern implementations one of the most complete ones is get dns which you can download for the source it has also a stub implementation that goes with it called stubby and provides a lot of language binding so you can use it from different programming languages uh it includes for instance things like local dns dns validation which is useful to bring that functionality closer to the application not having to rely on on other pieces of software to do it um as someone already mentioned the in this in in the chat linux introduced recently the systemd resolved service uh people have been beaten it's still early days for these um it has the advantage that it comes bundled with the system and so if it starts it you you already have a local resolver which has its advantages and disadvantages it depends how you use it but right now it's it's slightly mature um some apps do have their own stub resolvers built in these typically web browsers that want to speed everything up as much as they can so they they have their own built-in cache and they've run their own dns queries separately from what this the operating system might be doing interesting uh these days uh with the expansion of uh how dns is being transported and handled uh there might be room for the appearance of more modern apis or different looking apis and one of these which is uh kind of only considered right now as a transport which is like though of dns over cdb actually for web people will look a lot like a web rest api with some opaque blog of data but well you know there's a potential to develop a completely new api or that or even a new dnx moving on forwarders these sit uh typically on home routers or perhaps at your isp forwarders falling between stab resolvers and recursive resolvers both in where they sit in the network and what functionality they provide to the network uh they have some features that usually are typical of recursive results such as a big local cache but they don't usually perform the recursive lookups themselves rather they receive them from the nodes behind them that send them queries and they forward them to a full service recommended resolver so that's basically why they are called forwarders typical implementations of these the most famous the most used worldwide is dns mask a piece of software that's produced by uh simon kelly in the uk and it's this software is very very popular uh because it got picked up early on by uh route manufacturers rather home hardware home router manufacturers and it got dropped in and most a lot of people actually use it without even knowing right it has an advantage for that that kind of uh embedded device that has limited resources because it also includes a dhcp server and those two functions the hpp and dns are something that every home network needs but it has been evolving and for instance it's been supporting the asset validation locally since 2014 so you might actually have that supported in your home router by now um other implementations include things like buying bind you'll see repeated everywhere because this was the first kind of reference implementation out there and perform all the functions so it comes up a lot mara dns is another good implementation a common setup that you see that you didn't use to see earlier on at isps is the use of forwarders so people other sps need to provide dns services for their customers it's typically been one of the services that isps provide but they don't want to have the hassle and of having to cope with the load that comes with the recursive resolver with a lot of clients so they configure for instance things like bind as pure forwarders and let other open dns resolvers take care of the work for them typically these are the open dns people are the quads the ones the ones the 101 which is of course run out of a101 uh moving on the next uh set of functionality are the recursive resolvers okay so these are typically either at isps or enterprise networks which are kind of isps for only one company um and the open cloud resolver that you see these days being quite popular all across across around the world um as as there has been some discussion uh already in the chat um it's not entirely a complicated thing these days to run your own recursive resolver in uh in your own computer and some people argue that that's a good thing to do um in terms of privacy because you don't get the other the networks don't get to see all of your queries because you you can hide them um but still the most common case is that you send the recursive resolver is run by sp and you send your queries through a forwarder or directly to them um the software used in these in these deployments is is a mix usually of open source and proprietary software sometimes open source hiding behind a front end that's for friday that's not not unusual and uh and since google started doing their quad thing uh years ago there are more and more of these coming up and there are also commercial services like opendns that will provide not only dns resolution for you but also sort of filter dns resolution [Music] the recursive resolver is as a concentration point in dns in the dns processes is also frequently a control point sometimes with good intentions there might be malware detection that prevents some queries to generated by bots to to be go for any further but not always for good things so you see these uh the recursive dns servers are commonly being targeted as the place for censorship occurs or that that that collection um some of these seeds that we are used to control uh are proprietary most of them at least there is one that's being defined uh on the idf at the idf so that's at least you can get a picture of how they are used implementations themselves open source the typical ones are the ones listed there by far the most commonly used uh in uh pro in closed source versions uh some of those for instance cq64 uh infoblox uh are front-ends for uh open source implementations others are fully developed uh in-house by the companies that are named there and the last piece the last missing piece is the the origin of all the dns data the authority servers the publishers as we were referring to them earlier in principle their function is pretty straightforward you load what's used to be a zone file can be any sort of database and then surf based on the data that's in there don't do anything there else don't be more creative just read write read from the disk right to the network but of course people have been using dns for 35 years and the scenarios where people use the dns go way beyond a simple scheme of uh arrows like the one we are presenting here so enterprises have their own roots they have their own dna view of dns to the inside and the outside which is different uh so the authority dns servers have grown in what they do in terms of functionality they do split horizon basically showing different view of dns inside your network and outside they control who sees what and when they will these days give you often give you different answers based on which isp you are coming from where you are coming from in the world trying to most normally trying to direct you to the content delivery address that's closer to your service sometimes not quite getting it right but trying at least and it's a place where there has been a explosion of features both at the protocol and the application level uh storage backends that used to be uh what flat zone files text files and now can be very diverse and so use sql databases anything you you can think of traditionally dns authority servers have always also been open source uh and the names there for your reference but they are also closed source some of them you see open internet the microsoft version of the dns server authority server you see normally inside enterprises that use active directory active directory is based off an idf rfc and uses the dss dc mechanism but microsoft managed to really hug it closely and then extend it and it's slightly incompatible with active directory even though for things like buying have a gss txc implementation if you start using too many features you won't be fully compatible then there are other bits of pieces stuff that gets thrown into the network because the you want to scale you want to do different things right um one of these are dns load balancers jeff already talked about that how do we scale how do we offer increased resilience some of them to be honest are loaded into load balances that were meant to be doing something different typically http load balancers and initially had dns implementations that were more thick in the list of requested things than proper implementations of course with time everything gets better there is one that i like all your attention for which is the nsds produced by the powerdns guys i think this is the best example of software for the dns by the dns people people who understand the dns intimately and produced a load balancer that takes full advantage of how the dns works and this is one of the cases where they want for they actually analyze for instance what makes a cache good and implemented uh for an algorithm that makes use of them and some of them just use routing techniques you can do that with your routers with which is outside of the dns but for the ns benefit uh in the not so good part um there are dns interceptors people do things with the dns because it's a control point as you said before and this can range from simple things like captive portals in hotel networks that when you try to access the network will intercept your dns query and send you off to the registration login page to censorship to other things this is it for part one of the deep dive we wanted to tell you a lot more dns is one of these protocols that looks simple but then in real life it gets complicated really quick and so there has been a lot of misunderstandings we wanted to have a section on myths and misconceptions but we couldn't fit it in these 90 minute sessions so hopefully if there is a part 2 we'll go into that part and do both as an implementer as our protocol developer elsewhere in the itf things that people get wrong things that people think are one way but turn out be sometimes simpler sometimes harder and that will be left for part two in the meantime uh warren already published in the in the chat the link to the survey we would like to find out what you thought where we can do better but there is the link again and that is all for today's session uh we can start the dialogue with everyone please if you have some and or put them in the chat and we will try and try and answer as many as we can get here as you can tell we're running low on time there must be some questions warren it wouldn't be the idea if it wasn't but you know some reason you know we've stunned them well the mistake was you didn't ask for complaints yeah that was that was by design i'd been to an ietf meeting before um and it's possible that you covered everything perfectly is that a completely understandable manner i would be surprised um yeah they have also been questions during the during the chat which have been answered ah there you go jeff um i said eating s0 client subnet and if you actually read the rfc about this you actually find a preamble from which i think was suggested by the the iesg that says this is a really bad idea but we don't actually understand how to unpublish it why is this a bad idea um part of the issue is that if i saw your dns queries no one else's if i saw your dns queries there's nothing about your life i couldn't know because the dns is everything and and the way the dns hides this astonishing privacy leak is that each query as it moves from stub to recursive to authoritative loses the identity of the end party that started this in the first place all the authoritative sees is google's asking me questions cloudflare is asking me questions comcast isp is asking me resolvers are asking me questions but they don't know who now if i include the identity of the end user there's no secrets anymore that's really bad and everyone can start assembling profiles that's incredibly bad so why these folk doing it why are they butchering your privacy well the answer was actually in response to these anycast clouded servers open dns resolvers that if you've made the cardinal sim to use the dns as a geolocation steering mechanism which was the silliest idea known to the dns part of mankind ever if you overload the dns with such geolocation steering then these massive open resolvers make the the resultant service run like molasses you might be in australia like i am but you might meet a redirected to a server running in estonia because that's where the open dns resolver sort of thought that it configured itself when it gave back a geo answer and so edna zero client subnet has been useful to actually respond to any car services but the cost of that is incredible privacy leak i think that was a step not just a step too far but a gigantic leap to too far because of that privacy leap problem others might be a little more benign to it but it is it is in my view and a totally personal view a hideous mistake [Music] things i would say it can be lessened if it's configured right um you don't actually need to send a slash 32 ipv4 address to the resolver right actually i believe that the rfc says goat exactly it says minimum of 24 i believe is what it says but it's been a while there have been presentations warren that explicitly talk about how often the don't is ignored well there's a comment in the chat that said it's limit to a slash than before well you'd be amused what you see once you start looking at dns anyone else um because the question is speaking of privacy what are your views on q name minimization and certainly the case that the dns is incredibly chatty because when it asks and does the discovery of who are the right name servers for this zone like you know www.example.com it actually sends the full query name all the way down from the root service and part of the issue about root servers and the amount of information they see what they see is actually full query names now in terms of a privacy leak again you couldn't get much bigger and it actually doesn't make the dns any better um the issue about why the full query name was always included is you didn't know where the zone cut was so you actually asked everyone the full question because if a zone actually had a.b.c.d.example.com if you sent the full query name to the example.com server it would just give you back the answer but the cost of that implicit efficiency was a huge leak in terms of privacy and be perfectly frank um it was a step too far in retrospect so i think qna minimization is brilliant personally and just a quick clarification for those who weren't paying attention all the way through the presentation because lots of people miss this um it's only cache misses that get sent to the root and then only cache messages that get sent to dot com etc um lots of people but that's because they refuse to use one uh that's a completely different problem uh one let me back up one sec which is that uh to to be double clear that people got uh jeff's point he's talking about ecs uh edness zero slash the opt record i posted a link to uh ayanna in the in the meet echo chat there is a lot of extensions that make use of it and so he jeff is not saying edf zero is bad he is saying that that ecs he has issues with uh so dude you know there's like 15 actually there's a lot more than i even realized there's a 17 currently assigned uh specifications for eating a serial slash opt sub components that we are shoehorning there are some there are some subtleties there whereas and i suppose now is a good time as any to sink the slipper into a bit of v6 one of the issues around the eating s0 udp buffer size was actually promulgating the fact that if i can reassemble a 4000 octet message in dns then obviously the path between me and you can equally handle the fragmentation of the udp packet to send those 4 000 octets and part of the issue is ens00 isn't path mtu handling but it gives you the fiction that it can and what we're finding particularly in v6 because extension headers and fragmentation combined on the public dns make a hideous story of packet drop is that it actually might be worthwhile particularly with v6 to never send a packet larger than 1280 octets irrespective of whatever eatiness zero buffer size you might be able to handle and and so realistically in some cases the unbounded optimism of 4096 octets in edns zero buffer size is unfounded and you'd be better off being way more conservative 512 year will work 1280 yeah it will work 1500 yeah may not larger than 1500 and v6 so warren do you want to pick one of the other questions um i guess so um so pete resnick asks does keda or jeff or anyone else do measurement of how much or how little mechanisms like sending the whole name or having recursive servers help with performance the global dns we did do q a minimization as an experiment late last year and started to measure how much of it was around and it was actually quite disappointing in some respects that we thought it would be you know 70 80 percent and it was a lot less than that do you remember the answer joao or do i quickly need to go and find it i think it was around 30 not more than that yeah and so everyone is actually saying we support this but oddly enough when we try and do a measurement that aims queries in and we actually see where q name minimization should happen uh there's not as much of it as as we thought which is disappointing so as a follow-up to that victor actually posted a comment further up up in the chat that q a minimization does however run into bugs with poor implementations of empty non-terminals um which is that's true that is getting better so possibly qna minimization deployment might also be getting better um would somebody like to explain what um empty non-terminals are i did explain what an empty num terminal was it was in my slides label in the foreign of the zone with no data added because i that's one of the common misconceptions i think of dns is that you can't have that every every dot has to be a new label you know when you're at or a new sub zone when you're adding stuff and so i i did have a diagram that pointed to a label in a zone that had nothing else but sub stuff underneath it and that is in a genome terminal you know tina i actually started measuring key name minimization at usa isis root server and i need to go back and finish it because i did see a the beginning of a ramp and then i haven't measured it since and that was like a year ago so i suspect that it's actually done a lot better lately uh taking a while to get deployed yeah there's a question on synthesizing records of the apex unfortunately we push that one to the part two thing uh hopefully that hope that happens because there's always questions of is that legal is it is does it work even if it's not legal and there are combinations of those things um hopefully we get to do that on part two because well for q a minimization it's three percent the folk the folk who do it live in madagascar iran nepal belarus angola um it seems that the larger resolvers are way way more conservative about innovation and putting new features in their software and what we are finding is that resolvers that live way out on the edges where they're a much smaller client client being served actually do more of the leading edge or bleeding edge of software than everyone else so q name minimization three percent g now of course this was uh a year ago august 2019 and obviously it's got a whole lot better since then totally yeah big difference dns always get better yes always up and to the right know what your timeline plans are i guess we are at the time uh for everyone who thinks that it would have been better than meeting madrid i am actually in madrid it's 37 degrees 77 degrees centigrade outside bound to go to 39 over saturday and sunday when the idea would begin so perhaps it's not an entirely bad thing that this got moved to november next year i would have enjoyed the mic line i missed the mic line of people wanting to yell at us so uh thanks for everybody attending and for those who live in places without a sane measurement system that's 102 fahrenheit thanks guys so i'd like to thank all of the presenters for this um oh thank you for everyone as we mentioned beginning um it turns out that dns is a huge topic and so and also the amount of confusion around dns is an even larger topic um so we are planning on having a technology deep dives on dns part two and possibly three and 27 and 46 please do fill in the survey i will paste the link to the survey once more unless somebody beats me to it and thank you very much everyone um see you in bangkok or the virtual bangkok how about next week lauren we'll see each other next week remember there's an atf week this is not the end of the this is the beginning of the 18th oh i was hoping it was done yeah that's true i'll see you see you all um at the next few meetings including at the ietf plenary all right bye thanks a lot bye and now does anybody know how to terminate any echo session oh no i'll just let you deal with it your problem i'm leaving bye

Channel: IETF - Internet Engineering Task Force

Views: 5,439

Rating: 4.9708028 out of 5

Keywords: DNS, IETF, IETF108

Id: DV0q9s94RL8

Length: 92min 25sec (5545 seconds)

Published: Thu Jul 23 2020