0

I'm not sure how recursive resolves behave when its cache contains partial of the answer. Specifically, let's assume that first I ran this lookup request: 

dig example.com @8.8.8.8

Based on my understanding, after the resolution process, the following records will be cached at this public resolver(8.8.8.8)

example.com.        17834   IN  NS  a.iana-servers.net.
example.com.        17834   IN  NS  b.iana-servers.net.
example.com.        18662   IN  A   93.184.216.34

Second, let's assume the I ran another lookup request as follows (Before the expiration of the TTL of the above records):

dig sub.example.com @8.8.8.8

Now, since the NS records that are needed to resolve the apex domain are already in the cache, does the recursive resolver use this cached information to directly query one of these NS records for the A record for (sub.example.com)? If yes, how does it know how to breakdown the request?

I got the idea of how resolver start starts from the top of the hierarchy, i.e., root (.) if it doesn't have the answer in cache. However, what I found confusing is that if the cache has partial answers (in this example it's the NS record for the apex domain) how does the resolver make use of these cached answers?

  1. Would it breakdown the query (sub.example.com) and identify the apex domain(example.com), then find a hit in the cache for the NS record for (example.com)?
  2. Or, would it recursively resolve (sub.example.com) starting from the root and totally ignores any previous cache for (example.com)?
user5289027
  • 5
  • 1

1 Answers1

0

A recursive caching nameserver will use all information it has locally in order to do as few queries as possible, so for "does the recursive resolver use this cached information to directly query one of these NS records for the A record for (sub.example.com)" the answer is yes, if the content in cache is not expired of course.

If yes, how does it know how to breakdown the request?

The whole process is documented at §4.3.2 of RFC 1034. See also §5.3.3

Would it breakdown the query (sub.example.com) and identify the apex domain(example.com), then find a hit in the cache for the NS record for (example.com)? Or, would it recursively resolve (sub.example.com) starting from the root and totally ignores any previous cache for (example.com)?

Per the above algorithm, the search starts at the root for the specific (name, type) wanted. Note that the type is taken into account. At any step if the given (name, type) information is already in local cache, and not expired, then it will be used.

dig is a useful tool to troubleshoot DNS problems, but if you use with +trace you can see how a typical recursive nameserver (but without cache) works and see each step and how resolving starts from root. Otherwise you can install any recursive nameserver, such as bind or unbound, crank up verbosity in its logging and then read the logfiles to understand what is happening...

Community
  • 1
Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42