Performance issues with deadwood

[Sam Trenholme]

> i have been using a freeware windows based dns test program from gibson
> research co. at http://www.grc.com/dns/benchmark.htm which tests a given
> list of public (and private) dns servers for cached and uncached
> performance.

Thank you for the pointer.  This program has helped me find some bugs
in Deadwood.  It is my conclusion that, while this program has been
useful for finding a bug in Deadwood, it is not a reliable tool for
testing a DNS server running on one’s local connection.

The reason why this tool was reporting slow replies from Deadwood was
because of a bug in Deadwood (with hostnames and case sensitivity; a
case which does not affect things with most real-world queries but
delayed the responses Gibson’s program makes by timeout_seconds) which
I have fixed.  Once I patched the bug, while Gibson’s DNS benchmark
tool reports much higher speeds with Deadwood, it also *incorrectly*
reports that Deadwood drops between 80 and 95% of DNS packets, which
plain simply is not true.

Since these numbers are so distressing, which I did was carefully look
through Deadwood’s code to see if something was amiss.  I didn’t find
anything, and just verified that Deadwood is perfectly responsive
while being subjected to Gibson’s test, and that Deadwood replies to
almost all queries sent to it by Gibson’s test.

One thing that was *very* frustrating for me dealing with Gibson’s
tool is that it doesn’t give me enough information to troubleshoot its
error reports.  It doesn’t tell me which particular DNS packets were
“dropped”, so I was pulling my hair out all afternoon making damn sure
the problem was Gibson’s broken tool and not Deadwood.

My theory—again, Gibson’s tool is a black box, so this is a guess—is
that Gibson’s test looks at the average reply for a cache, and
considers any reply more than N standard deviations from that average
reply time to be a dropped packet.  As it turns out, Unbound run on my
system against this test reports 5% to 10% of packets being dropped,
and the older buggy versions of Deadwood (which delay replies with the
wrong case by timeout_seconds) are reported as having no dropped
packets with Gibson’s tool.

I would guess that Gibson’s tool is optimized to benchmark queries
from a recursive DNS server with a high-speed internet connection,
where the round trip time to do a recursive DNS query is a fraction of
the response time of a home internet connection.  It is obvious, based
on how the tool incorrectly states that Deadwood drops most packets,
that the tool can not handle very well home network connections with a
more variable response time.

Gibson also has an interesting DNS spoof-ability test which I used to
verify that recurse_min_bind_port and recurse_number_ports work
correctly in Deadwood; however the page at
https://www.grc.com/dns/gallery.htm claims there is something wrong
with MaraDNS’s default settings since I only use 28 instead of 32 bits
of entropy for the query ID + source port—MaraDNS’ default settings
allow people to use MaraDNS with random source ports without
completely removing one’s UDP firewall and allowing one to readily run
other UDP services on the same machine.

MaraDNS was immune from the Kaminsky attack as far back as 2001
because MaraDNS (and Deadwood) have never allowed packets in the AR
section of a reply in to their cache.  If you ask for
abwjde.paypal.com in an attempt to poison www.paypal.com with an AR
packet, a successful spoof will only spoof abwjde.paypal.com—*not*
www.paypal.com.  One would have to send on average over 100 million
packets that would need to arrive *before* paypal.com’s legitimate DNS
packet to successfully spoof MaraDNS or Deadwood.  This is how it was
in 2001; this is how it is today in 2010.

So, in conclusion, Gibson’s tools are useful, but after spending all
day using them and looking over Deadwood’s replies to it with a
microscope, the tool is just not a very good tool for testing a
recursive resolver on a home internet connection.

- Sam