Poor DNS Resolver Performance

The DHCP server in the Residential Gateway (RG) configures clients with a predefined set of Domain Name Service (DNS) resolvers that can't be changed, and many users complain that these resolvers are slow and/or unreliable.

Although you can't reconfigure the DHCP server to hand out a different set of resolvers, you can configure many operating systems to ignore the resolvers obtained by DHCP and use your own. Google recently (late 2009) announced that they were making a set of high quality DNS resolvers publicly available with the easy-to-remember IP addresses of 8.8.8.8 and 8.8.4.4. Although public DNS resolvers are already available from other providers, they are either unofficial or are run by companies like OpenDNS with the business model of redirecting traffic for nonexistent domain names to their advertising sites. Google's resolvers return the proper error codes for nonexistent domain names, they explicitly welcome public use, and their use is free. They have also invested an impressive amount of effort into maximizing their reliability and hardening them against the usual DNS attacks.

Google's DNS resolvers work as advertised, although the 53 ms round trip times from here (San Diego) are somewhat greater than the times I see to some closer resolvers like dns.lax1.speakeasy.net (26 ms). Google says they're using anycast (or will be using anycast - they were a little vague) so they can replicate their resolvers geographically, divide loads, provide robustness against denial-of-service attacks, and steer users automatically to the nearest one. So as they deploy more servers, the average latency for each user should go down.

I run Linux and Mac OS X so I have the option to run my own local name resolvers with BIND, and I do. However, the public resolvers are still useful because they can cache the most popular domain names and return results before my local resolver can walk through the server chain for a name that isn't already in its cache.

I also run the ISC DHCP server locally so that I can configure my DHCP clients with whatever DNS servers I want. I avoid interference with the DHCP server in the RG by connecting my LAN to the RG through a 2-port Linux box operating as an Ethernet bridge that blocks DHCP client packets. Only those clients within the RG, or directly attached to it without the Linux bridge in the path, use its built-in DHCP server. Right now that's just the U-verse set top box; I disable the built-in WiFi base station and use my own base stations connected on the other side of the filtering bridge.


Last modified: Mon Feb 8 15:13:38 PST 2010