Re: router causing strange DNS behaviour?

From: prg (rdgentry1_at_cablelynx.com)
Date: 05/20/05 

Date: 19 May 2005 21:48:21 -0700

Moe Trin wrote:
> In article <1116438813.706913.92640@g47g2000cwa.googlegroups.com>,
prg wrote:
> >
> >James Muir wrote:
>
> >> ; <<>> DiG 9.2.2 <<>> @199.166.27.253 www.nserc.ca +noall +answer
+stats
> >> ;; global options: printcmd
> >> ;; connection timed out; no servers could be reached
>
> I'm not a 'dig' person, but there is a '+trace' option that might be
> helpful.
>
> >I could not dig these (Rosger's?) server(s) either. First query
> >returned "Administratively prohibited". Others just timed out, but
> >they were (re)directed to another server/network in the domain.
>
> Wouldn't totally surprise me. A number of providers block access to
> their servers for queries from external addresses for external
addresses.
> Still, if you got a redirect.... no, wait. If you do a whois for
rogers,
> or look up a host (I'm using host -a), you are referred to four
hosts:
>
> ns1.ym.rnc.net.cable.rogers.com 24.153.22.141
> ns1.wlfdle.rnc.net.cable.rogers.com 24.153.22.13
> ns2.ym.rnc.net.cable.rogers.com 24.153.22.142
> ns2.wlfdle.rnc.net.cable.rogers.com 24.153.22.14
>
> but if you look up 24.153.22.67 and 24.153.22.195, they are
>
> dns.wlfdle.rnc.net.cable.rogers.com 24.153.22.67
> dns.ym.rnc.net.cable.rogers.com 24.153.22.195
>
> Suspicion: 'dns.<mumble>.rogers.com' is for customers, while the
unwashed
> masses out here are supposed to use ns?.<mumble>.rogers.com.

Could very well be the case. These cobbled together ISP networks can
be Byzantine. That's why I like poking at them with traceroute just to
see where they let me go before dropping packets. It's not very
efficient but turns up surprising results sometimes ;)

> >> Apparently the router (a D-link DI 604) just relays DNS queries to
the
> >> DNS server. I tried inserting my ISP's DNS server in
/etc/resolv.conf
> >> but it didn't help.
> >
> >As near as I can tell from the manual, your d-link is DNS dumb and
just
> >forwards the IP/UDP/DNS packets.
>
> WHOOPS! Is that an intentional red flag you are waving? What about
TCP
> queries? In theory, the only reason to use TCP would be when the UDP
> reply has the 'Truncated' flag set. For a bare bones query, the
response
> should be less than 512 bytes, but if you ask for more information,
the
> resulting response could be greater than that.

Nope, no flags, just quick-n-dirty putzing while killing an hour. Had
the d-link manual already and just checked that it did not try to do
any cacheing.

All my queries (then and below) used default UDP and UDP was all that
was used. OP seemed concerned about the "Warnings" so ...

> Now on the other hand, I just tried to look up www.nserc.ca using dig
and
> tcpdump, and dig timed out - about two and six seconds before the
replies
> from the two name servers I have listed in /etc/resolv.conf appeared
over
> the wire. Repeating the query got the answer from my name server's
cache.
>
> My take on this is that the name servers for nserc.ca being in the
Great
> White North (I was going to say North of the frozen tundra, but they
are
> in Ottawa, about 1000 clicks East of Lambeau Field), the servers are
sitting
> around a fire trying to keep warm, and it takes time for them to pull
their
> fingers out. ;-) What happens if you set the timeout in dig?
>
> Let me back up here for a moment:
>
> >> ; <<>> DiG 9.2.2 <<>> @205.166.226.38 www.nserc.ca +noall +answer
+stats
> >> ;; global options: printcmd
> >> www.nserc.ca. 3518 IN A 198.96.3.190
> >> ;; Query time: 138 msec
>
> >> ; <<>> DiG 9.2.2 <<>> @199.166.31.3 www.nserc.ca +noall +answer
+stats
> >> ;; global options: printcmd
> >> www.nserc.ca. 2731 IN A 198.96.3.190
> >> ;; Query time: 102 msec
>
> Those two answers are cached. When I query a un-cached servers, I'm
told
> that the TTL for www.nserc.ca is 3600 seconds.
>
> >My response time to this server (205.166.226.38) was fast enough.
> >$ ping -c4 205.166.226.38
>
> >rtt min/avg/max/mdev = 51.542/54.128/57.290/2.087 ms
>
> Well, yes but, that's not querying the round trip time of a DNS
query.
> That's just the time to the network stack.

