strange behaviour of resolving nameserver

Torsten toto at the-damian.de
Wed Mar 10 07:34:41 UTC 2010


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.


Ciao
Torsten


 



More information about the bind-users mailing list