[rescue] Odd DNS problem with Solaris 8
Greg A. Woods
rescue at sunhelp.org
Mon Nov 12 13:01:15 CST 2001
[ On Sunday, November 11, 2001 at 20:12:35 (-0500), Steve Sandau wrote: ]
> Subject: Re: [rescue] Odd DNS problem with Solaris 8
>
> Here's the conversation for the failed lookup:
>
> 19:38:32.489204 milhouse.sandau.33794 > marge.sandau.domain: 29957+ (45)
> (DF) (ttl 255, id 53207)
> 19:38:32.490277 marge.sandau.domain > milhouse.sandau.33794: 29957
> NXDomain* q: www.cc-soluti 0/1/0 (103) (ttl 64, id 16300)
Hmmm.... I assume you have the raw packets, and that you captured them
in full (i.e. "tcpdump -s 1500" or whatever). If so please post the
output of 'tcpdump -vvv -r -n' on that file.
> 19:38:32.493792 milhouse.sandau.33795 > marge.sandau.domain: 29958+ (52)
> (DF) (ttl 255, id 53208)
> 19:38:32.515471 marge.sandau.domain > milhouse.sandau.33795: 29958
> NXDomain* q: www.cc-soluti 0/1/0 (103) (ttl 64, id 16303)
> 19:38:32.519182 milhouse.sandau.33796 > marge.sandau.domain: 29959+ (47)
> (DF) (ttl 255, id 53209)
> 19:38:32.558194 marge.sandau.domain > milhouse.sandau.33796: 29959
> NXDomain* q: www.cc-soluti 0/1/0 (97) (ttl 64, id 16307)
>
> And this one is the successful lookup. (Yeah, it took me a while to
> realize that I wanted a comparison.. so I'm a little slow...):
>
> 20:04:24.446877 milhouse.sandau.33803 > marge.sandau.domain: 29960+ (38)
> (DF) (ttl 255, id 9239)
> 20:04:24.718001 marge.sandau.domain > milhouse.sandau.33803: 29960* q:
> www.cc-soluti 2/3/3 . (183) (ttl 64, id 17003)
The other thing you should try to do is to capture the queries made to
the Internet by your nameserver, and perhaps also do a dump of your
nameserver cache and poke around in it to find out where it learned the
records it has (you'll need ``host-statistics yes;'' in the options
section of your named.conf to keep track of where queries were learned).
I'm assuming you're looking up www.cc-solutions.com (which is why I want
the '-vvv' output! ;-). If so I'll note that it's a CNAME:
$ host -t a www.cc-solutions.com
www.cc-solutions.com CNAME cc-solutions.com
cc-solutions.com A 207.159.130.219
However I think the real problem is that this particular zone has
somewhat unreliable nameservers and you're just not always able to
resolve the A RR for the CNAME target. I noted there was a significant
delay between the printing of the first line and the printing of the
second one above.
I don't know about you, but I'm a long and lossy way away from their
nameservers too, and all the loss seems to be on the last hop. That
would make it very very easy for either one of the query packets, or one
of the responses, to get lost!
$ /usr/sbin/traceroute -n ns1.nameserve.net
traceroute to ns1.nameserve.net (207.159.128.3), 30 hops max, 40 byte packets
1 204.92.254.6 1.959 ms 1.375 ms 1.230 ms
2 216.138.200.153 7.210 ms 6.643 ms 7.006 ms
3 216.138.255.41 7.045 ms 7.791 ms 6.965 ms
4 216.138.255.4 9.500 ms 8.092 ms 6.795 ms
5 216.187.68.57 18.181 ms 7.914 ms 7.021 ms
6 216.187.68.10 22.126 ms 18.548 ms 19.125 ms
7 216.187.90.6 45.498 ms 48.516 ms 43.819 ms
8 208.175.103.205 44.950 ms 48.197 ms 46.148 ms
9 206.24.194.101 45.711 ms 45.564 ms 45.790 ms
10 206.24.207.193 46.538 ms 45.857 ms 45.164 ms
11 206.24.207.186 46.452 ms 75.156 ms 45.391 ms
12 206.24.194.62 58.961 ms 70.736 ms 47.700 ms
13 206.24.193.246 40.023 ms 36.376 ms 36.813 ms
14 152.63.24.102 36.181 ms 33.398 ms 34.957 ms
15 152.63.23.133 34.954 ms 42.993 ms 43.253 ms
16 152.63.0.106 96.256 ms 97.965 ms 96.156 ms
17 152.63.145.238 98.839 ms 96.100 ms 94.534 ms
18 152.63.106.234 98.903 ms 95.152 ms 97.766 ms
19 146.188.201.29 95.145 ms 97.776 ms 95.990 ms
20 157.130.213.230 135.399 ms 133.510 ms 130.657 ms
21 216.122.94.8 132.174 ms 133.038 ms 131.432 ms
22 * 207.159.128.2 131.221 ms *
NS3.nameserve.net doesn't seem to actually be on a different network
up-stream though, and it is experiencing similar loss on the last hop:
$ /usr/sbin/traceroute -n ns3.nameserve.net
traceroute to ns3.nameserve.net (207.159.153.115), 30 hops max, 40 byte packets
1 204.92.254.6 1.346 ms 0.528 ms 0.532 ms
2 216.138.200.153 5.567 ms 6.111 ms 5.838 ms
3 216.138.255.41 7.882 ms 6.581 ms 6.516 ms
4 216.138.255.4 6.222 ms 6.411 ms 7.895 ms
5 216.187.68.57 7.053 ms 6.586 ms 6.677 ms
6 216.187.68.10 16.119 ms 15.897 ms 14.907 ms
7 216.187.90.6 44.893 ms 43.624 ms 43.433 ms
8 208.175.103.205 44.197 ms 47.138 ms 44.374 ms
9 206.24.194.101 49.627 ms 47.190 ms 45.303 ms
10 206.24.207.193 44.921 ms 53.141 ms 49.626 ms
11 206.24.207.186 46.071 ms 44.477 ms 48.779 ms
12 206.24.194.62 52.960 ms 45.191 ms 44.089 ms
13 206.24.193.246 40.306 ms 38.542 ms 35.698 ms
14 152.63.24.98 36.323 ms 36.176 ms 36.539 ms
15 152.63.23.117 35.436 ms 35.583 ms 36.338 ms
16 152.63.0.66 95.019 ms 95.848 ms 95.471 ms
17 152.63.38.82 112.420 ms 112.020 ms 110.944 ms
18 152.63.106.226 114.614 ms 110.610 ms 113.561 ms
19 146.188.201.33 94.967 ms 95.809 ms 94.710 ms
20 157.130.213.230 130.667 ms 132.139 ms 130.626 ms
21 216.122.94.9 133.399 ms 215.109 ms 134.685 ms
22 207.159.153.114 132.718 ms * 130.824 ms
I'll also note there's a discrepancy between their registered auth
nameserver list, and the ones provided within their zone file:
Domain Name: CC-SOLUTIONS.COM
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
Name Server: NS1.NAMESERVE.NET
Name Server: NS2.NAMESERVE.NET
Updated Date: 05-nov-2001
$ host -r -t ns cc-solutions.com ns1.nameserve.net
cc-solutions.com NS ns3.nameserve.net
cc-solutions.com NS ns1.nameserve.net
cc-solutions.com NS ns2.nameserve.net
As a side-note remember that when you do the first lookup of that name
you'll fetch just the first two NS records, and the initial answer will
thus be fetched from one of the first two nameservers, and likely when
the CNAME is resolved it'll still hit one of the first two nameservers.
It's really sad to see someone who's apparently supposed to be in the
business of providing DNS (i.e. nameserve.net) to have such a lame and
broken configuration (i.e. no network topology diversity in their
nameservers, discrepancies between in-zone and exterior delegations, and
many more I didn't document here)!
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods at acm.org> <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; Secrets of the Weird <woods at weird.com>
More information about the rescue
mailing list