In article <mailman.751.1268170620.21153.bind-us...@lists.isc.org>, Mark Andrews <ma...@isc.org> wrote:
> 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. There's also a lame delegation. Here's an extract from "dig ws.mobilecdn.verisign.com +trace": : : mobilecdn.verisign.com. 900 IN NS dns2-auth.m-qube.com. mobilecdn.verisign.com. 900 IN NS dns1-auth.m-qube.com. ;; Received 98 bytes from 192.5.6.31#53(a2.nstld.com) in 119 ms ws.mobilecdn.verisign.com. 1800 IN A 64.14.95.24 mobilecdn.verisign.com. 1800 IN NS dns2-auth.m-qube.com. mobilecdn.verisign.com. 1800 IN NS dns3-auth.m-qube.com. mobilecdn.verisign.com. 1800 IN NS ns1.savvis.net. mobilecdn.verisign.com. 1800 IN NS ns2.savvis.net. mobilecdn.verisign.com. 1800 IN NS ns3.savvis.net. ;; Received 178 bytes from 64.14.95.64#53(dns2-auth.m-qube.com) in 90 ms dns1-auth.m-qube.com does not respond, at least to me, and will also cause delays or failures because it is a CNAME for dns1.m-qube.com. Sam _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
