

Improving your resolv.conf file - datums
http://edwin.io/optimized-resolv-conf

======
viraptor
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 / ...)

~~~
avar
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.

~~~
X-Istence
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.

------
skorgu
> 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.

~~~
X-Istence
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.

------
mhansen
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/>

------
egonzalez
@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.

------
qbi
I wrote an additional entry on how to find to optimal nameserver:
[http://www.kubieziel.de/blog/archives/1343-Improving-your-
re...](http://www.kubieziel.de/blog/archives/1343-Improving-your-resolv.conf-
file-part-2.html)

------
sandGorgon
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/...](https://bugs.launchpad.net/ubuntu/lucid/+source/eglibc/+bug/417757)

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

------
known
<http://www.dnsserverlist.org/indexbeta.php?oby=Q_RTT>

