[H-GEN] DNS Pains

[Greg Black]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

Nikolai Lusan wrote:

| On Tue, 30 Jul 2002, Greg Black wrote:
| 
| > Nikolai Lusan wrote:
| >
| > No idea about this one.  The right answer is provided by the
| > authoritative name servers and the web server there is giving
| > the expected data.
| 
| I have some suspicions about this one now ... after my nameserver
| stopped getting info on this domain I noticed some inconsistancies in
| the whois information:

Data from whois is absolutely irrelevant to the operation of the
DNS -- it should be correct for other reasons, but has no impact
at all on name server operations.

| <SNIP>
|    Domain servers in listed order:
| 
|    NS1.EXA.COM.AU                                    202.3.42.65
|    NS2.EXA.COM.AU                                    202.3.42.65

Those IP addresses are bogus.  When you ask an authoritative
name server, you get:

    answer: ns1.exa.com.au 86400 A 210.11.140.120
    answer: ns2.exa.com.au 86400 A 195.218.81.62

| These nameserver details don't gel with the details from a successful dig:
| 
| kiev:/etc/bind# dig www.noosaweddingring.com
| 
| <SNIP>
| ;; ADDITIONAL SECTION:
| ns1.exa.com.au.         77700   IN      A       210.11.140.120
| ns2.exa.com.au.         77700   IN      A       195.218.81.62

This is correct, but it's not clear (since you don't provide the
necessary data) where this came from.  The problem with dig is
that it's excessively verbose and it's difficult to drive it
correctly when debugging this kind of problem.  Even if you
don't want to use Bernstein's djbdns package, you should at
least install his lookup tools (dnsq and dnsqr), as they are
easy to use, provide complete information, waste little screen
real estate in displaying results, and only perform the desired
type of query (non-recursive, in this case).

| kiev is my dialup machine and as a test I set it up with no forwarding
| bind as a test. The results on kiev where the same as ones from a
| machine outside the network. Also midori (the nameserver here) is no
| longer doing a dig or host for www.noosaweddingring.com, it returns:
| 
| midori:~# dig  www.noosaweddingring.com
| 
| ; <<>> DiG 8.3 <<>> www.noosaweddingring.com
| ;; res options: init recurs defnam dnsrch
| ;; res_nsend to server default -- 202.165.0.67: Connection timed out
| 
| I am assuming this is a timeout with 202.3.42.65 because if I specify
| 210.11.140.120 as the server to dig at (dig @210.11.140.120) I get a
| correct response.

Hard to know what it is, but if it's querying 202.3.42.65 you
have something wrong, presumably bad cached data.

I'd suggest using better tools, or using dig with its options to
control what it does and following the delegated trail all the
way.  If you do, you'll get the right answers.  This means that
something is wrong internally.  If you're still having problems
on Saturday, we can go through the diagnostic process in more
detail at the meeting.

| > You may have some wrong data cached somewhere -- but the info
| > above is not sufficient to diagnose it.
| 
| Is it sufficient now? :)  I am at a loss, considering I can get I get
| healthy resolution of most .com addresses and this is my first known
| failure and it is not a blanket failure ...

DNS problems often seem inexplicable, but I find that careful
use of dnsq and dnsqr usually reveals the explanation quickly
enough.  Sometimes, a bit of playing with ethereal can also be
helpful.

Greg

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/