lame servers

[Sam Trenholme]

>> Digging around on a particular offender (MX lookup for
>> wjh.harvard.edu) I found that there is a lame server entry
>> which causes MaraDNS to respond with a SERVFAIL to the user.

Thank you for the bug report and the fix.

Let me spell out the issue so I can come up with some good SOA test
cases to reproduce this bug and make sure your patch fixes it/

Let's suppose we have sub.example.com, and the root servers say this
for the nameservers for example.com:

example.com. NS ns1.example.net.
example.com. NS ns2.example.net.
ns1.example.net. A 192.168.1.1
ns2.example.net. A 192.168.1.2

When we query 192.168.1.1 or 192.168.1.2 for sub.example.com, we get this:

sub.example.com. NS ns1.example.net.
sub.example.com. NS ns2.example.net.
sub.example.com. NS ns.sub.example.com.
ns1.example.net. A 192.168.1.1
ns2.example.net. A 192.168.1.2
ns.sub.example.com. A 192.168.1.3

And ns.sub.example.com (192.168.1.3) gives us the correct answer.

Now, your patch looks good, but I think I will have to add some tests
so getting this from 192.168.1.1 or 192.168.1.2 for sub.example.com
doesn't put us in an infinite loop--did anyone else read the article
detailing exactly why some Zunes crashed December 31st?  It was caused
by an unintentional infinite loop.

sub.example.com. NS ns1.example.net.
sub.example.com. NS ns2.example.net.
ns1.example.net. A 192.168.1.1
ns2.example.net. A 192.168.1.2

- Sam

Note: If you send me a MaraDNS-related support question, I reserve the
right to post your support email to the Mara-DNS mailing list so that
the community at large can examine your issue. MaraDNS security
vulnerability reports, however, will be kept confidential.