[rescue] Odd DNS problem with Solaris 8
Steve Sandau
rescue at sunhelp.org
Mon Nov 12 14:17:56 CST 2001
In other words... For troubleshooting the Solaris DNS oddities, I have
picked a bad example! I'll run tcpdump with the flags you mention and
see what a missed connection looks like.
No, I wasn't capturing the contents of all the packets. I had to run
this for several hours before actually getting an error. (Hrm. Seemed to
error out much more often when I wasn't looking.)
More info later.
"Greg A. Woods" wrote:
>
> [ 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>
> _______________________________________________
> rescue maillist - rescue at sunhelp.org
> http://www.sunhelp.org/mailman/listinfo/rescue
--
Steve Sandau, IS Technician
TMA Bath, Maine
ssandau at bath.tmac.com
More information about the rescue
mailing list