Does the Glue record get cached by the Recursive resolver?

Question

Does the IP address of authoritative name server from Glue record get cached by the Recursive resolver?
The name server for a top level domain includes glue along with the delegation for a domain name.
Now, does the Recursive resolver cache this 'A'/'AAAA' record (glue record)? I know that caching applies only if the response came from an 'Authoritative' Name server but here the TLD Name server further delegates and cannot be considered Authoritative.
Or
Does the Authoritative Name server also provides its own IP address as an A record (along with the domain's A record) and this is what gets cached by Recursive resolver?

Answer 1

Normally, the glue records aren't given as authoritative answers, which you may notice, if you look at the flags (the existence or absence of aa Authoritative Answer; RFC 1035, 4.1.1) e.g. of the following queries:

• Authoritative on the parent:

   dig com NS @f.gtld-servers.net
   ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
  

• Deletation of control. Both gives glue records in the additional section.

   dig google.com NS @f.gtld-servers.net
   ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
  
   dig ns1.google.com A @f.gtld-servers.net
   ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
  

• Authoritative answers from an authoritative server:

   dig google.com NS @ns1.google.com
   ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 9
  
   dig ns1.google.com A @ns1.google.com
   ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
  

The basic algorithm from RFC 1034, 5.3.3 caches most of the response data; only failures and other bizarre contents (d) are ignored (emphasis is mine):

• a. if the response answers the question or contains a name error, cache the data as well as returning it back to the client.

• b. if the response contains a better delegation to other servers, cache the delegation information, and go to step 2.

• c. if the response shows a CNAME and that is not the answer itself, cache the CNAME, change the SNAME to the canonical name in the CNAME RR and go to step 1.

• d. if the response shows a servers failure or other bizarre contents, delete the server from the SLIST and go back to step 3.

The RFC also mentions some implementation could have an option to force the resolver to ignore the cached data and consult with an authoritative server. What really happens depends on the implementation. According to How DNS Kills the Internet from Kudelski Security Research:

Beside bugs that can result in non-intentional false responses, cache poisoning (see Dan Kaminsky’s 2008 DNS vulnerability and The Hitchhiker’s Guide to DNS Cache Poisoning) has to be taken into consideration. Many DNS cache implementations cache the glue records as normal records, thus a DNS server may provide a malicious response and in consequence having a wrong entry in the cache.

For example:

evil.com.       IN NS ns.company.com.
ns.company.com. IN A 6.6.6.6

While the legitimate server says

company.com.    IN NS ns.company.com.
ns.company.com. IN A 1.2.3.4

So the wrong IP address will end up in the cache for the lifetime of the record. To avoid this problem most of the caching resolver implementation do not trust and ignore the optional glue records for out-of-bailiwick NS records, and thus ignore the ns.company.com. IN A 6.6.6.6 in the example above. A note for DNS administrator: it is good practice to have only in-bailiwick records.

Whether an answer is authoritative or not isn't per se an indicator on whether the records should be cached or not:

• The upper level name servers are part of the same authoritative name server structure. Therefore, as they do delegate control of their subdomains i.e. ultimately can control who can answer authoritatively, they should be trusted and are trustworthy. Normally, the glue records should match the records on the zone itself, and everything else would be a configuration error per IANA Technical requirements for authoritative name servers:

Consistency between glue and authoritative data

For name servers that have IP addresses listed as glue, the IP addresses must match the authoritative A and AAAA records for that host.

Consistency between delegation and zone

The set of NS records served by the authoritative name servers must match those proposed for the delegation in the parent zone.

• Not every recursive server starts resolving the name from the root name servers, but there are more complex recursive infrastructures, too. A resolver can have forwarders, other recursive name servers they ask instead of the authoritative name servers. These responses are never authoritative, but are always cached.

• In DNS cache poisoning scenarios the perpetrator isn't any of the authoritative name servers, but an answer spoofed to be from a trusted source, whether it's an authoritative name server or a forwarder. Because DNS utilizes UDP, spoofing the responses is easier. There are some solutions against that:

  • Maximum UDP response size. If the response is bigger than that i.e. greater than a single UDP packet, DNS uses TCP. Having an additional section, a response containing glue records easily goes over that boundary. TCP connections aren't that easy to spoof, as it would require a MitM position.

  • DNSSEC validation. A spoofed response can't have matching DNSSEC signatures for their records, so they won't get cached.

  • Encrypted DNS. There are two standards: DNS over TLS (RFC 7858) and DNS over HTTPS (RFC 8484).