HN user

hextraorinary

4 karma
Posts0
Comments3
View on HN
No posts found.

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.

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.

That's one benefit of DNSSEC. If an ISP adopts it, including NSEC, they can't also do NXDOMAIN spoofing with their DNS servers. Mutually exclusive.

But for ISP's that insist on doing this, there are various workarounds besides the one mentioned in the blog post. It's quite easy. Tunneling inside HTTP is a last resort. At some point it's not worth the trouble for the ISP, e.g., to peek into every packet trying to stop users from getting a proper NXDOMAIN response.