strange behaviour of resolving nameserver

[Torsten]

Am Wed, 10 Mar 2010 08:34:41 +0100
schrieb Torsten <toto at the-damian.de>:

> Am Wed, 10 Mar 2010 08:36:54 +1100
> schrieb Mark Andrews <marka at isc.org>:
> 
> > 
> > In message <20100309154017.4801cf70 at the-damian.de>, Torsten writes:
> > > Am Wed, 10 Mar 2010 00:44:46 +1100
> > > schrieb Mark Andrews <marka at isc.org>:
> > > 
> > > > 
> > > > In message <20100309142153.016c7dbb at the-damian.de>, Torsten
> > > > writes:
> > > > > Hi,
> > > > > 
> > > > > I'm a bit clueless about what's happening here exactly.
> > > > > I have a server (9.6.1-P3) that tries resolving
> > > > > ws.mobilecdn.verisign.com. Queries for this host permanently
> > > > > fail with SERVFAIL.
> > > > > 
> > > > > I've narrowed the problem down to answers from c2.nstld.net 
> > > > > 
> > > > > 
> > > > > dig @c2.nstld.com mobilecdn.verisign.com 
> > > > > ;; Got referral reply from 192.26.92.31, trying next server
> > > > 
> > > > Fix /etc/resolv.conf to point to recursive nameservers.
> > > > 192.26.92.31 is not a recursive nameserver.
> > > 
> > > /etc/resolv.conf already points to recursive nameservers. Since
> > > these nameservers can't resolve ws.mobilecdn.verisign.com I tried
> > > every single nameserver found by dig +trace and ended up with the
> > > behaviour of c2.nstld.net.
> > 
> > I mis-read.  192.26.92.31 is c2.nstld.net so someone at RedHat has
> > hacked dig to return " ;; Got referral reply from 192.26.92.31,
> > trying next server" when it see a referral and move onto the next
> > address which is a IPv6 addresss which presumably you don't have
> > connectivity for.
> > 
> > Try "dig -4 @c2.nstld.com mobilecdn.verisign.com".  Then yell at
> > RedHat.  Dig is not supposed to move on when it sees a referral.
> > Dig is a diagnostic tool first and foremost, not a general hostname
> > lookup tool.  One needs to see the answers to queries in a
> > diagnostic tool not have them skipped.
> > 
> 
> Hmm... you're right. Using the self compiled dig doesn't return the
> referral notice.
> 
> Still I'm not sure why named can't resolve the hostname and always
> breaks with a servfail. Shouldn't it just skip servers which ran into
> a timeout and try the next (even though this might take a bit longer
> to resolve)?
> 
> 
> Anyway, there must have been some sort of error somewhere 'cause now
> resolving is working perfectly fine again.
> 
> 



It happened again... only this time, I have network packets of working
queries and those answered with servfail by the local resolver.

What I've done:
I've flushed the cache, made a dig to the local resolver and at the
same time captured the network traffic.

The disturbing part about it is, that both times (those queries
resolving and those ending in a servfail) the last packet seen is an
answer packet from dns2.m-qube.com (64.14.96.64) and both look okay to
me. I wonder why named sometimes responds with a servfail and most of
the time not.


Ciao
Torsten