strange behaviour of resolving nameserver
Mark Andrews
marka at isc.org
Tue Mar 9 21:36:54 UTC 2010
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.
> > > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.1 <<>> @c2.nstld.com
> > > mobilecdn.verisign.com ; (2 servers found)
> > > ;; global options: printcmd
> > > ;; connection timed out; no servers could be reached
> > >
> > >
> > > This happens only if the hostname is used in a dig. Using the ipv4
> > > address everything turns out fine.
> > >
> > > What's even more strange is the answer packet received (at least I
> > > can't see any errors there).
> > >
> > >
> > > No. Time Source Destination
> > > Protocol Info 4 3.529927 192.26.92.31 10.10.3.22
> > > DNS Standard query response
> > >
> > > Frame 4 (140 bytes on wire, 140 bytes captured)
> > > Arrival Time: Mar 9, 2010 13:33:49.987181000
> > > [Time delta from previous captured frame: 0.086282000 seconds]
> > > [Time delta from previous displayed frame: 0.086282000 seconds]
> > > [Time since reference or first frame: 3.529927000 seconds]
> > > Frame Number: 4
> > > Frame Length: 140 bytes
> > > Capture Length: 140 bytes
> > > [Frame is marked: True]
> > > [Protocols in frame: eth:ip:udp:dns]
> > > [Coloring Rule Name: UDP]
> > > [Coloring Rule String: udp]
> > > Ethernet II, Src: Cisco_46:45:d3 (00:04:27:46:45:d3), Dst:
> > > HewlettP_08:78:76 (00:1f:29:08:78:76) Destination: HewlettP_08:78:76
> > > (00:1f:29:08:78:76) Address: HewlettP_08:78:76 (00:1f:29:08:78:76)
> > > .... ...0 .... .... .... .... = IG bit: Individual address
> > > (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique
> > > address (factory default) Source: Cisco_46:45:d3 (00:04:27:46:45:d3)
> > > Address: Cisco_46:45:d3 (00:04:27:46:45:d3)
> > > .... ...0 .... .... .... .... = IG bit: Individual address
> > > (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique
> > > address (factory default) Type: IP (0x0800)
> > > Internet Protocol, Src: 192.26.92.31 (192.26.92.31), Dst: 10.10.3.22
> > > (10.10.3.22) Version: 4
> > > Header length: 20 bytes
> > > Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN:
> > > 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00)
> > > .... ..0. = ECN-Capable Transport (ECT): 0
> > > .... ...0 = ECN-CE: 0
> > > Total Length: 126
> > > Identification: 0x0000 (0)
> > > Flags: 0x02 (Don't Fragment)
> > > 0.. = Reserved bit: Not Set
> > > .1. = Don't fragment: Set
> > > ..0 = More fragments: Not Set
> > > Fragment offset: 0
> > > Time to live: 58
> > > Protocol: UDP (0x11)
> > > Header checksum: 0x1716 [correct]
> > > [Good: True]
> > > [Bad : False]
> > > Source: 192.26.92.31 (192.26.92.31)
> > > Destination: 10.10.3.22 (10.10.3.22)
> > > User Datagram Protocol, Src Port: domain (53), Dst Port: 48885
> > > (48885) Source port: domain (53)
> > > Destination port: 48885 (48885)
> > > Length: 106
> > > Checksum: 0x1190 [validation disabled]
> > > [Good Checksum: False]
> > > [Bad Checksum: False]
> > > Domain Name System (response)
> > > [Request In: 3]
> > > [Time: 0.086282000 seconds]
> > > Transaction ID: 0x3824
> > > Flags: 0x8100 (Standard query response, No error)
> > > 1... .... .... .... = Response: Message is a response
> > > .000 0... .... .... = Opcode: Standard query (0)
> > > .... .0.. .... .... = Authoritative: Server is not an
> > > authority for domain .... ..0. .... .... = Truncated: Message is
> > > not truncated .... ...1 .... .... = Recursion desired: Do query
> > > recursively .... .... 0... .... = Recursion available: Server can't
> > > do recursive queries .... .... .0.. .... = Z: reserved (0)
> > > .... .... ..0. .... = Answer authenticated: Answer/authority
> > > portion was not authenticated by the server .... .... .... 0000 =
> > > Reply code: No error (0) Questions: 1
> > > Answer RRs: 0
> > > Authority RRs: 2
> > > Additional RRs: 0
> > > Queries
> > > ws.mobilecdn.verisign.com: type A, class IN
> > > Name: ws.mobilecdn.verisign.com
> > > Type: A (Host address)
> > > Class: IN (0x0001)
> >
> > ws.mobilecdn.verisign.com != mobilecdn.verisign.com so this packet is
> > *not* a response to the query made by dig.
>
> Sorry, my fault... I tried several different things and obviously
> pasted the wrong packet. The answer packet of a query for
> mobilecdn.verisign.com looks the same though.
>
> >
> > > Authoritative nameservers
> > > mobilecdn.verisign.com: type NS, class IN, ns
> > > dns2-auth.m-qube.com Name: mobilecdn.verisign.com
> > > Type: NS (Authoritative name server)
> > > Class: IN (0x0001)
> > > Time to live: 15 minutes
> > > Data length: 19
> > > Name server: dns2-auth.m-qube.com
> > > mobilecdn.verisign.com: type NS, class IN, ns
> > > dns1-auth.m-qube.com Name: mobilecdn.verisign.com
> > > Type: NS (Authoritative name server)
> > > Class: IN (0x0001)
> > > Time to live: 15 minutes
> > > Data length: 12
> > > Name server: dns1-auth.m-qube.com
> > >
> > >
> > >
> > > Asking any of the other nameservers responsible for
> > > verisign.com about mobilecdn.verisign.com works just fine and they
> > > all return with a proper answer.
> > >
> > > As a workaround I have set c2.nstld.net to bogus but I'm still
> > > unsure what the real cause for this problem is.
> > >
> > > Any ideas?
> > >
> > >
> > >
> > > Ciao
> > > Torsten
> > > _______________________________________________
> > > bind-users mailing list
> > > bind-users at lists.isc.org
> > > https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users
mailing list