Improving your resolv.conf file | Hacker News Reader

Improving your resolv.conf file

edwin.io

33 pointsdatums13 comments

There's no "why". There's no justification for the word "improving" either. No interesting content really.

Even the man page is better: http://linux.die.net/man/5/resolv.conf

"Optimised" resolv.conf has one line - 127.0.0.1 and the host runs a local cache (dnsmasq / bind / djbdns / ...)

Actually using Google's nameservers are really fast compared to a default Bind/PowerDNS setup.

I have a PowerDNS setup on localhost that was a lot slower than Google's servers. That's because by default it recurses to the root servers.

I found that the fastest setup in my case was to use PowerDNS and have it recurse via bt.com servers (this is in London). BT is a big commercial provider so what I need is often hot in their cache, the same goes for Google.

I run a dnscache (djbdns) local DNS cache on my gateway and it caches most of the DNS entries I need on a daily basis so getting results back is much faster than getting them from google.

With a local DNS cache on my network for the same domain name I get replies within 30 or so milliseconds, with Google's DNS servers there is at least another 60 ms or so required for the round trip, making most of the queries take 90 ms. Now that may not seem like a lot, and most likely I will spend more time waiting on a website to load, but in the long run it does make a difference.

Try a server which is only caching instead -- not the normal standalone resolution. For example dnsmasq caches entries locally, but you can select the "upstream" servers yourself, so that you do either no internet queries or only one. In that case asking dnsmasq, which is configured to use 3 google dns servers, is never slower than configuring them in resolv.conf. You never hit the root servers yourself.

Actually, that may be true, but recently, with my website http://code.getnightingale.org, I had SERIOUS troubles accessing my DNS once (the TTL was set very low, and even after fixing it, it didn't work in Google DNS). Turns out, it was because of Google's nameservers. Moment I changed, it was fine (must be a bug in their setup).

Anyway, this isn't much of an improvement honestly..

> nameserver 4.4.4.4

Please don't do this unless you're a GTE/Verizon customer. Use your ISP's or run a resolver yourself.

4.4.4.4 was what they originally wanted to set up DNS on (The guys behind 4.2.2.[1-6] that is ...) however those are not Verizon's or GTE's name servers, there is no resolver running on that IP address, it is on 4.2.2.2, and they are Level 3's name servers which they anycast for use on their network by their customers.

For a bit of the history behind it check out this site: http://www.tummy.com/Community/Articles/famous-dns-server/

Using the DNS server is not suggested, since it is not officially a public DNS server, and Level 3 could cease the service at any time (in all likelihood that is very slim, since they have been telling their customers to use them for years now). Since they are anycast it will reach the closest server to your location when you query that DNS, and as such using it shouldn't be too big of a deal, whether you are a customer or not.

Isn't that a Google nameserver?

Oh wait, that's 8.8.4.4. Maybe that's what he meant.

And now I checked the article. That's what it says now.

Try out namebench. It hunts down the fastest DNS servers available for your computer to use. namebench runs a fair and thorough benchmark using your web browser history, tcpdump output, or standardized datasets in order to provide an individualized recommendation.

http://code.google.com/p/namebench/

@viraptor thanks for the feedback. Excluding the "why" was a huge oversight. As far as running a local resolver, it depends on how you architect your infrastructure. Having a single line with 127.0.0.1 introduces a single point of failure. While that might be acceptable for demo/prototyping applications, I think for production deployments you'd want to avoid that. Also running a local resolver adds another service you'll need to monitor and keep up to date.

Note: This recommendation is for server setups, where dns latency can easily add ms to processing time. With workstations we can tolerate some latency and should probably benchmark your ISPs resolvers.

I wrote an additional entry on how to find to optimal nameserver: http://www.kubieziel.de/blog/archives/1343-Improving-your-re...

hmmm.. what distro is this ?

Because AFAIK, ubuntu distros (and maybe redhat/fedora even) suffer from multisecond delays due to ipv6 lookups - https://bugs.launchpad.net/ubuntu/lucid/+source/eglibc/+bug/...

I thought this article had some solution to that (other than disabling ipv6, right now) - but dont think so

http://www.dnsserverlist.org/indexbeta.php?oby=Q_RTT

Reply on news.ycombinator.com