strenholme.usenet at gmail.com
Thu Jan 15 18:58:37 EST 2009
> 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.
OK, I have looked at this issue. Read that as: I have set up a VMware
virtual machine to run CentOS 5.2 from the command line so I can do
full development and testing of MaraDNS again (that took a couple of
days ), then spent a few hours today designing a SQA test that
recreates this problem in a reproducible form.
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
More information about the list