router causing strange DNS behaviour?

I've been experiencing some strange DNS behaviour from behind my router (a
DLink DI-604 with fully up-to-date firmware) and I wondered if someone here
might be able to enlighten me as to the cause.

Here's what I'm dealing with. I want to access the web page www.nserc.ca
[198.96.3.190] from behind my router. When I put

http://www.nserc.ca

in my browser I get a "host not found" error. Very occassionally (maybe 1
in 15 times) the web page will come up. When I put

http://198.96.3.190

in my browser everything works fine. I can get through to the web site no
problem using the numeric IP. (I should add that a month ago I wasn't
experiencing any of these difficulties).

So it seems like there is some DNS issue. I have repeatedly queried my
DNS server using "dig www.nserc.ca +short". Here are some of the results:

Thu May 12 21:46:26 EDT 2005
; <<>> DiG 9.2.2 <<>> www.nserc.ca +short
;; global options: printcmd
;; connection timed out; no servers could be reached

Thu May 12 21:46:41 EDT 2005
; <<>> DiG 9.2.2 <<>> www.nserc.ca +short
;; global options: printcmd
;; connection timed out; no servers could be reached

Thu May 12 21:46:56 EDT 2005
;; Warning: ID mismatch: expected ID 38020, got 40564
; <<>> DiG 9.2.2 <<>> www.nserc.ca +short
;; global options: printcmd
;; connection timed out; no servers could be reached

Thu May 12 21:47:11 EDT 2005
198.96.3.190

Thu May 12 21:47:21 EDT 2005
;; Warning: ID mismatch: expected ID 64552, got 38020
;; Warning: ID mismatch: expected ID 64552, got 38020
; <<>> DiG 9.2.2 <<>> www.nserc.ca +short
;; global options: printcmd
;; connection timed out; no servers could be reached

Thu May 12 21:47:36 EDT 2005
;; Warning: ID mismatch: expected ID 26784, got 47818
; <<>> DiG 9.2.2 <<>> www.nserc.ca +short
;; global options: printcmd
;; connection timed out; no servers could be reached

As you can see, on the fourth query the DNS server was able to resolve the
IP address. But, the majority of the time, the query just times out.

When I query a different DNS server, there's no problem:

$ dig @199.166.31.3 www.nserc.ca +short
198.96.3.190
$ dig @199.166.31.3 www.nserc.ca +short
198.96.3.190
$ dig @199.166.31.3 www.nserc.ca +short
198.96.3.190

Now, the weird part is that this problem seems to magically go away when I
remove the router. That is, when I'm plugged in directly to my modem the
DNS queries come back undamaged and entering http://www.nserc.ca into my
browser works fine.

I've been using the router and modem together for about 20 months without
any problems. I am having a hard time accepting the fact that the router is
at fault. My ISP claims that the DNS server is fine.

Any ideas or explanations?

-James

In article <(E-Mail Removed) erloo.ca>,
James Muir wrote:

>When I put
>
>http://www.nserc.ca
>
>in my browser I get a "host not found" error. Very occassionally (maybe 1
>in 15 times) the web page will come up. When I put
>
>http://198.96.3.190
>
>in my browser everything works fine.

That's certainly a DNS issue, but remember that your browser is merely an
application that is using the resolver code in the kernel.

>(I should add that a month ago I wasn't experiencing any of these
>difficulties).

Well, the question all admins hate to ask is "What did you change?"

>So it seems like there is some DNS issue. I have repeatedly queried my
>DNS server using "dig www.nserc.ca +short".

The only thing that 'dig' (and other DNS query tools) do differently from
what the normal name resolution process does is that these tools ignore
/etc/host.conf and /etc/nsswitch.conf.

>;; connection timed out; no servers could be reached

That's pretty explicit.

>When I query a different DNS server, there's no problem:

which should be a clue.

