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. > > > ; <<>> 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@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
