alex at digriz.org.uk
Fri Jan 16 04:42:40 EST 2009
* Sam Trenholme <strenholme.usenet at gmail.com> [Thu, 15 Jan 2009 17:58:37 -0600]:
> 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?'):
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' 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 :(
More information about the list