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.
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?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?
First, the misconceptions:
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.