lame servers

[Sam Trenholme]

> The behaviour I saw anyway was that MaraDNS was not trying *all* the
> nameservers before coming back with SERVFAIL, it would cling to the
> entries delegated by the 'parent zone'[1] and not ask any of the ones
> further down the line.  I hope that's clear.

OK, can you think of a test case that can reproduce this behavior?

I created a test case that basically duplicated the issue with the
Harvard servers.  The test case I created was as follows:

root:

example.net. NS ns1.example.net.
example.net. NS ns2.example.net.
example.net. NS ns3.example.net.
example.net. NS ns4.example.net.
ns1.example.net. A 127.0.1.2
ns2.example.net. A 127.0.1.3
ns3.example.net. A 127.0.1.4
ns4.example.net. A 127.0.1.5

ns[1-4].example.net:

sub.example.net. NS ns1.example.net.
sub.example.net. NS ns2.example.net.
sub.example.net. NS ns3.example.net.
sub.example.net. NS ns4.example.net.
sub.example.net. NS ns.sub.example.net.
ns1.example.net. A 127.0.1.2
ns2.example.net. A 127.0.1.3
ns3.example.net. A 127.0.1.4
ns4.example.net. A 127.0.1.5
ns.sub.example.net. A 127.0.1.6

ns.sub.example.net:

sub.example.net. NS ns1.example.net.
sub.example.net. NS ns2.example.net.
sub.example.net. NS ns3.example.net.
sub.example.net. NS ns4.example.net.
sub.example.net. NS ns.sub.example.net.
sub.example.net. A 127.0.1.32
www.sub.example.net. A 127.0.1.33

With this particular setup, the first time we try to resolve
www.sub.example.net, we get a SERVFAIL; the second time, the hostname
correctly resolves.

If you want to see the test case for this particular setup, download
the 20080115 snapshot of MaraDNS:

http://www.maradns.org/download/1.3/snap/2009/

(maradns-Q-20090115.1.tar.bz2)

And look in the directory sqa/regressions/borked_zone

If you have any questions about how this script works, let me know.  I
know it works on a CentOS 5.2 system (you can download a CentOS 5.2
vmware image at http://www.thoughtpolice.co.uk/vmware/ )

The deal is this: Saying "some domains on the internet don't resolve
correctly" is not a good enough bug report.  It's about as useful as
the email someone once sent us when I was working email support for
Netcom: "We lost the big bunny". [1]

What I need is a test case where one can demonstrate that MaraDNS
isn't consistently resolving a domain that BIND can resolve.  If you
give me a domain that MaraDNS consistently can't resolve again, I
might get around to making a test case. Did I mention I'm doing all
this support without getting paid? [3] So, yeah, it's not a big
priority for me.

Since money isn't changing hands, I'm going to ask you to do the
lion's share of the work to make a reproducible test case
demonstrating this bug.  I'm not even going to start think about
making changes to the recursive code until we have a test case.

- Sam

[1] Yes, someone once sent us an email with this content.  It ended up
being a conversation piece; a lot of speculation about why this email
was sent to us was done around the water cooler.  We finally decided
it was some kids who though we were their parents or some such. [2]

[2] I understand you did give a good bug report the first time.  I
made a test case reproducing the bug and saw a perfectly good
workaround with my test case.

[3] If you think people will create compelling art, music, movies,
software, and other digital content for fun and for free, and that you
have a God-given right to pirate any and all content from
thepiratebay.com, please stop taking those kinds of drugs.