Possibility 1. The addresses you have in /etc/resolv.conf for nameservers
are no longer correct. Is this router running a DHCP server that is telling
your system to use some stupid nameserver address (like it's own)?

Possibility 2. You've got a firewall rule problem. This can happen when
you have some 'automatically block anyone who attacks you' helper, and
one of your "friends' hit you with a tool like nmap using the -D option.
Wouldn't be the first time some one shot their own foot.

>Now, the weird part is that this problem seems to magically go away when I
>remove the router. That is, when I'm plugged in directly to my modem the
>DNS queries come back undamaged and entering http://www.nserc.ca into my
>browser works fine.

So look at /etc/resolv.conf now. Different? If not, it's likely a firewall
fiasco on your router.

>I am having a hard time accepting the fact that the router is at fault.

because?

>My ISP claims that the DNS server is fine.

Probably so - and when you bypass the router, things are OK.

Old guy

On Fri, 13 May 2005, Moe Trin wrote:

> In article <(E-Mail Removed) erloo.ca>,
> James Muir wrote:
>
> >When I put
> >
> >http://www.nserc.ca
> >
> >in my browser I get a "host not found" error. Very occassionally (maybe 1
> >in 15 times) the web page will come up. When I put
> >
> >http://198.96.3.190
> >
> >in my browser everything works fine.
>
> That's certainly a DNS issue, but remember that your browser is merely an
> application that is using the resolver code in the kernel.
>
> >(I should add that a month ago I wasn't experiencing any of these
> >difficulties).
>
> Well, the question all admins hate to ask is "What did you change?"

That's just the thing -- I haven't changed anything. I experience the
problem in both linux and windows.

> >So it seems like there is some DNS issue. I have repeatedly queried my
> >DNS server using "dig www.nserc.ca +short".
>
> The only thing that 'dig' (and other DNS query tools) do differently from
> what the normal name resolution process does is that these tools ignore
> /etc/host.conf and /etc/nsswitch.conf.
>
> >;; connection timed out; no servers could be reached
>
> That's pretty explicit.

What about the "Warning: ID mismatch" on the other queries? Doesn't that
indicate that the queries are getting mangled somehow? And what is special
about www.nser.ca? Why haven't I noticed this behaviour before?

> >When I query a different DNS server, there's no problem:
>
> which should be a clue.
>
> Possibility 1. The addresses you have in /etc/resolv.conf for nameservers
> are no longer correct. Is this router running a DHCP server that is telling
> your system to use some stupid nameserver address (like it's own)?

Yes, the router is running a DHCP server and the nameserver address listed
in /etc/resolv.conf is the address of the router. I have to confess that I
am a bit naive as to why this would be a problem. Isn't this the way it's
supposed to be? (ie. the router talks to my ISP's DHCP server and gets
updated IP addresses for DNS servers, etc, while the settings on my linux
box don't have to change.)

> Possibility 2. You've got a firewall rule problem. This can happen when
> you have some 'automatically block anyone who attacks you' helper, and
> one of your "friends' hit you with a tool like nmap using the -D option.
> Wouldn't be the first time some one shot their own foot.

I don't have my firewall set up to do auto blocking.

> >Now, the weird part is that this problem seems to magically go away when I
> >remove the router. That is, when I'm plugged in directly to my modem the
> >DNS queries come back undamaged and entering http://www.nserc.ca into my
> >browser works fine.
>
> So look at /etc/resolv.conf now. Different? If not, it's likely a firewall
> fiasco on your router.
>
> >I am having a hard time accepting the fact that the router is at fault.
>
> because?

...because I've been using the router without any problems for such a long
time. And because I haven't changed any settings on the router.

> >My ISP claims that the DNS server is fine.
>
> Probably so - and when you bypass the router, things are OK.
>
> Old guy

Thanks for your help.

-J

In article <(E-Mail Removed) terloo.ca>,
James Muir wrote:
>On Fri, 13 May 2005, Moe Trin wrote:

>> Well, the question all admins hate to ask is "What did you change?"
>
>That's just the thing -- I haven't changed anything. I experience the
>problem in both linux and windows.

Well, I said nobody liked to ask that question. Unfortunately, all to often
it is something that got changed that couldn't possibly have any effect on
the problem.

>What about the "Warning: ID mismatch" on the other queries? Doesn't that
>indicate that the queries are getting mangled somehow? And what is special
>about www.nser.ca? Why haven't I noticed this behaviour before?

[compton ~]$ host -a www.nser.ca.
rcode = 3 (Non-existent domain), ancount=0
Host not found.
[compton ~]$ host nser.ca
Host not found.
[compton ~]$ whois -h whois.cira.ca nser.ca
Status: AVAIL
Domain: nser.ca
[compton ~]$

I dunno - you tell me. CIRA says the domain doesn't exist.

>Yes, the router is running a DHCP server and the nameserver address listed
>in /etc/resolv.conf is the address of the router. I have to confess that I
>am a bit naive as to why this would be a problem. Isn't this the way it's
>supposed to be? (ie. the router talks to my ISP's DHCP server and gets
>updated IP addresses for DNS servers, etc, while the settings on my linux
>box don't have to change.)

OK, this means that your router should be running at least a caching and
forwarding name server. Your computer asks the router for name service. If
the router knows the answer, it gives it from cache. Otherwise, it asks
some other name server, and remembers the result (as well as passing them
on to you). What I suspect is that the router is either not running that
name server, OR it's looking at the wrong name server upstream. The quick
and dirty is to stick the ISPs name server addresses into /etc/resolv.conf
and tell your DHCP client not to overwrite that file.

Regarding 'updated IP addresses for DNS servers' it's quite rare for the
address of the name server to change. (Do you really think that the staff
of the ISP have nothing better to do than to swap name server IPs for the
heck of it?). Our name server addresses at work have been the same since
mid-1986. The addresses of the name servers at the ISPs I have access to
have not changed in the year that I've been with my primary, and in the
four years I've been with the secondary. Simple reason - it's to much work
to change addresses.

>I don't have my firewall set up to do auto blocking.

Hate to tell you how often that one has been a problem.

>>> I am having a hard time accepting the fact that the router is at fault.
>>
>> because?
>
>..because I've been using the router without any problems for such a long
>time. And because I haven't changed any settings on the router.

Well, something sure has changed, and it smells like the router. I don't
know how to query the router to find out what it's using for a name server,
but that would be something to look at.

Old guy

On Mon, 16 May 2005, Moe Trin wrote:

> In article <(E-Mail Removed) terloo.ca>,
> James Muir wrote:
>> On Fri, 13 May 2005, Moe Trin wrote:
>
>
>> What about the "Warning: ID mismatch" on the other queries? Doesn't that
>> indicate that the queries are getting mangled somehow? And what is special
>> about www.nser.ca? Why haven't I noticed this behaviour before?
>
> [compton ~]$ host -a www.nser.ca.
> rcode = 3 (Non-existent domain), ancount=0
> Host not found.
> [compton ~]$ host nser.ca
> Host not found.
> [compton ~]$ whois -h whois.cira.ca nser.ca
> Status: AVAIL
> Domain: nser.ca
> [compton ~]$
>
> I dunno - you tell me. CIRA says the domain doesn't exist.

Sorry -- when I replied to your post I made a typo in the url. The web
page is www.nserc.ca.

Here is a script which demonstrates the behaviour I am experiencing:

--------------
#!/bin/bash
#
# open DNS
# 199.166.27.253
# 205.166.226.38 (ns1.granitecanyon.com)
# 199.166.31.3 (NS1.QUASAR.NET)
#
# roger's DNS servers
# 24.153.22.67
# 24.153.22.195

URL=www.nserc.ca

for ns in 199.166.27.253 205.166.226.38 199.166.31.3 \
24.153.22.67 24.153.22.195
do
dig '@'$ns $URL +noall +answer +stats
done
--------------

here is the output:

--------------
; <<>> 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

; <<>> 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
;; SERVER: 205.166.226.38#53(205.166.226.38)
;; WHEN: Wed May 18 10:08:38 2005
;; MSG SIZE rcvd: 125

; <<>> 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
;; SERVER: 199.166.31.3#53(199.166.31.3)
;; WHEN: Wed May 18 10:08:38 2005
;; MSG SIZE rcvd: 125

; <<>> DiG 9.2.2 <<>> @24.153.22.67 www.nserc.ca +noall +answer +stats
;; global options: printcmd
;; connection timed out; no servers could be reached

; <<>> DiG 9.2.2 <<>> @24.153.22.195 www.nserc.ca +noall +answer +stats
;; global options: printcmd
;; connection timed out; no servers could be reached
--------------

Only 2 of the 5 DNS servers where able to resolve the hostname. It seems
that the problem I'm experiencing isn't particular to my ISP's servers
(Roger's) since the first DNS also is giving me trouble.

When I change the url in the script to www.yahoo.ca I get this:

-------------
; <<>> DiG 9.2.2 <<>> @199.166.27.253 www.yahoo.ca +noall +answer +stats
;; global options: printcmd
www.yahoo.ca. 20383 IN CNAME rc.yahoo.com.
rc.yahoo.com. 583 IN CNAME rc.yahoo.akadns.net.
rc.yahoo.akadns.net. 283 IN A 66.94.234.13
;; Query time: 67 msec
;; SERVER: 199.166.27.253#53(199.166.27.253)
;; WHEN: Wed May 18 10:11:18 2005
;; MSG SIZE rcvd: 105


; <<>> DiG 9.2.2 <<>> @205.166.226.38 www.yahoo.ca +noall +answer +stats
;; global options: printcmd
www.yahoo.ca. 20383 IN CNAME rc.yahoo.com.
rc.yahoo.com. 951 IN CNAME rc.yahoo.akadns.net.
rc.yahoo.akadns.net. 67 IN A 216.109.112.135
;; Query time: 98 msec
;; SERVER: 205.166.226.38#53(205.166.226.38)
;; WHEN: Wed May 18 10:11:18 2005
;; MSG SIZE rcvd: 464


; <<>> DiG 9.2.2 <<>> @199.166.31.3 www.yahoo.ca +noall +answer +stats
;; global options: printcmd
www.yahoo.ca. 16629 IN CNAME rc.yahoo.com.
rc.yahoo.com. 1440 IN CNAME rc.yahoo.akadns.net.
rc.yahoo.akadns.net. 23 IN A 216.109.112.135
;; Query time: 78 msec
;; SERVER: 199.166.31.3#53(199.166.31.3)
;; WHEN: Wed May 18 10:11:18 2005
;; MSG SIZE rcvd: 464


; <<>> DiG 9.2.2 <<>> @24.153.22.67 www.yahoo.ca +noall +answer +stats
;; global options: printcmd
www.yahoo.ca. 17228 IN CNAME rc.yahoo.com.
rc.yahoo.com. 1590 IN CNAME rc.yahoo.akadns.net.
rc.yahoo.akadns.net. 250 IN A 216.109.112.135
;; Query time: 35 msec
;; SERVER: 24.153.22.67#53(24.153.22.67)
;; WHEN: Wed May 18 10:11:18 2005
;; MSG SIZE rcvd: 464


; <<>> DiG 9.2.2 <<>> @24.153.22.195 www.yahoo.ca +noall +answer +stats
;; global options: printcmd
www.yahoo.ca. 16630 IN CNAME rc.yahoo.com.
rc.yahoo.com. 1722 IN CNAME rc.yahoo.akadns.net.
rc.yahoo.akadns.net. 136 IN A 216.109.112.135
;; Query time: 11 msec
;; SERVER: 24.153.22.195#53(24.153.22.195)
;; WHEN: Wed May 18 10:11:18 2005
;; MSG SIZE rcvd: 464
--------------
Now the success rate is 5/5.

>> Yes, the router is running a DHCP server and the nameserver address listed
>> in /etc/resolv.conf is the address of the router. I have to confess that I
>> am a bit naive as to why this would be a problem. Isn't this the way it's
>> supposed to be? (ie. the router talks to my ISP's DHCP server and gets
>> updated IP addresses for DNS servers, etc, while the settings on my linux
>> box don't have to change.)
>
> OK, this means that your router should be running at least a caching and
> forwarding name server. Your computer asks the router for name service. If
> the router knows the answer, it gives it from cache. Otherwise, it asks
> some other name server, and remembers the result (as well as passing them
> on to you). What I suspect is that the router is either not running that
> name server, OR it's looking at the wrong name server upstream. The quick
> and dirty is to stick the ISPs name server addresses into /etc/resolv.conf
> and tell your DHCP client not to overwrite that file.

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.

> Regarding 'updated IP addresses for DNS servers' it's quite rare for the
> address of the name server to change. (Do you really think that the staff
> of the ISP have nothing better to do than to swap name server IPs for the
> heck of it?). Our name server addresses at work have been the same since
> mid-1986. The addresses of the name servers at the ISPs I have access to
> have not changed in the year that I've been with my primary, and in the
> four years I've been with the secondary. Simple reason - it's to much work
> to change addresses.

It got -- DNS server ip addresses rarely change.

> Well, something sure has changed, and it smells like the router. I don't
> know how to query the router to find out what it's using for a name server,
> but that would be something to look at.

The router has a web interface and it displays the DNS server it is using.
I can change the DNS server to whatever I want. When I change it to
205.166.226.38 the problem goes away but the response time from this
server isn't so great. I would like to use my ISP's server.

I can accept that my router is at fault. However, in that case, I don't
see why this behaviour should be restricted to the url www.nserc.ca.
Shouldn't I be able to find other (valid) urls which cannot be resolved?

-James

James Muir wrote:
> On Mon, 16 May 2005, Moe Trin wrote:
>
> > In article
<(E-Mail Removed) terloo.ca>,
> > James Muir wrote:
> >> On Fri, 13 May 2005, Moe Trin wrote:
> >
> >
> >> What about the "Warning: ID mismatch" on the other queries?
Doesn't that
> >> indicate that the queries are getting mangled somehow? And what
is special
> >> about www.nser.ca? Why haven't I noticed this behaviour before?
> >
> > [compton ~]$ host -a www.nser.ca.
> > rcode = 3 (Non-existent domain), ancount=0
> > Host not found.
> > [compton ~]$ host nser.ca
> > Host not found.
> > [compton ~]$ whois -h whois.cira.ca nser.ca
> > Status: AVAIL
> > Domain: nser.ca
> > [compton ~]$
> >
> > I dunno - you tell me. CIRA says the domain doesn't exist.
>
> Sorry -- when I replied to your post I made a typo in the url. The
web
> page is www.nserc.ca.

Typo is not the source of the "Warning: ID mismatch". The IDs are used
to match DNS queries with responses since this is UDP. If you look
closer at your original post you will see that (some) packets are being
returned "out of sequence". Artifact of running multiple queries from
script?

> Here is a script which demonstrates the behaviour I am experiencing:
>
> --------------
> #!/bin/bash
> #
> # open DNS
> # 199.166.27.253
> # 205.166.226.38 (ns1.granitecanyon.com)
> # 199.166.31.3 (NS1.QUASAR.NET)
> #
> # roger's DNS servers
> # 24.153.22.67
> # 24.153.22.195
>
> URL=www.nserc.ca
>
> for ns in 199.166.27.253 205.166.226.38 199.166.31.3 \
> 24.153.22.67 24.153.22.195
> do
> dig '@'$ns $URL +noall +answer +stats
> done
> --------------
>
> here is the output:
>
> --------------
> ; <<>> 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
>
> ; <<>> 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
> ;; SERVER: 205.166.226.38#53(205.166.226.38)
> ;; WHEN: Wed May 18 10:08:38 2005
> ;; MSG SIZE rcvd: 125
>
> ; <<>> 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
> ;; SERVER: 199.166.31.3#53(199.166.31.3)
> ;; WHEN: Wed May 18 10:08:38 2005
> ;; MSG SIZE rcvd: 125
>
> ; <<>> DiG 9.2.2 <<>> @24.153.22.67 www.nserc.ca +noall +answer
+stats
> ;; global options: printcmd
> ;; connection timed out; no servers could be reached
>
> ; <<>> DiG 9.2.2 <<>> @24.153.22.195 www.nserc.ca +noall +answer
+stats
> ;; global options: printcmd
> ;; connection timed out; no servers could be reached
> --------------
>
> Only 2 of the 5 DNS servers where able to resolve the hostname. It
seems
> that the problem I'm experiencing isn't particular to my ISP's
servers
> (Roger's) since the first DNS also is giving me trouble.

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.

> When I change the url in the script to www.yahoo.ca I get this:
>
> -------------
> ; <<>> DiG 9.2.2 <<>> @199.166.27.253 www.yahoo.ca +noall +answer
+stats
> ;; global options: printcmd
> www.yahoo.ca. 20383 IN CNAME rc.yahoo.com.
> rc.yahoo.com. 583 IN CNAME rc.yahoo.akadns.net.
> rc.yahoo.akadns.net. 283 IN A 66.94.234.13
> ;; Query time: 67 msec
> ;; SERVER: 199.166.27.253#53(199.166.27.253)
> ;; WHEN: Wed May 18 10:11:18 2005
> ;; MSG SIZE rcvd: 105
>
>
> ; <<>> DiG 9.2.2 <<>> @205.166.226.38 www.yahoo.ca +noall +answer
+stats
> ;; global options: printcmd
> www.yahoo.ca. 20383 IN CNAME rc.yahoo.com.
> rc.yahoo.com. 951 IN CNAME rc.yahoo.akadns.net.
> rc.yahoo.akadns.net. 67 IN A 216.109.112.135
> ;; Query time: 98 msec
> ;; SERVER: 205.166.226.38#53(205.166.226.38)
> ;; WHEN: Wed May 18 10:11:18 2005
> ;; MSG SIZE rcvd: 464
>
>
> ; <<>> DiG 9.2.2 <<>> @199.166.31.3 www.yahoo.ca +noall +answer
+stats
> ;; global options: printcmd
> www.yahoo.ca. 16629 IN CNAME rc.yahoo.com.
> rc.yahoo.com. 1440 IN CNAME rc.yahoo.akadns.net.
> rc.yahoo.akadns.net. 23 IN A 216.109.112.135
> ;; Query time: 78 msec
> ;; SERVER: 199.166.31.3#53(199.166.31.3)
> ;; WHEN: Wed May 18 10:11:18 2005
> ;; MSG SIZE rcvd: 464
>
>
> ; <<>> DiG 9.2.2 <<>> @24.153.22.67 www.yahoo.ca +noall +answer
+stats
> ;; global options: printcmd
> www.yahoo.ca. 17228 IN CNAME rc.yahoo.com.
> rc.yahoo.com. 1590 IN CNAME rc.yahoo.akadns.net.
> rc.yahoo.akadns.net. 250 IN A 216.109.112.135
> ;; Query time: 35 msec
> ;; SERVER: 24.153.22.67#53(24.153.22.67)
> ;; WHEN: Wed May 18 10:11:18 2005
> ;; MSG SIZE rcvd: 464
>
>
> ; <<>> DiG 9.2.2 <<>> @24.153.22.195 www.yahoo.ca +noall +answer
+stats
> ;; global options: printcmd
> www.yahoo.ca. 16630 IN CNAME rc.yahoo.com.
> rc.yahoo.com. 1722 IN CNAME rc.yahoo.akadns.net.
> rc.yahoo.akadns.net. 136 IN A 216.109.112.135
> ;; Query time: 11 msec
> ;; SERVER: 24.153.22.195#53(24.153.22.195)
> ;; WHEN: Wed May 18 10:11:18 2005
> ;; MSG SIZE rcvd: 464
> --------------
> Now the success rate is 5/5.
>
> >> Yes, the router is running a DHCP server and the nameserver
address listed
> >> in /etc/resolv.conf is the address of the router. I have to
confess that I
> >> am a bit naive as to why this would be a problem. Isn't this the
way it's
> >> supposed to be? (ie. the router talks to my ISP's DHCP server and
gets
> >> updated IP addresses for DNS servers, etc, while the settings on
my linux
> >> box don't have to change.)
> >
> > OK, this means that your router should be running at least a
caching and
> > forwarding name server. Your computer asks the router for name
service. If
> > the router knows the answer, it gives it from cache. Otherwise, it
asks
> > some other name server, and remembers the result (as well as
passing them
> > on to you). What I suspect is that the router is either not
running that
> > name server, OR it's looking at the wrong name server upstream.
The quick
> > and dirty is to stick the ISPs name server addresses into
/etc/resolv.conf
> > and tell your DHCP client not to overwrite that file.
>
> 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.

> > Regarding 'updated IP addresses for DNS servers' it's quite rare
for the
> > address of the name server to change. (Do you really think that the
staff
> > of the ISP have nothing better to do than to swap name server IPs
for the
> > heck of it?). Our name server addresses at work have been the same
since
> > mid-1986. The addresses of the name servers at the ISPs I have
access to
> > have not changed in the year that I've been with my primary, and in
the
> > four years I've been with the secondary. Simple reason - it's to
much work
> > to change addresses.
>
> It got -- DNS server ip addresses rarely change.
>
> > Well, something sure has changed, and it smells like the router. I
don't
> > know how to query the router to find out what it's using for a name
server,
> > but that would be something to look at.

Your router (d-link) is cacheing nothing (if any) specific DNS info.
At best, it is cacheing arp/routing info, just like your hosts.

> The router has a web interface and it displays the DNS server it is
using.
> I can change the DNS server to whatever I want. When I change it to
> 205.166.226.38 the problem goes away but the response time from this
> server isn't so great. I would like to use my ISP's server.

My response time to this server (205.166.226.38) was fast enough.
$ ping -c4 205.166.226.38
PING 205.166.226.38 (205.166.226.38) from 206.255.200.28 : 56(84) bytes
of data.
64 bytes from 205.166.226.38: icmp_seq=1 ttl=50 time=57.2 ms
64 bytes from 205.166.226.38: icmp_seq=2 ttl=50 time=51.5 ms
64 bytes from 205.166.226.38: icmp_seq=3 ttl=50 time=54.1 ms
64 bytes from 205.166.226.38: icmp_seq=4 ttl=50 time=53.4 ms

--- 205.166.226.38 ping statistics ---
4 packets transmitted, 4 received, 0% loss, time 3032ms
rtt min/avg/max/mdev = 51.542/54.128/57.290/2.087 ms

Could not "eyeball" the difference in time when using dig and did not
bother to look at the times in my packet capture. Suspect this is
related to your other problems. See below for "investigative summary".

> I can accept that my router is at fault. However, in that case, I
don't
> see why this behaviour should be restricted to the url www.nserc.ca.
> Shouldn't I be able to find other (valid) urls which cannot be
resolved?

I too first thought it might be your router when I first read the
thread. Now I do not think it is any faulty setup or hardware problem
on your end (most likely).

Here's my console output:
$ dig www.nserc.ca +short
198.96.3.190

$ dig @205.166.226.38 www.nserc.ca +short
198.96.3.190

$ dig @NS1.QUASAR.NET www.nserc.ca +short
198.96.3.190

$ dig @24.153.22.67 www.nserc.ca +short
; <<>> DiG 9.2.1 <<>> @24.153.22.67 www.nserc.ca +short
;; global options: printcmd
;; connection timed out; no servers could be reached

$ dig @24.153.22.195 www.nserc.ca +short
; <<>> DiG 9.2.1 <<>> @24.153.22.195 www.nserc.ca +short
;; global options: printcmd
;; connection timed out; no servers could be reached

$ dig @24.153.22.195 www.yahoo.ca +short
; <<>> DiG 9.2.1 <<>> @24.153.22.195 www.yahoo.ca
;; global options: printcmd
;; connection timed out; no servers could be reached

$ dig @24.153.22.67 www.nserc.ca +short
; <<>> DiG 9.2.1 <<>> @24.153.22.67 www.nserc.ca +short
;; global options: printcmd
;; connection timed out; no servers could be reached

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 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).

This is not _that_ surprising after the recent DNS poisoning alerts
that have gone out in the past month or two.

Perhaps your ISP reconfigured their internal firewalls/ACLs and routing
policies and have mucked things up for you. Getting some
ping/traceroute times to your ISP's name servers and to other name
servers would help determine what's afoot.

Most likely, you'll have to do some sniffing off the wire as you run
some queries (by hand) and take a close look at what's passing. My
captures were without errors (only that first "prohibited" response)
and seemed rather routine (except for the failures/timeouts). Can't
really read too much into that except that packets from outside are
treated differently from inside query packets.

Here's how the DNS messages are layed out:
http://www.networksorcery.com/enp/protocol/dns.htm

I do wish I had kept that first query, though. Besides the prohibited
response, the name resolution for the IP was _really_ long (like six or
seven components).

So I looked it up:
http://www.openrbl.org/ip/24/153/22/67.htm
Lookup 24.153.22.67 (dns.wlfdle.rnc.net.cable.rogers.com)

After being "prohibited" I got no farther than (IIRC):
gw02.ym.phub.net.cable.rogers.com (66.185.81.189)

If you would post a list of name server IPs and label them as your
ISP's or others' (I _think_ I got it right from your posts, but ...), I
could do some more timings/captures and give you the results to compare
to your own. My connection is pretty fast.

If there are some ISP net problems, you'll most likely need some
"evidence" in the form of packet traces to show them to convince them
anyway. After all, they've already told you everything is OK on their
end

You might also want to check here for any users' reports of problems:
http://www.dslreports.com/

good luck,
prg
email above disabled

In article <(E-Mail Removed). 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.

>> 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.

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.

>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 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?

>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'.

Old guy

Moe Trin wrote:
> In article <(E-Mail Removed). 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

In article <(E-Mail Removed) .com>, prg wrote:
>
>Moe Trin wrote:

>> 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

I think this was a 'anti-denial-of-service' thing started when bandwidth
was more precious.

>>> 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?

>Nope, no flags, just quick-n-dirty putzing while killing an hour.

OK - just checking

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

It was just one more thing that "could" go wrong. I suspect those warnings
are due to the slow response of the authoritative name server chain.

>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):

At least on the "default" compile of 'dig' the timeout is set to 4
seconds. That might be a problem. At least on this system, 'resolv.h'
sets the RES_TIMEOUT to 5 seconds, and the system will retry up to 3
times if there is a timeout.

>Standard query A www.farmimplement.com: (small town in central Arkansas)

yabbut that's 65.216.49.59 which is uu.net

>; <<>> DiG 9.2.1 <<>> @205.166.226.38 www.cityofsearcy.org

66.136.239.195 which is SBC (swbell)

>; <<>> DiG 9.2.1 <<>> @205.166.226.38 weiser.govoffice.com [in SW Idaho]

63.228.251.51 which is qworst

>; <<>> DiG 9.2.1 <<>> @205.166.226.38 www.buhlidaho.us [in S Central Idaho]

216.55.145.2 which is Abacus America (abac.com) which is a /18 with at
least a decent sized feed from Level3

"Boondocksville" doesn't specifically mean that it's at the end of the
earth as regards networking. Actually, only the swbell address is more
than 9 hops from my border router. (SWBell looks to have their routing
much more fragmented, as I make 11 hops _within_ their domain [SJC twice,
SFO, SLC, DEN, MKC twice, and 3 in LIT] alone.)

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

I dunno. Rogers is a Canadian ISP, and their name servers should have
the IPs of the TLD servers authoritative for .ca cached (there are
apparently six servers authoritative for .ca., with 2 day TTLs on their
names and IP addresses). I don't know how many _domains_ there are in
..ca (ARIN has assigned 4911 IPv4 networks totalling 64,933,888 individual
IP addresses though there are only 763 autonomous system numbers). This
means the worst case query scenario should be a query to the .ca
name servers, which should return name and IP of the SLD server (here,
nserc.ca), which should then result in a third query which should provide
the desired answer. When I tried the query of the nserc.ca name server at
198.96.3.152 (powerweb4.nserc.ca) asking for the IP of www.nserc.ca, dig
reported 305 msec.

>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

I'm still wondering if increasing the timeout might also help.

>Had to leave _something_ for OP to investigate

True.

Old guy

On Fri, 20 May 2005, Moe Trin wrote:

> In article <(E-Mail Removed) .com>, prg wrote:
> >
> >Moe Trin wrote:
>
> >> 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

Yes, I'm quite certain that is the case. The two Roger's DNS servers that I
had been using (24.153.22.67, 24.153.22.195) are privileged access. You
shouldn't be able to 'dig' them.

> >Standard query A www.farmimplement.com: (small town in central Arkansas)
>
> yabbut that's 65.216.49.59 which is uu.net
>
> >; <<>> DiG 9.2.1 <<>> @205.166.226.38 www.cityofsearcy.org
>
> 66.136.239.195 which is SBC (swbell)
>
> >; <<>> DiG 9.2.1 <<>> @205.166.226.38 weiser.govoffice.com [in SW Idaho]
>
> 63.228.251.51 which is qworst
>
> >; <<>> DiG 9.2.1 <<>> @205.166.226.38 www.buhlidaho.us [in S Central Idaho]
>
> 216.55.145.2 which is Abacus America (abac.com) which is a /18 with at
> least a decent sized feed from Level3
>
> "Boondocksville" doesn't specifically mean that it's at the end of the
> earth as regards networking. Actually, only the swbell address is more
> than 9 hops from my border router. (SWBell looks to have their routing
> much more fragmented, as I make 11 hops _within_ their domain [SJC twice,
> SFO, SLC, DEN, MKC twice, and 3 in LIT] alone.)

Is there some implication here that Ottawa (the capital of Canada) is in the
boonies? ;-)

> >Can't see why OP could not use this for a name server if it _is_ a
> >Rogers DNS issue instead of his router.
>
> I dunno. Rogers is a Canadian ISP, and their name servers should have
> the IPs of the TLD servers authoritative for .ca cached (there are
> apparently six servers authoritative for .ca., with 2 day TTLs on their
> names and IP addresses). I don't know how many _domains_ there are in
> .ca (ARIN has assigned 4911 IPv4 networks totalling 64,933,888 individual
> IP addresses though there are only 763 autonomous system numbers). This
> means the worst case query scenario should be a query to the .ca
> name servers, which should return name and IP of the SLD server (here,
> nserc.ca), which should then result in a third query which should provide
> the desired answer. When I tried the query of the nserc.ca name server at
> 198.96.3.152 (powerweb4.nserc.ca) asking for the IP of www.nserc.ca, dig
> reported 305 msec.

I just tried and I got 20 msec:

$ dig @198.96.3.152 www.nserc.ca +noall +answer +stats

; <<>> DiG 9.2.2 <<>> @198.96.3.152 www.nserc.ca +noall +answer +stats
;; global options: printcmd
www.nserc.ca. 3600 IN A 198.96.3.190
;; Query time: 20 msec
;; SERVER: 198.96.3.152#53(198.96.3.152)
;; WHEN: Fri May 20 18:06:56 2005
;; MSG SIZE rcvd: 46

I have given up on Roger's DNS servers and am now using the public access
DNS server ns1.granitecanyon.com [205.166.226.38] (courtesy of
http://soa.granitecanyon.com/). There are some other public access DNS
servers listed at http://www.open-rsc.org . This solves the problem but it
doesn't tell me why the problem occurred in the first place.

> >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

I have a WebStar modem and my router's firmware is fully up-to-date.

> I'm still wondering if increasing the timeout might also help.
>
> >Had to leave _something_ for OP to investigate

Well, the OP (me) sent off a few emails to D-link tech support. They echoed
Moe's suggestion that I statically configure each client behind the router
to use Roger's DNS servers. This way the router would no longer be relaying
DNS requests. Even though I tried this before without success, I decided to
give it another go. At first this seemed to help. I was able to resolve
www.nserc.ca a couple of times on both clients using Roger's DNS servers.
But, after 10mins and a few reboots, the problem came back. So it seems
that it is not just a problem with the way the router relays DNS packets.

I think my service agreement with my ISP says that I am not supposed to have
more than one client connected to the cable modem (a Webstar). I wonder if
they have found a way to detect that there is more than one client behind
the router and have implemented some kind of countermeasure. But then why
would I only be experiencing a problem with one url?

In any case, now that I have a fix, I think I will have to stop
investigating and get back to other things.

Thanks for your help and suggestions.

-James