Understanding the DNS domain lookup mechanism

domain-name-systemnameservernetworkingresolvesubdomain

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 effectively hard coded in network hardware. In the case of a lookup for example.com, our local DNS server, probably our router, queries one of these root servers for the domain in question, and is referred to the top-level nameserver for com. It then asks this nameserver if it knows how to resolve example. If it does, we're done, if not, we're referred on to another server. Some of the servers in this process may be caching, so that for a time our local router will now know offhand where to look for com and 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 we're referred to does not know how to resolve example, is it right to say that's the end of the line: 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 in the database used by the nameservers for that TLD? Does the registrar itself maintain "proxy" nameservers?

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. Are all authoritative com nameservers, for example, exact mirrors, or would a resolver have to try each in turn?

Looking back at my initial question, I might take a very speculative stab at "no", assuming the A records are both on the same nameserver. I would be very grateful to anyone who could reduce my ignorance!

Best Answer

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

Assuming that there is a caching server in the scene, yes. This is because in order to find an A record for anything in example.com., the nameservers for example.com. must be known. When the request for assets.example.com. is made the nameservers for example.com. should already be cached, and so the only query is for assets.example.com. itself.

I know there are other intermediate DNS servers, such as those provided by ISPs. At what point are they queried?

These are typically caching or recursive nameservers. These do the hard work on your behalf (the multiple requests to traverse the tree) and then cache the result to speed up later queries for the same name.

Are all authoritative com nameservers, for example, exact mirrors, or would a resolver have to try each in turn?

Yes, they contain the same information. The resolver just has to find one which is actually working.

If the com TLD nameserver we're referred to does not know how to resolve example, is it right to say that's the end of the line: example.com cannot be resolved?

If the .com. nameserver responds and says example.com. does not exist, then the result is that the name does not exist. If the .com. nameserver doesn't respond to the query the resolver should try a different .com. nameserver.

When I register a domain and configure nameservers, am I in effect editing a group of NS records for my subdomain in the database used by the nameservers for that TLD? Does the registrar itself maintain "proxy" nameservers?

Correct. When you register the domain you provide NS records (and some A records if you need glue) to be inserted in the parent domain. The registrar doesn't necessarily run those nameservers itself, but have a mechanism to modify the database of those nameservers.