Query sent, but no response

[Mark Andrews]

> I'm seeing an odd problem on my recursive resolvers that I can't  
> quite figure out. Given queries in the sfchron.com zone (say,  
> querying for mr1.sfchron.com. A) I am unable to get a response. If I  
> log into the resolver host and use "dig" against the authoritative  
> servers, I get a response, i.e.
> 
> dig @ns1.sfchron.com. mr1.sfchron.com. a
> 
> dig @ns2.sfchron.com. mr1.sfchron.com. a

	ns1.sfchron.com and ns2.sfchron.com are running a stupid
	nameserver implementation that returns FORMERR to a plain
	EDNS query but drops a EDNS query with DO set.

	The base DNSSEC spec says to return FORMERR to something you
	don't understand.  It looks like they have been told to return
	FORMERR to EDNS but failed to learn that this to properly.

	dig ns1.sfchron.com @198.134.145.66 +bufsize=512 -> FORMERR

	dig ns1.sfchron.com @198.134.145.66 +dnssec -> NO RESPONSE

	Mark
 
> However, if I dig @localhost (i.e. I am asking my resolver for the  
> answer) then I get a varying response. On several of the resolvers, I  
> get the same answer as the above queries. On others, I get a timeout.  
> But on all resolvers, if I dig @nsN.sfchron.com it works; only on  
> some does it timeout when I ask localhost.
> 
> On the hosts where I get timeouts, other queries against localhost  
> work fine (for instance, yahoo.com. MX).
> 
> All resolvers are running BIND 9.3.1 on Sun Solaris 8 SPARC. I have  
> reviewed the BIND configs to ensure the sfchron.com nameservers are  
> not blackholed.
> 
> Results from snoop and tcpdump are consistent with the errors  
> returned; i.e. when the client returns a timeout, I see a request go  
> out, but no answer comes back.
> 
> Has anyone seen this before? I've seen similar behavior in the past,  
> but it always turned out to be something simple (the remote end was  
> filtering us, or we had the remote site's IP in our blackhole list...)
> 
> Lastly, the pattern appears to change somewhat over time. Of my 17  
> resolvers, on one day a certain subset get timeouts. The next day it  
> is a different set. The next a different set (though a small handful  
> seem to constantly be present on the timeout list, I am so far  
> considering that to be a coincidence).
> 
> Thanks for any help you can offer.
> 
>   -dan
> 
> 
> -- 
> logic (n.): the art of being wrong with confidence.
> 
> 
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org