[cobalt-users] Cobalt bug nameServers???

["frderik" <frederik.wille@xxxxxxxxx>]

Hi,

I found out something weird this morning. We have a couple of Cobalt Raq4
servers, and each of them is using UUnet's caching DNS servers (to which we
have full access) for resolving. Now recently we noticed that some mails
could not be delivered because "domain of sender does not exist". All of
these domains DID exist though and were perfectly reachable. Now, this
morning I performed a few tests and erhm... I don't quite understand what's
going on.

When I query the DNS servers using nslookup on every one of our Cobalts, I
often get timeouts and for example:

[root /root]# nslookup www.google.com
Server:  cache00.ns.be.uu.net
Address:  194.7.1.4

*** cache00.ns.be.uu.net can't find www.google.com: Non-existent host/domain

So the domain can not be found, so I guess that's what occurs when a mail is
being sent.

Now, when I do it interactively, I DO get an answer:

[root /root]# nslookup
Default Server:  cache00.ns.be.uu.net
Address:  194.7.1.4

> set type=any
> www.google.com
Server:  cache00.ns.be.uu.net
Address:  194.7.1.4

Non-authoritative answer:
www.google.com  internet address = 216.239.39.101

Authoritative answers can be found from:
google.com      nameserver = NS2.google.com
google.com      nameserver = NS1.google.com
google.com      nameserver = NS3.google.com
google.com      nameserver = NS4.google.com
NS2.google.com  internet address = 216.239.34.10
NS1.google.com  internet address = 216.239.32.10
NS3.google.com  internet address = 216.239.36.10
NS4.google.com  internet address = 216.239.38.10


I tried this using several domain names. Most of them could not be resolved
using nslookup from the command line, but when I do it interactively it does
resolve.

Now, when I use dig instead of nslookup, I sometimes get slow response
times:

[root /root]# dig www.pandora.be

; <<>> DiG 8.3 <<>> www.pandora.be
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;;      www.pandora.be, type = A, class = IN

;; ANSWER SECTION:
www.pandora.be.         2h17m8s IN CNAME  napollo.telenet-ops.be.
napollo.telenet-ops.be.  2h3m18s IN A  195.130.132.84

;; AUTHORITY SECTION:
telenet-ops.be.         12h45m1s IN NS  ns.telenet-ops.be.
telenet-ops.be.         12h45m1s IN NS  ns2.telenet-ops.be.

;; ADDITIONAL SECTION:
ns.telenet-ops.be.      6h15m9s IN A    195.130.132.17
ns2.telenet-ops.be.     5h29m5s IN A    213.224.126.242

;; Total query time: 5015 msec
;; FROM: www.enfocus.com to SERVER: default -- 194.7.1.4
;; WHEN: Mon Feb  4 11:59:37 2002
;; MSG SIZE  sent: 32  rcvd: 149

Usually a lookup takes about 20msec, but like in the example above it takes
about 5 seconds to do the lookup. Perhaps in this time interval it times out
and gets a "domain not found" answer? I tried adding options= retry:n
timeout:n to resolv.conf but that didn't seem to solve the problem either...

Well the WEIRD part of this all is that this behavior does ONLY occur on ALL
of our Cobalt servers. The Windows 2000 and Red Hat machines we're running
do NOT have this problem, NONE of them. A nslookup from the command line
always gives out the right answer after a few msec's...

This makes me conclude that it's some sort of Cobalt bug or something?!
However, I couldn't find the answer in one of the mailing lists. Does anyone
know what the problem here is and how to solve it?? I would really
appreciate any help.

Thanks in advance,

Sven Delmeiren,
E-zone Internet Solutions