strange behaviour of resolving nameserver

Tue Mar 9 13:44:46 UTC 2010

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.

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

>     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