Am Wed, 10 Mar 2010 08:34:41 +0100 schrieb Torsten <t...@the-damian.de>:
> Am Wed, 10 Mar 2010 08:36:54 +1100 > schrieb Mark Andrews <ma...@isc.org>: > > > > > In message <20100309154017.4801c...@the-damian.de>, Torsten writes: > > > Am Wed, 10 Mar 2010 00:44:46 +1100 > > > schrieb Mark Andrews <ma...@isc.org>: > > > > > > > > > > > In message <20100309142153.016c7...@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 _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
