Under which circumstances will the NS records at the apex of a zone be queried?

Question

At what point do the NS records defined at the apex of a zone are queried during normal operations?

From what I've researched these records are used by:

• DNS NOTIFY, for the master to signal slave servers to pull its SOA and update their zone files when the master changes.

• Some tools, to verify the correctness of the DNS zone definitions

• Iterative DNS resolvers, if they have cached the authoritative NS records for a zone they will use them to answers queries for that zone instead of going to root/TLD/parent servers

• The server itself, to declare itself as authoritative for its zone (though I'm not convinced this is the case, I believe that is set either externally by each DNS implementation plus the parent DNS server referral NS records and not in the zone file, or via the SOA record)

What I don't understand is under which circumstances would an iterative DNS resolver ever cache the NS records for a zone unless he receives a query specifically for the NS records of that zone

Let me elaborate. From what I understand when iterative resolver that has an empty cache is given a query for a resource (for example IN A www.example.com.), it will:

1. Query a root DNS server for IN A www.example.com.

1.1. It will receive an empty Answer section

1.2. Authority section with the NS records for the .com. zone (these are not authoritative).

1.3. It will cache these non-authoritative NS records (if it is Child Centric non sticky or Parent Centric). Though RFC 2181 says you SHOULD NOT do this.

2. Query a TDL .com. DNS server for IN A www.example.com.

2.1. Same deal as above but the non-authoritative NS records are for example.com.

3. Query an NS server of example.com. for IN A www.example.com.

3.1 Receive an authoritative answer for www.example.com.

3.2 It will cache the A record received.

3.3 It will return an answer to the client

At no point during the above exchange did the iterative resolver emitted the query IN NS example.com. or IN NS .com. or any other query for the authoritative NS records for any zone. So, from what I gather, unless some client/user of the iterative DNS resolver happens to emit the exact query IN NS example.com., the iterative resolver will never cache the authoritative NS records for IN NS example.com.

Is the above the case? or do iterative DNS resolvers implementations fire NS queries for zones for the purpose of caching their authoritative NS records and speed up future queries for the same domain? Or do they only cache authoritative NS records if a client randomly queries the NS records for a zone? Is there even a common or most popular pattern across DNS resolver implementations?

References:

• What is the role of NS records at the apex of a DNS domain?
• When are NS records at the apex of a DNS domain queried?
• https://www.rfc-editor.org/rfc/rfc1034
• https://www.rfc-editor.org/rfc/rfc1035
• https://www.rfc-editor.org/rfc/rfc2181
• https://www.zytrax.com/books/dns/ch8/ns.html
• How is DNS lookup order determined?
• https://stackoverflow.com/questions/57828833/when-following-a-referral-for-an-a-record-in-an-dns-iterative-query-should-the

Answer 1

I think there is really one main case that will deviate from your stated expectation and an additional case that is less common, both being implementation specific:

• The authoritative server for example.com tacks on the NS records to its response for www.example.com. IN A. It is not required to do so, but it can. Traditionally this has been quite common behavior.

  • Example: BIND does this unless the minimal-responses option is enabled.

• The resolver server looks up example.com. IN NS as part of following the referral. Not traditionally a common behavior.

  • Example: Unbound will do this (and more) if the harden-referral-path option is enabled.

Answer 2

See the algorithm at https://www.rfc-editor.org/rfc/rfc7816#appendix-A that deals only about use of NS records and how to use them.

Querying for NS records is necessary to find about zone cuts, which is then necessary for proper DNSSEC validation as well as QNAME minimization.

RFC 7816 on QNAME minimization says this in section 2:

Instead of sending the full QNAME and the original QTYPE upstream, a resolver that implements QNAME minimisation and does not already have the answer in its cache sends a request to the name server authoritative for the closest known ancestor of the original QNAME.
The request is done with:

o the QTYPE NS

o the QNAME that is the original QNAME, stripped to just one label more than the zone for which the server is authoritative

Using NS records that way makes the client (recursive nameserver) not share any data about the current flying request to the authoritative nameservers it is querying.

It is true that in its section 3 it explains that to go around some broken nameservers you (the recursive client) may want to try A records instead of NS ones. It is however still and only a workaround for other broken DNS servers.

Also, in a commonly shared view, the DNS is "child centric" meaning the NS set that is relevant is the one coming from the child not the parent, as it is the only recordset that can be signed in DNSSEC (referrals not being in the ANSWER section). But if a resolver does only that and recheck only at child it means a domain could never disappear or change nameservers... hence a resolver have to, periodically, check the parent for the NS.

See this draft currently being worked on: https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/?include_text=1

It has the following relevant paragraph:

Officially, a child zone's apex NS RRset is authoritative and thus has a higher cache credibility than the parent's delegation NS RRset, which is non-authoritative glue ([RFC2181], Section 5.4.1. Ranking data). Hence the NS RRset "below the zone cut" should immediately replace the parent's delegating NS RRset in cache when an iterative caching DNS resolver crosses a zone boundary. However, this can only happen if (1) the resolver receives the authoritative NS RRset in the Authority section of a response from the child zone, which is not mandatory, or (2) if the resolver explicitly issues an NS RRset query to the child zone as part of its iterative resolution algorithm. In the absence of this, it is possible for an iterative caching resolver to never learn the authoritative NS RRset for a zone, unless a downstream client of the resolver explicitly issues such an NS query, which is not something that normal enduser applications do, and thus cannot be relied upon to occur with any regularity.

Then note all following details in its section 3 about when and why the recursive nameserver should issue NS record types requests to revalidate its data properly.

Note that this document is currently being called out to be adopted by the IETF Working Group on DNS. If that happens it may then become later a full standard (RFC).