5 ms·

Someone is paying attention. ;) The tld server ip's are "hardcoded" into the resolver application and revised as needed from the root.zone.gz file periodically

Someone is paying attention. ;) The tld server ip's are "hardcoded" into the resolver application and revised as needed from the root.zone.gz file periodically- these servers do not change very often. The application is just a simple lexer that can be easily edited and recompiled. Writing this thing was a learning experience: the vast majority of cases, DNS lookups follow some very predictable patterns. So, to answer your question: that first lookup is unnecessary. There's no need to keep hitting the root to get a relatively small number of tld server ip's that rarely change or go inactive. It's easier just to download the root zone regularly to check for changes. As for subdomains, such as www, that's the CNAME indirection to which I alluded. Everytime someone adds indirection, whatever their reasons (e.g. load balancing, CDN, etc.), it slows down the lookup process by necessitating more lookups. It's a small tradeoff that probably few people pay attention to. From the resolver's perspective, it is more work and it does slow things down compared to the typical 2 query resolution. Note I still say 2 queries because even with recursive resolvers like the ones we all use, the tld server ip's for the popular tld's are almost always already in the cache. You only need to lookup a single domain.com and the com tld server ip's will be there for all future queries.

X-Istence 14y ago
I've thought about writing my own recursive DNS resolver that followed that exact pattern (with caching according to TTL's off course). So yes, you may only need to hit the root once to get the tld as it will be cached, but it is still a hit. I am not sure that downloading the root.zone.gz instead is necessarily required, especially with the amount of new tld's that they are planning on adding it would amount to a lot of wasted resources. Also, for some domains (those in the UK are the ones that popped into my mind), you have sub-domains such as co.uk. So that is another extra lookup... and depending on whether or not you want to use ANY or not in the lookup you find that if you query ns1.nic.uk for co.uk. (A) you get an SOA record back, but no NS results, so at that point instead of just being able to continue you'd have to retry with co.uk. (ANY). At that point you get back a truncated result, and need to retry over TCP... Now you can continue on to ns1.nic.uk for co.uk. and ask it your question mydomain.co.uk. so and and so forth. You've piqued my interest and I am thinking I may start keeping logs from my local recursive DNS resolver and start looking at what the cost is now versus what the cost would be if recursive DNS resolvers would go step by step themselves (keeping in mind TTL's and the like).

X-Istence 14y ago

I've thought about writing my own recursive DNS resolver that followed that exact pattern (with caching according to TTL's off course). So yes, you may only need to hit the root once to get the tld as it will be cached, but it is still a hit. I am not sure that downloading the root.zone.gz instead is necessarily required, especially with the amount of new tld's that they are planning on adding it would amount to a lot of wasted resources. Also, for some domains (those in the UK are the ones that popped into my mind), you have sub-domains such as co.uk. So that is another extra lookup... and depending on whether or not you want to use ANY or not in the lookup you find that if you query ns1.nic.uk for co.uk. (A) you get an SOA record back, but no NS results, so at that point instead of just being able to continue you'd have to retry with co.uk. (ANY). At that point you get back a truncated result, and need to retry over TCP... Now you can continue on to ns1.nic.uk for co.uk. and ask it your question mydomain.co.uk. so and and so forth. You've piqued my interest and I am thinking I may start keeping logs from my local recursive DNS resolver and start looking at what the cost is now versus what the cost would be if recursive DNS resolvers would go step by step themselves (keeping in mind TTL's and the like).