When are NS records at the apex of a DNS domain queried?

When are NS records at the apex of a DNS domain queried?

Lets say, that I have a following example.com zone: TTL 120 IN SOA ns1 hostmaster 2018041509 300 150 600 60 IN NS ns1 IN NS ns2 ns1 IN A 192.168.0.159 ns2 IN A 192.168.0.160 blah IN A 192.168.0.141 As seen above, ns1.example.com and ns2.example.com are two authoritative name-servers for that zone. When are they queried by other name-servers As much as I tested, the only time when those two records were queried was when I asked for NS records from 192.168.0.159 with a DNS lookup utility, i.e dig 192.168.0.159 -t NS example.com.

For the casual user, it really shouldnt matter. If what youre after is consistent delivery and uptime for your domain, the rules are pretty simple: The NS records on your nameservers should only point at A and AAAA records. not CNAME records, etc. Make sure to include IPv4 addresses A records, or it will not be possible for DNS servers running single-stack IPv4 to obtain information about your domain. The names and IP addresses of those nameservers should match how your domain is configured within the registrars control panel. Thats it. The how and why of the implementation doesnt matter so much. If you diverge from this recommendation, the result will be a great deal of inconsistent and unpredictable behavior. Scary phrases such as undefined behavior and implementation specific behavior both apply here. With that said, the question being asked by the OP is a completely fair one. Excluding explicit requests by clients and excluding indirect referencing within the authority section of other answers, when are these NS records explicitly requested by recursive nameservers Youve inadvertently walked into one of the more ambiguous areas of how recursive DNS servers operate. To the best of my knowledge, we still dont have an amendment to the governing Internet Standard clarifying how this is supposed to work. A high level overview of how a recursive DNS server learns about your domain goes like this: Recursive server gets a request for www.example.com. IN A. If this DNS record is in cache, it is answered from cache. If the DNS record is not in cache, it needs to find a nameserver which can provide the answer. It starts by checking its memory to see if it has already identified nameservers related to the domain. It will consult the nameservers for the most specific zone aka domain it is aware of. If referrals for more specific zones are encountered, those referrals will be followed until a server identifies itself as authoritative for www.example.com. IN A. or until an error prevents it from following the path further In a cold cache scenario imagine a freshly restarted DNS server, it would have to start from scratch with least specific and work its way up to most specific. For our example of www.example.com. IN A, it would to follow the following set of referrals: .: AKA root nameservers. com.: The Top Level Domain nameservers for com., learned from . nameservers. example.com.: The nameservers listed for example.com. in the com. registry, learned from the com. nameservers. www.example.com: This happens only if the example.com nameservers provided a referral to a different set of nameservers for www. For this example lets assume thats not the case. Our answer for the A record will have come directly from the nameservers for example.com. Each step along this path, the recursive server asked if these servers were responsible for www.example.com and received a referral to a more specific set of DNS servers. At no point in this walk did we need to ask for the NS records. We learned about the more specific servers through referrals until one set of servers finally replied with an authoritative answer for www.example.com. in this case, the example.com. nameservers had our answer This is where things get weird. The NS records we have in memory at this point were learned through referrals. For the purposes of the nameserver this is good enough, but we now have two problems: What happens when the TTL associated with the NS records in the referral expire What happens when someone asks us for the value of these NS records Well explore each of these. The TTL of NS records learned through referrals has expired. Now what This is where nameserver behavior diverges greatly. While it has some age on it March 2011, I strongly recommend reading lafur Gumundssons presentation that covers the topic. Slides 11 - 13 introduce us to several patterns of nameserver behavior. Im going to borrow the same terms from lafurs presentation: Child Centric non sticky: PPPCCCPPPCCCPPPCCCPP Child Centric sticky PPPCCCCCCCCCCCCCCCCC Parent Centric PPPPPPPPPPPPPPPPPPPP In this instance, parent is referring to the NS records that we learned of through the referral. child is referring to the NS records that we learned through the authoritative answer we receive when we query the first set of NS records for the value of example.com. IN NS. i.e. when we are asking those nameservers to return their own NS record...in theory The commonality with all of these patterns is that the NS data in memory is first learned from the parent. This is a given, as its fundamental to how the process works. Where implementations differ is what they do afterwards: Child centric non-sticky will initially prefer parent, then swap to the child. Once the child expires, the NS records are forgotten and re-learned from scratch in order to provide an opportunity for changes on the parent nameservers to be incorporated. Without this, changes in nameservers related to expired domains would not be caught -- both the expiration and renewal thereof. The disadvantage is that occasionally these NS record definitions do not agree, resulting in the recursive server returning different responses for a specific DNS record i.e. www.example.com. IN A depending on which servers it is currently hitting. Child centric sticky is a very problematic implementation where the nameservers get stuck on the child side of the definition and the parent side is not re-evaluated until the cache is purged or the server is restarted. It is generally considered to be the worst of these implementations due to the very obvious problems that are associated with it. an example would be this QA where someone is observing the behavior Parent centric is an interesting implementation that eschews the value of the childauthoritative NS records entirely. The general idea behind it is that alternating between the values of the parent and the child cause much more trouble and confusion than its worth. By ignoring the authoritative version of the NS records completely and always preferring the referral without which its not possible to learn about the authoritative records anyway, you avoid the flip-flop problem of child centric non-sticky entirely. The main disadvantage are some edge cases where the NS records from the child side can help expedite a migration off of old nameservers prior to the change being made at the registry. This can can be beneficial when youre dealing with certain boneheaded registrars who also provide DNS services, but immediately kill all of your DNS data when you change the servers for your domain to point somewhere else. As you can see, this is a complicated topic and one that is extremely difficult to document without extensive testing. It works this way because the standards remain loose in this area to this day, at least to the best of my knowledge. What happens when a client asks a recursor for the value of NS records Once again, it depends. RFC 2181 strongly discourages nameservers from returning cached nameserver data learned from referrals in the answer section, but does not outright forbid it: should not Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse. ... Note that throughout this document, authoritative means a reply with the AA bit set. Despite this warning, we can return the NS records observed from the referral in our answer as its not explicitly forbidden. I suspect its more likely to happen with parent centric implementations, but I dont have any good data in front of me at the moment. Ill do some testing on my own when I find the time and update this answer. What happens if the server has the nameservers from the referral cached, and does honor RFC 2181 In the case of ISC BIND at least in the 9.10 and 9.11 implementations that I have most experience with, the explicit request for the NS records from the client triggers an immediate refresh against the child nameservers. Its easiest to observe when the client nameservers are pointing at something that BIND considers broken, such as NS records that point at CNAME records. BIND will initially be able to answer for the domain using the information it received from the initial referral glue included, but the domain will immediately stop working the moment the NS record request is received and the nameserver attempts to re-learn the nameserver information it needs to communicate with. Closing Disclaimer: This is an extremely vague and confusing area of recursive server operation. Some things may have changed since I last explored the topic in-depth. Im happy to amend any information provided here, but please provide specific data citations where possible.