strange behaviour of resolving nameserver

[Sam Wilson]

In article <mailman.751.1268170620.21153.bind-users at lists.isc.org>,
 Mark Andrews <marka at isc.org> wrote:

> 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.

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