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 resolveexample
, how does it work out what other nameservers to check? Or would this simply mean thatexample.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?