32
$ORIGIN example.com. ; not necessary, using this to self-document

$TTL 3600
@        IN     SOA   ns1.example.com. admin.example.com. (
                      1970010100 7200 1800 1209600 300)

@        IN     NS   ns1.example.com.
@        IN     NS   ns2.example.com.

@        IN     A    198.51.100.1
ns1      IN     A    198.51.100.2
ns2      IN     A    198.51.100.3

sub1     IN     NS   ns1.example.edu.

sub2     IN     NS   ns1.sub2
ns1.sub2 IN     A    203.0.113.1 ; inline glue record

The role of a NS record beneath the apex of a domain is well-understood; they exist to delegate authority for a subdomain to another nameserver. Examples of this above would include the NS records for sub1 and sub2. These allow the nameserver to hand out referrals for portions of the domain that it does not consider itself authoritative for.

The purpose of the NS records at the apex of a domain, ns1 and ns2 in this case, seem to be less understood by the internet at large. My understanding (which may not be holistic) is as follows:

  1. They are not used by caching DNS servers in order to determine the authoritative servers for the domain. This is handled by nameserver glue, which is defined at the registrar level. The registrar never uses this information to generate the glue records.
  2. They are not used to delegate authority for the entire domain to other nameservers. Trying to do so with software such as ISC BIND will not result in the "expected" referral behavior at all, as the nameserver will continue to consider itself authoritative for the zone.
  3. They are not used by the nameserver to determine whether it should return authoritative responses (AA flag set) or not; that behavior is defined by whether the software is told to be a master or a slave for the zone. Most nameserver software will quite happily serve apex NS records that disagree with the information contained by the upstream glue records, which will in turn cause well-known DNS validation websites to generate warnings for the domain.

With this being the case, what are we left with? Why are we defining this information if it doesn't appear to be consumed by caching DNS servers on the internet at large?

Community
  • 1
Andrew B
  • 31,858
  • 12
  • 90
  • 128

2 Answers2

30

Subordinate identification

Apex level NS records are used by a master server to identify its subordinates. When data on an authoritative nameserver changes, it will advertise this via DNS NOTIFY messages (RFC 1996) to all of its peers on that list. Those servers will in turn call back with a request for the SOA record (which contains the serial number), and make a decision on whether to pull down a more recent copy of that zone.

  • It's possible to send these messages to servers not listed in the NS section, but this requires server specific configuration directives (such as ISC BIND's also-notify directive). The apex NS records comprise the basic list of servers to notify under a default configuration.
  • It's worth noting that the secondary servers will also send NOTIFY messages to each other based on these NS records, usually resulting in logged refusals. This can be disabled by instructing servers to only send notifies for zones they are masters for (BIND: notify master;), or to skip NS based notifies entirely in favor of notifies explicitly defined in the configuration. (BIND: notify explicit;)

Authoritative definition

The question above contained a fallacy:

They are not used by caching DNS servers in order to determine the authoritative servers for the domain. This is handled by nameserver glue, which is defined at the registrar level. The registrar never uses this information to generate the glue records.

This is an easy conclusion to arrive at, but not accurate. The NS records and glue record data (such as that defined within your registrar account) are not authoritative. It stands to reason that they cannot be considered "more authoritative" than the data residing on the servers that authority is being delegated to. This is emphasized by the fact that referrals do not have the aa (Authoritative Answer) flag set.

To illustrate:

$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     172800  IN      A       199.43.135.53
a.iana-servers.net.     172800  IN      AAAA    2001:500:8f::53
b.iana-servers.net.     172800  IN      A       199.43.133.53
b.iana-servers.net.     172800  IN      AAAA    2001:500:8d::53

Note the lack of aa in the flags for the above reply. The referral itself is not authoritative. On the other hand, the data on the server being referred to is authoritative.

$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            86400   IN      NS      a.iana-servers.net.
example.com.            86400   IN      NS      b.iana-servers.net.

That said, this relationship can get very confusing as it is not possible to learn about the authoritative versions of these NS records without the non-authoritative NS records defined on the parent side of the referral. What happens if they disagree?

  • The short answer is "inconsistent behavior".
  • The long answer is that nameservers will initially stub everything off of the referral (and glue) on an empty cache, but those NS, A, and AAAA records may eventually be replaced when they are refreshed. The refreshes occur as the TTLs on those temporary records expire, or when someone explicitly requests the answer for those records.
  • A and AAAA records for out of zone data (i.e. the com nameservers defining glue for data outside of the com zone, like example.net) will definitely end up being refreshed, as it is a well-understood concept that a nameserver should not be considered an authoritative source of such information. (RFC 2181)
  • When values of the NS records differ between the parent and child sides of the referral (such as the nameservers entered into the registrar control panel differing from the NS records that live on those same servers), the behaviors experienced will be inconsistent, up to and including child NS records being ignored completely. This is because the behavior is not well defined by the standards, and the implementation varies between different recursive server implementations. In other words, consistent behavior across the internet can only be expected if the nameserver definitions for a domain are consistent between the parent and child sides of a referral.

The long and short of it is that recursive DNS servers throughout the internet will bounce back between destinations if the records defined on the parent side of the referral do not agree with the authoritative versions of those records. Initially the data present in the referral will be preferred, only to be replaced by the authoritative definitions. Since caches are constantly being rebuilt from scratch across the internet, it is impossible for the internet to settle on a single version of reality with this configuration. If the authoritative records are doing something illegal per the standards, such as pointing NS records at aliases defined by a CNAME, this gets even more difficult to troubleshoot; the domain will alternate between working and broken for software that rejects the violation. (i.e. ISC BIND / named)

