Re: strange behaviour of resolving nameserver
Am Wed, 10 Mar 2010 00:44:46 +1100 schrieb Mark Andrews : > > 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. TimeSourceDestination > > Protocol Info 4 3.529927192.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) 00.. = Differentiated Services Codepoint: Default (0x00) > > ..0. = ECN-Capable Transport (ECT): 0 > > ...0 = ECN-CE: 0 > > Total Length: 126 > > Identification: 0x (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 = > > 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
Re: strange behaviour of resolving nameserver
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. > ; <<>> 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. TimeSourceDestination > Protocol Info 4 3.529927192.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) > 00.. = Differentiated Services Codepoint: Default (0x00) > ..0. = ECN-Capable Transport (ECT): 0 > ...0 = ECN-CE: 0 > Total Length: 126 > Identification: 0x (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 = 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: mob
Re: strange behaviour of resolving nameserver
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 : > >> >> 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. TimeSourceDestination >>> Protocol Info 4 3.529927192.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) 00.. = Differentiated Services Codepoint: Default (0x00) >>> ..0. = ECN-Capable Transport (ECT): 0 >>> ...0 = ECN-CE: 0 >>>Total Length: 126 >>>Identification: 0x (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
strange behaviour of resolving nameserver
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 ; <<>> 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. TimeSourceDestination Protocol Info 4 3.529927192.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) 00.. = Differentiated Services Codepoint: Default (0x00) ..0. = ECN-Capable Transport (ECT): 0 ...0 = ECN-CE: 0 Total Length: 126 Identification: 0x (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 = 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) 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
dnsquery for Solaris
Hello everyone,
Can somebody suggest a place where from I can download dnsquery source/pkg to
make it work on Solaris 10?
I have it installed on a FreeBSD machine but imported to Solaris is reporting
some syntax error
# dnsquery www.google.com
dnsquery: syntax error at line 1: `(' unexpected
Thank you,
Julian
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsquery for Solaris
On Tue, 9 Mar 2010, ic.nssip wrote:
> Can somebody suggest a place where from I can download dnsquery source/pkg
> to make it work on Solaris 10?
It is available in old BIND 8 source.
> I have it installed on a FreeBSD machine but imported to Solaris is
> reporting some syntax error
>
> # dnsquery www.google.com
> dnsquery: syntax error at line 1: `(' unexpected
FreeBSD executables don't run on Solaris.
Instead of dnsquery, can you use dig or host instead?___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsquery for Solaris
I find it useful to test records cache time.
I'll check on BIND 8 package.
Thank you for pointing to a Solaris compatible source.
Julian
- Original Message -
From: "Jeremy C. Reed"
To: "ic.nssip"
Cc:
Sent: Tuesday, March 09, 2010 10:56 AM
Subject: Re: dnsquery for Solaris
On Tue, 9 Mar 2010, ic.nssip wrote:
Can somebody suggest a place where from I can download dnsquery source/pkg
to make it work on Solaris 10?
It is available in old BIND 8 source.
I have it installed on a FreeBSD machine but imported to Solaris is
reporting some syntax error
# dnsquery www.google.com
dnsquery: syntax error at line 1: `(' unexpected
FreeBSD executables don't run on Solaris.
Instead of dnsquery, can you use dig or host instead?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsquery for Solaris
In article , "ic.nssip" wrote: > I find it useful to test records cache time. dig tells you that. > I'll check on BIND 8 package. > Thank you for pointing to a Solaris compatible source. Use dig from a recent BIND package, though you may find it's already there - ours is in /usr/local/bin/dig on our Solaris systems and was installed with BIND 9. I don't know whether it's there if you use the Solaris-supplied BIND. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsquery for Solaris
On Mar 9 2010, Sam Wilson wrote: In article , "ic.nssip" wrote: I find it useful to test records cache time. dig tells you that. I'll check on BIND 8 package. Thank you for pointing to a Solaris compatible source. Use dig from a recent BIND package, though you may find it's already there - ours is in /usr/local/bin/dig on our Solaris systems and was installed with BIND 9. I don't know whether it's there if you use the Solaris-supplied BIND. Sure it is: $ ls -l /usr/sbin/dig -r-xr-xr-x 1 root bin75208 Jul 29 2008 /usr/sbin/dig $ fgrep /usr/sbin/dig /var/sadm/install/contents /usr/sbin/dig f none 0555 root bin 75208 48119 121715 SUNWbind (that's a 9.3.5-P1 dig, from a not very up-to-date Solaris 10 installation, but it's been around in Solaris distributions much longer than that). -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsquery for Solaris
dig was added to Solaris 9. It is not native to Solaris 8 or older. Chris Thompson wrote: > On Mar 9 2010, Sam Wilson wrote: > > >In article , > > "ic.nssip" wrote: > > > >> I find it useful to test records cache time. > > > >dig tells you that. > > > >> I'll check on BIND 8 package. > >> Thank you for pointing to a Solaris compatible source. > > > >Use dig from a recent BIND package, though you may find it's already > >there - ours is in /usr/local/bin/dig on our Solaris systems and was > >installed with BIND 9. I don't know whether it's there if you use the > >Solaris-supplied BIND. > > Sure it is: > > $ ls -l /usr/sbin/dig > -r-xr-xr-x 1 root bin75208 Jul 29 2008 /usr/sbin/dig > $ fgrep /usr/sbin/dig /var/sadm/install/contents > /usr/sbin/dig f none 0555 root bin 75208 48119 121715 SUNWbind > > (that's a 9.3.5-P1 dig, from a not very up-to-date Solaris 10 installation, > but it's been around in Solaris distributions much longer than that). > > -- > Chris Thompson University of Cambridge Computing Service, > Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH, > Phone: +44 1223 334715 United Kingdom. > ___ > 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
Re: strange behaviour of resolving nameserver
In message <20100309154017.4801c...@the-damian.de>, Torsten writes: > Am Wed, 10 Mar 2010 00:44:46 +1100 > schrieb Mark Andrews : > > > > > 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. TimeSourceDestination > > > Protocol Info 4 3.529927192.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) 00.. = Differentiated Services Codepoint: Default (0x00) > > > ..0. = ECN-Capable Transport (ECT): 0 > > > ...0 = ECN-CE: 0 > > > Total Length: 126 > > > Identification: 0x (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
Re: dnsquery for Solaris
I've got dnsquery working fine from sunfreeware.com bind-8.4.6 on x86-Solaris 10. Does anybody knows if it can be exported to another machine? I tried to binary ftp the file to another machine (same configuration), I fixed owner and permissions but will just not run there. Does it has some dependencies? Is any chance I can find a Windows version of this dnsquery command (as there is one distribution only for dig)? Thank you, Julian On Mar 9 2010, Sam Wilson wrote: In article , "ic.nssip" wrote: I find it useful to test records cache time. dig tells you that. I'll check on BIND 8 package. Thank you for pointing to a Solaris compatible source. Use dig from a recent BIND package, though you may find it's already there - ours is in /usr/local/bin/dig on our Solaris systems and was installed with BIND 9. I don't know whether it's there if you use the Solaris-supplied BIND. Sure it is: $ ls -l /usr/sbin/dig -r-xr-xr-x 1 root bin75208 Jul 29 2008 /usr/sbin/dig $ fgrep /usr/sbin/dig /var/sadm/install/contents /usr/sbin/dig f none 0555 root bin 75208 48119 121715 SUNWbind (that's a 9.3.5-P1 dig, from a not very up-to-date Solaris 10 installation, but it's been around in Solaris distributions much longer than that). -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. ___ 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
Re: dnsquery for Solaris
ic.nssip wrote: > I've got dnsquery working fine from sunfreeware.com bind-8.4.6 on > x86-Solaris 10. > Does anybody knows if it can be exported to another machine? I tried to > binary ftp the file to another machine (same configuration), I fixed > owner and permissions but will just not run there. Does it has some > dependencies? > > Is any chance I can find a Windows version of this dnsquery command (as > there is one distribution only for dig)? Maybe if you told us what you are trying to do, we might be able to tell you a better tool than something that was not brought forward from BIND8. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsquery for Solaris
What I'm trying to do is to find a way to get the TTL left for a cached record. I usually use dnsquery like this (12m23s and 9m53s is what interest me): # dnsquery -n 8.8.8.8 -t a ftp.funet.fi ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47912 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ftp.funet.fi, type = A, class = IN ftp.funet.fi. 12m23s IN A 193.166.3.2 # # # dnsquery -n 8.8.8.8 -t a ftp.funet.fi ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29770 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ftp.funet.fi, type = A, class = IN ftp.funet.fi. 9m53s IN A 193.166.3.2 Thank you, Julian ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsquery for Solaris
ic.nssip wrote: > What I'm trying to do is to find a way to get the TTL left for a cached > record. > I usually use dnsquery like this (12m23s and 9m53s is what interest me): > > # dnsquery -n 8.8.8.8 -t a ftp.funet.fi > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47912 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; ftp.funet.fi, type = A, class = IN > ftp.funet.fi. 12m23s IN A 193.166.3.2 > # > # > # dnsquery -n 8.8.8.8 -t a ftp.funet.fi > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29770 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; ftp.funet.fi, type = A, class = IN > ftp.funet.fi. 9m53s IN A 193.166.3.2 acl...@yellow:~$ dig +noquestion +nocomments +nostats @8.8.8.8 ftp.funet.fi ; <<>> DiG 9.7.0 <<>> +noquestion +nocomments +nostats @8.8.8.8 ftp.funet.fi ; (1 server found) ;; global options: +cmd ftp.funet.fi. 900 IN A 193.166.3.2 See the 900? There's your TTL. Use dig. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsquery for Solaris
In message <8be7886dd93c4870bd2a8a0d00259...@internal.corp.ds>, "ic.nssip" writ es: > What I'm trying to do is to find a way to get the TTL left for a cached > record. > I usually use dnsquery like this (12m23s and 9m53s is what interest me): > > # dnsquery -n 8.8.8.8 -t a ftp.funet.fi > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47912 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; ftp.funet.fi, type = A, class = IN > ftp.funet.fi. 12m23s IN A 193.166.3.2 > # > # > # dnsquery -n 8.8.8.8 -t a ftp.funet.fi > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29770 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; ftp.funet.fi, type = A, class = IN > ftp.funet.fi. 9m53s IN A 193.166.3.2 > > Thank you, > Julian dig +norec @8.8.8.8 a ftp.funet.fi +noall +answer > 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
Re: dnsquery for Solaris
Mark Andrews writes: > > In message <8be7886dd93c4870bd2a8a0d00259...@internal.corp.ds>, "ic.nssip" wr > it > es: > > What I'm trying to do is to find a way to get the TTL left for a cached > > record. > > I usually use dnsquery like this (12m23s and 9m53s is what interest me): > > > > # dnsquery -n 8.8.8.8 -t a ftp.funet.fi > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47912 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; ftp.funet.fi, type = A, class = IN > > ftp.funet.fi. 12m23s IN A 193.166.3.2 > > # > > # > > # dnsquery -n 8.8.8.8 -t a ftp.funet.fi > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29770 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; ftp.funet.fi, type = A, class = IN > > ftp.funet.fi. 9m53s IN A 193.166.3.2 > > > > Thank you, > > Julian > > dig +norec @8.8.8.8 a ftp.funet.fi +noall +answer dig +norec +noall @8.8.8.8 a ftp.funet.fi +answer +comments ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9254 ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: ftp.funet.fi. 643 IN A 193.166.3.2 > > 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 -- 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
Re: dnsquery for Solaris
Yup! That's what I need. Thank you for all suggestion! Best Wishes! Julian ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: strange behaviour of resolving nameserver
Am Wed, 10 Mar 2010 08:36:54 +1100 schrieb Mark Andrews : > > In message <20100309154017.4801c...@the-damian.de>, Torsten writes: > > Am Wed, 10 Mar 2010 00:44:46 +1100 > > schrieb Mark Andrews : > > > > > > > > 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. > Hmm... you're right. Using the self compiled dig doesn't return the referral notice. Still I'm not sure why named can't resolve the hostname and always breaks with a servfail. Shouldn't it just skip servers which ran into a timeout and try the next (even though this might take a bit longer to resolve)? Anyway, there must have been some sort of error somewhere 'cause now resolving is working perfectly fine again. Ciao Torsten ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
