lame servers

[Alexander Clouter]

Hi,

* Sam Trenholme <strenholme.usenet at gmail.com> [Thu, 15 Jan 2009 17:58:37 -0600]:
> 
> [snipped]
>
> Here is what I see: MaraDNS initially sends a SERVFAIL when it sees
> this kind of borked zone.  However, if someone sends a DNS packet to
> MaraDNS again with the same query, MaraDNS will correctly resolve it.
>
> If the SERVFAIL packet is causing problems, the workaround is to stop
> MaraDNS from sending SERVFAIL when there is an issue like this
> resolving a domain.  Add this to one's mararc file:
>
> handle_noreply = 0
>
> This is better for server use (where we're willing to wait longer
> before resolving domains, and where a DNS timeout is not annoying),
> but probably not good for desktop use (where people don't like wait 90
> seconds for a DNS timeout; it's an old *NIX usability issue).
>
> I feel this resolves the issue in question; if there is a reason why
> this workaround is not acceptable, please let me know.  I don't like
> making changes to the recursive code; it works and is a bit difficult
> to maintain.
>
I'm going to have to grumble :) Have a nosey at the depressing Infoblox 
report (sections titled 'Do delegations match authoritative NS records?' 
and 'How many zones have a lame server?'):

http://dns.measurement-factory.com/surveys/200710.html

I think you are going to have to crack into the recursive code :)

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.

For us it was not the SERVFAIL that caused the problem, we simply got 
*no* answer at all, no matter how often we asked.  wjh.harvard.edu is 
really completely unreachable for us with my hack :(