Thursday, September 2, 2010

New Deadwood snapshot: Better heuristics for empty DNS packets

When a remote server sends us an empty DNS packet, what does that really mean? Well, it usually means that the hostname does not always exist. But, not always.

Let’s take the hostname ibnlive.in.com. It has three DNS servers: 123.108.40.31, 123.108.40.32, and 123.108.40.81. Two of the servers (123.108.40.32 and 123.108.40.81) do the right thing: They redirect the name to Akamai’s horrendous mess of DNS resolution. However, 123.108.40.31 is broken and gives us a blank DNS packet with a SERVER FAIL message.

The DNS administrators for in.com aren’t trying to tell us that ibnlive.in.com doesn’t resolve. No, they’re trying to tell us that their DNS administrator is asleep and misconfigured one of their three DNS servers.

So, I’ve tweaked the heuristics of Deadwood to treat a DNS packet with a “SERVER FAIL” RCODE as being one where the DNS server is asleep at the wheel, so instead of treating the packet like “this name does not exist” (like what we normally do with a blank DNS reply), we ignore the packet and bug the next DNS server on the list. The code isn’t perfect: We wait timeout_seconds before contacting the next server, but it’s good enough to have domains mismanaged like this correctly resolve.

I should note that the bugs I’m finding in Deadwood right now are not bugs caused by Deadwood not being RFC-compliant—the last bug I fixed like that was on August 9. No, at this point, I’m fine-tuning Deadwood to more or less do the right thing with mismanaged domains and broken DNS servers.

As always, the snapshot can be looked at here:

http://maradns.org/deadwood/snap/