[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNS



On Tue, Jun 20, 2000 at 11:08:38PM +0300, ksemat at eahd.or.ug wrote:
> I have a problem on which I would like your help.
> I have a domain eahd.or.ug for which it is its own primary it has stub
> zones wawa and alpha however alpha uses the same IP as that of eahd.or.ug
> itself.
> Now the problem is that the DNS tends to time out when I do nslookup

The simplest way to debug external DNS problems is to follow them through
step-by-step, starting at the root server, just the same as some other
machine on the Internet would do when looking up your address. So let's do
it:

$ dig  at a.root-servers.net. www.eahd.or.ug. any
...
UG.                     2D IN NS        NS.RIPE.NET.
UG.                     2D IN NS        RIP.PSG.COM.

(OK, so those are the nameservers we ask next)

$ dig  at ns.ripe.net. www.eahd.or.ug. any
$ dig  at rip.psg.com. www.eahd.or.ug. any

Both of these give:
...
eahd.or.ug.             4H IN NS        eahd.or.ug.
eahd.or.ug.             4H IN NS        pop.nsrc.org.

;; ADDITIONAL SECTION:
eahd.or.ug.             4H IN A         216.129.132.208

[note: glue record returned. Is 216.129.132.208 correct?]

$ dig  at eahd.or.ug. www.eahd.or.ug. any
[no answer]
$ dig  at 216.129.132.208 www.eahd.or.ug. any
[no answer]
But this address does ping.

*** Problem: machine 'eahd.or.ug' (216.129.132.208) is listed as nameserver
*** for the zone 'eahd.or.ug', but is not authoritative (primary or
*** secondary)

$ dig  at pop.nsrc.org. www.eahd.or.ug. any

;; ANSWER SECTION:
www.eahd.or.ug.         1D IN CNAME     eahd.or.ug.

;; AUTHORITY SECTION:
eahd.or.ug.             1D IN NS        eahd.or.ug.
eahd.or.ug.             1D IN NS        pop.nsrc.org.

;; ADDITIONAL SECTION:
eahd.or.ug.             1D IN A         216.129.132.208

That's OK.

Now, you are also interested in the reverse zone, so let's try that too:

$ dig  at a.root-servers.net. 208.132.129.216.in-addr.arpa. any
;; AUTHORITY SECTION:
132.129.216.IN-ADDR.ARPA.  6D IN NS  DEATHSTAR.KERSUR.NET.
132.129.216.IN-ADDR.ARPA.  6D IN NS  SAURON.KERSUR.NET.

$ dig  at deathstar.kersur.net. 208.132.129.216.in-addr.arpa. any
$ dig  at deathstar.kersur.net. 208.132.129.216.in-addr.arpa. any

Both give:
;; ANSWER SECTION:
208.132.129.216.in-addr.arpa.  1D IN PTR  eahd.or.ug.

;; AUTHORITY SECTION:
132.129.216.in-addr.arpa.  1D IN NS  dar1.afsat.com.
132.129.216.in-addr.arpa.  1D IN NS  sauron.kersur.net.
132.129.216.in-addr.arpa.  1D IN NS  deathstar.kersur.net.

That's fine. There is an additional nameserver listed in the NS records
within the zone, compared to the two which are delegated from the enclosing
zone, but that's not a problem as long as it's authoritative as well:

$ dig  at dar1.afsat.com. 208.132.129.216.in-addr.arpa. any
[find, gives the same answer]

So, from the outside, your reverse DNS looks to be configured OK, although
it violates RFC2182 because the two nameservers are on the same network.

> It times out on reverse lookups yet I have an entry in the reverse files
> pointing to eahd.or.ug. However I am not the SOA for the reverse zone
> just load them from the master server.

So, you have a problem with _resolving_ DNS names, but I don't understand
exactly what you are saying.

You say you "have an entry in the reverse files pointing to eahd.or.ug".
However, you should not configure _anything_ on your nameserver to be able
to resolve 216.129.132.* addresses. The caching nameserver will
automatically find the correct nameservers which have the necessary
information (following the same process I did manually above).

As far as I can tell, machine 'eahd.or.ug' is not running a nameserver at
all - at least, it is not responding to any DNS queries I send it (or it is
configured to block queries from outside)

$ nslookup - 216.129.132.208
Default Server:  eahd.or.ug
Address:  216.129.132.208

> psg.com.
Server:  eahd.or.ug
Address:  216.129.132.208

*** Request to eahd.or.ug timed-out

Hmm. I suggest you have a broken named.conf file, or the cache hints file
(usually called 'named.root'). Try killing and restarting named, and see if
any errors are reported in /var/log/messages

HTH,

Brian.

-----
This is the afnog mailing list, managed by Majordomo 1.94.4

To send a message to this list, e-mail afnog at afnog.org
To send a requet to majordomo, e-mail majordomo at afnog.org and put
your request in the body of the message (i.e use "help" for help)

This list is mantained by owner-afnog at afnog.org