strange behaviour of resolving nameserver
imfeldma at gmail.com
imfeldma at gmail.com
Tue Mar 9 15:24:02 UTC 2010
Torsten,
ws.mobilecdn.verisign.com. doesn't answer for me either.
It's supposed to be authoritatively hosted here:
mobilecdn.verisign.com. 900 IN NS dns1-auth.m-qube.com.
mobilecdn.verisign.com. 900 IN NS dns2-auth.m-qube.com.
But neither of them answer an iterative query for me, be it a SOA for mobilecdn.verisign.com. or the ultimately desired ws.mobilecdn.verisign.com. Not sure this is really your fault, unless of course the '-auth' means only certain people are allowed to query.
-mat
On Mar 9, 2010, at 3:40 PM, Torsten wrote:
> 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.
>
>>
>>> ; <<>> 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
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
More information about the bind-users
mailing list