8 ms·

There's a solution to all this, where you will always get the right response, and it even obviates the need for DNSSEC or DNSCurve. And that is, write your own

There's a solution to all this, where you will always get the right response, and it even obviates the need for DNSSEC or DNSCurve. And that is, write your own resolver that only sends nonrecursive queries to authoritative nameservers. If the DNS admin has configured DNS simply and sensibly, it will only take you 2 queries to get a name resolved. It's very fast. If they are using Akamai or some other CDN, or they have a love for CNAMES and indirection, it can take many more queries. Sometimes up to 7.

X-Istence 14y ago
Only 2? Wouldn't you have to hit the root, then the tld server, then the name server for the domain, and if it isn't the root domain (example.net), but if it is a sub-domain (www.example.net) which could potentially return more NS records ... and the process would have to happen all over again. net. => root (return tld) example.net. => tld (return ns) www.example.net. => ns (returns ns2) www.example.net. => ns2
- hextraorinary 14y ago
  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

Only 2? Wouldn't you have to hit the root, then the tld server, then the name server for the domain, and if it isn't the root domain (example.net), but if it is a sub-domain (www.example.net) which could potentially return more NS records ... and the process would have to happen all over again. net. => root (return tld) example.net. => tld (return ns) www.example.net. => ns (returns ns2) www.example.net. => ns2

hextraorinary 14y ago
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).