workaround for broken nameserver

[Mark Andrews]

> I recently encountered a couple of nameservers which exhibit seriously 
> broken behavior with respect to IPv6.  As I understand it, a nameserver 
> which recieves an AAAA query for a domain which exists but which has no 
> AAAA record is supposed to return NOERROR and an empty result set.  These 
> particular servers return NXDOMAIN; from the research I did on Google, it 
> sounds like there are also some that return SERVFAIL.
> So the result of this problem is that I can't send email to this domain. 
> Sendmail tries an AAAA lookup; it fails, returning NXDOMAIN, and sendmail 
> - following every RFC that I can find - decides that an A query will be 
> fruitless and gives up.  After some research, I discovered that sendmail 
> has an option to ignore NXDOMAIN and SERVFAIL responses to AAAA queries 
> and try an A query anyway; this option was added to help work around 
> exactly this kind of broken nameserver.  So I tried enabling that option, 
> but it didn't fix the problem.
> 
> Why not?  Well, the resolver library on that machine is pointed at a 
> caching nameserver (bind 9.3.1) on the local machine.  Bind goes out, 
> tries the AAAA query, gets back NXDOMAIN, and returns NXDOMAIN to 
> sendmail.  Sendmail then tries an A query (because of the workaround 
> option), but bind says, ah ha, I don't need to recurse, I already know the 
> answer, because I got NXDOMAIN from my AAAA query.  This host doesn't 
> exist.  So it sends that answer back in response to the A query as well.
> 
> This behavior on the part of bind is eminently sensible, but I still can't 
> send mail to that domain, whereas if either my MTA or my nameserver were 
> slightly stupider (and I'm guessing that most people's are, or the people 
> responsible for the domain would have fixed it) I would be able to do so. 
> So I'm looking for a workaround.  Any ideas?  I see that there is a 
> "bogus" option in the "server {}" stanza, but doesn't help me in this case 
> because ALL of the nameservers for that domain exhibit this problem 
> (otherwise I could declare the broken ones bogus and rely on the 
> remainder).  It seems like it might be helpful to have a "bogus-ipv6" or 
> "dont-cache-ipv6-failure" option that flags a nameserver as having this 
> problem, unless there is some other clean solution that I have missed.
> 
> Thanks in advance for any suggestions,
> 
> ...Robert

	The usual offendors are load balancers.

	Look up the offending site with whois and phone the operator.

	Tell them that they are not running a RFC 1034/1034 compliant
	nameserver (load balancer).  You can also refer them to:

		http://www.kb.cert.org/vuls/id/714121

	Their nameserver (load balancer) vendor should have a patch.
	Or in the case where the load balancer falls through to a
	standard nameserver, for non A queries, add the A records
	to the backing nameserver.

	While they are waiting for a fix from their vendor that
	should install a regular nameserver with multiple address
	records.  It will make them compliant again.  Keep them
	operational and may even show them that they don't need
	the load balancer.

	As for bogus-ipv6 etc.  There are / were load balancers that
	did this for ever type other than A.  Working around broken
	nameservers doesn't fix the problem.  It just perpetuates it.

	Note: this issue is nowhere near as prevalent as it once
	was.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org