Yep, but better than nothing as I ran out of my hour.

Tonights timed queries were quite good (once my ISP got out of the way
looking up names for ethereal). Initial query took about 4.5 secs
start to finish with the query time (from trace):
dig @205.166.226.38 www.farmimplement.com +short
 Standard query A www.farmimplement.com: (small town in central
Arkansas)
     33 5.471462
     34 5.636152

Other equally small(er) towns (govts):

; <<>> DiG 9.2.1 <<>> @205.166.226.38 www.cityofsearcy.org
;; Query time: 156 msec
;; SERVER: 205.166.226.38#53(205.166.226.38)
;; WHEN: Thu May 19 22:37:50 2005
;; MSG SIZE rcvd: 104

I'm at my parents near Searcy -- about 20 miles from where the Ivory
Billed Woodpecker was "rediscovered" ;)

; <<>> DiG 9.2.1 <<>> @205.166.226.38 weiser.govoffice.com
[in SW Idaho]
;; Query time: 382 msec
;; SERVER: 205.166.226.38#53(205.166.226.38)
;; WHEN: Thu May 19 22:41:39 2005
;; MSG SIZE rcvd: 54

; <<>> DiG 9.2.1 <<>> @205.166.226.38 www.buhlidaho.us
[in S Central Idaho]
;; Query time: 322 msec
;; SERVER: 205.166.226.38#53(205.166.226.38)
;; WHEN: Thu May 19 22:50:27 2005
;; MSG SIZE rcvd: 140

Can't see why OP could not use this for a name server if it _is_ a
Rogers DNS issue instead of his router.

> >You might want to capture packets with ethereal and see just what is
> >being passed between your host and the name server. Traceroutes
might
> >be useful too to see just what kind of path packets are traveling
> >inside your ISP's network.
>
> I'm wondering if the time problem isn't the response time of the
> authoritative name server. Heck even the TTL of the rogers.com
servers
> are only 3600 seconds (though the A record times of the external
servers
> seems to be several orders of magnitude greater). I just did a quick
> 'dig @198.96.3.152 www.nserc.ca +noall +answer +stats' and got an
answer
> in 305 msec.

I've seen this network I'm on now go down several times and actually
watched it rebuilding once with ethereal. Talk about garnering a lot
of "interesting" internal network IPs...

It would take maybe a week before getting confident with DNS servers
again and I noticed that during that time they had very short TTLs.
Maybe they are in "maintainence mode" for a while ;)

> >I was "really" surprised that my first dig was "prohibited" and that
> >subsequent queries were redirected (as if my IP had been logged and
> >subsequently re-reouted).
>
> As above. Were you being redirected to one of their external servers?

I think it was only two nodes in on the subsequent dig attempts.
That's why I thought I might have been flagged since I got "all the
way" the first time.

> >After being "prohibited" I got no farther than (IIRC):
> >gw02.ym.phub.net.cable.rogers.com (66.185.81.189)
>
> As a traceroute? Sure - you aren't trying to reach the DNS server
> ports. Traceroute has a -p option, but I think this refers to the
> starting port number (incremented per hop). You might want to look at
> the more capable 'tcptraceroute'.

Just lack of time and failure to save to file between captures ;)

Actually the OP's symptoms seemed a mixture of possible problems:
-- ISP's internal workings
-- ISP's name servers
-- dslreports FAQ on Rogers saying that his d-link was flakey with
certain Terayon modems used by Rogers

Had to leave _something_ for OP to investigate ;)

regards,
prg
email above disabled