Question

The specific query that led me to try and unpick this process was:

Will a DNS lookup for a subdomain, such as assets.example.com, be faster if the parent domain, example.com, has already been resolved?

By my (naive) understanding, the basic process for translating a domain name into an IP address is quite simple. The addresses of the thirteen root servers, who know how to resolve top-level domains like com and net, are hard coded in network hardware. In the case of a lookup for example.com, our local DNS server, probably our router, asks one of these root servers where to find a top-level nameserver for com. It then asks the resultant nameserver if it knows how to resolve example. If it does, we’re done, if not, we’re passed to another server. Each nameserver in this process may well be caching, so that for a time our local router will now know offhand where to look for com and example, and the com server will know where to look for example.

Still, I don’t really get it.

• I know there are other intermediate DNS servers, such as those provided by ISPs. At what point are they queried?
• If the com TLD nameserver does not know how to resolve example, how does it work out what other nameservers to check? Or would this simply mean that example.com cannot be resolved?
• When I register a domain and configure nameservers, am I in effect editing a group of NS records for my subdomain of a particular TLD in the database used by the nameservers for that TLD?

Wikipedia explains that some DNS servers combine caching with a recursive query implementation which allows them to serve cache hits and reliably resolve cache misses. I don’t understand how these servers come to be queried, or how (even broadly) the resolving algorithm works.

Looking back at my initial question, I might take a stab at “no”, assuming the A records are both on the same nameserver. Is this accurate?

Answer 1

First, the misconceptions:

• The root hints (names and IP addresses of the 13 root servers) are hardly ever “hard coded in network hardware”. Network hardware such as a router, may sometimes have a built in DNS resolver if it happens to also have a DHCP server, but if it does, it’s usually just a forwarding resolver that passes the query along to an upstream nameserver (obtained from an ISP) if it doesn’t know the answer.
• nameservers provided by ISPs don’t usually act as “intermediate DNS servers”. Either you use your own nameservers (e.g. corporate nameservers, or you installed BIND on your computer) or you use the ones provided by your ISP. In either case, whichever nameserver you choose will take care of the recursive resolution process from beginning to end. The exception is the aforementioned forwarding nameservers.
• If the com TLD nameserver does not know how to resolve example, it does not work out what other nameservers to check. It is itself the nameserver to check. It either knows about example, or example doesn’t exist.

The answer to your question is yes. If a nameserver has already resolved example.com (and that result is still valid in its cache), then it will be able to resolve assets.example.com more quickly.

The recursive resolution process is much as you described it: First find out the nameservers for . (the root), then find out the nameservers for com, etc… Only the recursive resolver does not actually ask for the nameservers for . and com and example.com. It actually asks for assets.example.com each time. The root servers won’t give it the answer to that question (they don’t know anything about assets.example.com) but they can at least offer a referral to the nameservers for com. Similarily, the nameservers for com won’t answer the question (they don’t know either) but they can offer a referral to the nameservers for example.com. The nameservers for example.com may or may not know the answer to the question depending on whether assets.example.com is delegated further to other nameservers or provisioned in the same zone as example.com. Accordingly, the recursive resolver will receive either a final answer or another referral.