Josh Stone

Twice in the last few weeks I’ve found uses of dnsmasq to solve DNS headaches: first to get around Comcast issues, and second to juggle both VPN and local hostnames.

Round 1 vs. Comcast:  I discovered a while ago that I couldn’t get DNS resolution of a particular domain, elastic.org, nor its subdomains, though it would resolve just fine using a third-party DNS like Google’s 8.8.8.8.  I couldn’t find any reason for this failure, the site’s admin had no idea, and of course Comcast support was no help.  Surprise, rebooting my computer doesn’t help, when I just told you that every Windows and Linux computer I have fails even querying the server directly!

I hesitate to use Google DNS permanently, mainly for fear of losing CDN benefits, so for a while I just hard-coded the addresses in my hosts files.  That’s not ideal in case they ever change, but the web is a fairly static place in practice.  But then I discovered that dnsmasq has an option to route specific domains to specific DNS servers.  My router is running DD-WRT with dnsmasq, so I just had to add “server=/elastic.org/8.8.8.8” to the config, and that one troublesome domain can now query through Google while the rest go through Comcast.  That’s still a bit of a headache to maintain as I discovered other domains with a similar issue, but the problem was somewhat solved.

Round 2 vs. Comcast: Recently I also started having outright connection issues, which turned out to be dropping due to too-high transmit power negotiated in the modem.  They replaced wiring to improve this, but in the process of troubleshooting they also “reactivated” my account.  I noticed that the router was now getting different DNS servers from DHCP, so I tried elastic.org again and it worked!  I manually queried both the old and new servers, and sure enough only the new was able to resolve that domain.

Turns out that the different servers came because the reactivation had also reset the Domain Helper feature, which I had previously opted-out of.  The DNS that DHCP gives you depends on your choice in this setting.  When the “helper” DNS is asked about an unknown name, it will give a bogus resolution to 208.68.143.50, which is a Comcast web server that informs you of the failure and does a web search instead.  This is sort of OK for regular HTTP traffic, but it’s broken for many other uses.  I’d rather have the proper NXDOMAIN, so the browser and any other clients can act accordingly.  Dnsmasq comes to the rescue again with the option “bogus-nxdomain=208.68.143.50” in my config, and it will convert any name resolved to that address to a real NXDOMAIN instead.  So faced with two broken Comcast DNS options, either unable to resolve good names or improperly resolving bad names, I’m able to eke out full and proper functionality again – yay!

[Update Aug 5, 2011] I just got another search page, argh!  Turns out the IP I gave above is for search5.comcast.com, and this time I got search3.comcast.com, so this may be a bit of whack-a-mole.  I scanned search[0-9] now, and got these three to set bogus-nxdomain: 207.223.0.140, 208.68.139.38, and 208.68.143.50.

Bonus round vs. VPN: I have several machines on my home network, and the router’s dnsmasq already does a fine job of resolving those local names.  But my work computer uses openvpn to connect to the corporate network, and for that it needs the VPN’s DNS servers so it can resolve intranet names.  I really want it to resolve names in both networks though.  Then I discovered that NetworkManager has a configuration option “dns=dnsmasq“, which causes it to start a local dnsmasq with a “server=” option for the VPN’s domain.  This means that only requests for the corporate domain will go through the VPN, and all others will use the local connection’s DNS, including the general internet and all my home machines.  Perfect!