In message <20100309154017.4801c...@the-damian.de>, Torsten writes: > 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.
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@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: ma...@isc.org _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users