RFC 2181 §5.4.1 provides a ranking table for the trustworthiness of this data, and makes it explicit that cache data associated with referrals and glue cannot be returned as the answer to an explicit request for the records they refer to.

5.4.1. Ranking data

   When considering whether to accept an RRSet in a reply, or retain an
   RRSet already in its cache instead, a server should consider the
   relative likely trustworthiness of the various data.  An
   authoritative answer from a reply should replace cached data that had
   been obtained from additional information in an earlier reply.
   However additional information from a reply will be ignored if the
   cache contains data from an authoritative answer or a zone file.

   The accuracy of data available is assumed from its source.
   Trustworthiness shall be, in order from most to least:

     + Data from a primary zone file, other than glue data,
     + Data from a zone transfer, other than glue,
     + The authoritative data included in the answer section of an
       authoritative reply.
     + Data from the authority section of an authoritative answer,
     + Glue from a primary zone, or glue from a zone transfer,
     + Data from the answer section of a non-authoritative answer, and
       non-authoritative data from the answer section of authoritative
       answers,
     + Additional information from an authoritative answer,
       Data from the authority section of a non-authoritative answer,
       Additional information from non-authoritative answers.

   <snip>

   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.
Community
  • 1
Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • Well written answer! I don't agree with the "long and short" of your answer. The primary use of DNS on the internet is about getting the host IP, thus "A" requests. The DNS resolvers will always accept and replace the referral to get to an Authoritative "A" Response. And he will "always" only cache the referral record. The only time the records would be replaced is when an explicit request comes in for an "example.com IN NS". Then the resolver will ask the server at the referral location. And that AR response will replace the cached referral response (only for the TTL of that record). – Wasted_Coder Jun 11 '17 at 06:22
  • I may be wrong according to the answer by @BillThor. I based my reasoning on the fact that if a DNS server refresh it's NS cached entry for example.com from an (now expired) authoritative NS response. It will break the DNS chain. Because it is now stuck in a loop where while the (old) NS server keeps on replying, it will not take into account changes on the above apex DNS server (the registrar). Like in the case you move DNS servers but not update or take the old DNS server offline. Or is this "problem" totally the case today? – Wasted_Coder Jun 11 '17 at 06:51
  • @Wasted I likewise disagree with your first comment due to the many assumptions being made. Since the behavior is not explicitly laid out by the standards, it's actually implementation specific. [This presentation is 6 years old](https://archive.icann.org/en/meetings/siliconvalley2011/bitcache/Conclusions%20from%20DNS%20Traces%20-%20Olafur%20Gudmunsson,%20Shinkuro-vid=23075&disposition=attachment&op=download.pdf) (start at slide #11), but still gets the point across; parent vs. child nameserver preference will vary. Beyond that, you can only count on the RFC 2181 requirements. – Andrew B Jun 11 '17 at 08:08
  • I think my point of concern is around if a resolver's NS cached entries reach TTL = 0 say for example.com. And it needs to lookup a new host entry also not cached yet, say for new.example.com. It now needs the NS server(s) for example.com and since it's cached copies are expired, it would be bad to still try to hit that "expired" NS server just to see if it still responds. It will HAVE to check with the next ancestor, thus .com's NS for direction. This means that the ancestor NS records would prevail most of the times (until an NS request is processed). – Wasted_Coder Jun 11 '17 at 09:21
  • @Wasted Start from slide #11 and note the three patterns: child centric non-sticky (`PPPCCCPPPCCC...`), child centric sticky (`PPPCCCCCC...`), and parent sticky (`PPPPPP...`). Child centric non-sticky is by far the most common, and child centric sticky is actually *more* prevalent than parent sticky. Clients will indeed bounce back and forth between the two versions of reality if the NS data on the child and parent are not in agreement *unless* the resolver software is parent sticky, which is the least likely outcome. – Andrew B Jun 11 '17 at 17:37
  • [This answer](https://serverfault.com/a/322524/152073) by Alnitak is also relevant to the above discussion of nameserver stickiness. We're both citing the same presentation. – Andrew B Apr 24 '18 at 00:08
3

The NS records the delegated zone provide completeness of the domain definition. The NS servers themselves will rely on the zone file. They are not expected to try to find themselves by doing a recursive query from the root servers. The NS records in the zone file provide a number of other functions..

Caching servers may refresh the name server list by querying a name server from its cache. As long as a caching server knows the address of a name server it will use that rather than recursively looking up an appropriate NS record.

When moving name servers, it is important to update the old name servers as well as the new name servers. This will prevent outages or inconsistencies that will result when the two zone definitions get out of sync. The updated records will eventually be refreshed by any servers that have cached the NS records. This will replace the cached list of name servers.

The NS records also assist in confirming correctness of the DNS configuration. Validation software will often verify that the delegating zone's name server definitions matches those provided by the zone. This check may be performed on all name servers. Any mismatches may indicate a misconfiguration.

Having the NS records allow for disconnected (local) zones. These may be sub-domains of a registered domain, or an entirely new domain (not recommended due to TLD changes). Hosts who use the name servers as their name server will be able to find the zones which are not reachable by recursing up from the root servers. Other name servers may be configured to look to the name servers for the local zones.

In the case of split DNS (internal/external), it may be desired to have a different set of DNS servers. In this case the NS list (and likely other data) will be different, and the NS records in the zone files will list the appropriate name server list.

BillThor
  • 27,354
  • 3
  • 35
  • 69