getting closer to a working dns server

[Kevin Darcy]

sygurd1006 at my-deja.com wrote:

> i'm getting closer despite the fact that my useless BIND 4
> documentation led me in the wrong direction; please help me answer 3
> questions
> thanks in advance.
>
> [1] although my dns1 server (10.1.203.65) answers in what seems to be
> an authoritative way, his ip address is not reported.  why would this
> be?  (the domain query always answers my web server; i thought it
> should answer my dns server; don't understand this part either but
> that's not critical right now [i hope])

I assume you're talking about that "Address: 0.0.0.0" line? I think this
means that you don't have an /etc/resolv.conf file. In that case,
nslookup or any resolver just sends a query to 0.0.0.0, a kind of
"wildcard" address. (Although, I just tested this by moving my
/etc/resolv.conf to another name, and it used 127.0.0.1 instead. I guess
maybe the Solaris 7 resolver library acts differently). It is surprising
to me that anything came up in the "Server:" line at all. Maybe somebody
has added a reverse record for 0.0.0.0 into your internal DNS (???)

If you want your local nameserver's address to show up here, then put
that address in your /etc/resolv.conf. Then to get the correct server
name in the "Server: " field, ensure that the proper reverse record
exists. You could even use loopback (127.0.0.1) in your /etc/resolv.conf
if you want, but in that case you'd have to define a
1.0.0.127.in-addr.arpa zone in order to make the address reverse-resolve
properly.

> [root at dns1 /etc]# nslookup my_domain.net
> Server:  dns1.my_domain.net
> Address:  0.0.0.0
>
> Name:    www.my_domain.net
> Address:  10.1.203.64
> Aliases:  my_domain.net
>
> (we're in china, so both .net and .net.cn are working)
> [root at dns1 /etc]# nslookup my_domain.net.cn
> Server:  dns1.my_domain.net
> Address:  0.0.0.0
>
> Name:    www.my_domain.net.cn
> Address:  10.1.203.64
> Aliases:  my_domain.net.cn
>
> [2] 2nd question: regarding named daemon;
> [root at dns1 /etc]# ls rc.d/rc3.d/
>  ... S45named ...
>
> i ran the shell program with 'status' switch and it reports that named
> is not loading any configuration at all; what the #@^&*##!!?

Interesting. What OS is this? I've never heard of an rc script accepting
a "status" switch before. I like it.

> [root at dns1 /etc]# rc.d/rc3.d/S45named status
>
> named 8.2.2-P5 Mon Feb 28 10:17:53 EST 2000
> root at porky.devel.redhat.com:/usr/src/bs/BUILD/bind-
> 8.2.2_P5/src/bin/named
> number of zones allocated: 64
> debug level: 0
> xfers running: 0
> xfers deferred: 0
> soa queries in progress: 0
> query logging is OFF
> server is DONE priming
> server IS NOT loading its configuration
> [root at dns1 /etc]#

It's just a badly worded status message. Since it's possible to force the
server to reload its configuration, it's just trying to tell you that it
is not *CURRENTLY* loading its configuration. Better wording might
be: "server IS DONE loading its configuration". Read it that way.

> i know i have a configuration right here:
>
> [root at dns1 /etc]# cat /etc/named.boot
> ;
> directory                                       /var/named
> cache      .                                    named.ca
> primary    0.0.127.in-addr.arpa                 named.local
> ; make him a secondary nameserver
> slave my_domain.net            192.168.1.173  my_domain.hosts
> slave my_domain.net            192.168.1.188  my_domain.hosts
> slave  1.10.in-addr.arpa       192.168.1.173  10.1.rev
> ;
> forwarders 192.168.1.173 192.168.1.188

Why do you even have an /etc/named.boot? BIND 8 doesn't use it. It uses
/etc/named.conf instead.

> i wonder if at all this is the problem:
>
> cat /etc/named.conf
>
> options {
>         directory "/var/named";
> };
>
> zone "." {
>         type hint;
>         file "named.ca";
> };
> zone "0.0.127.in-addr.arpa" {
>         type master;
>         file "named.local";
> };

Note that this named.conf is *NOT* in any way equivalent to your old
named.boot, in fact it looks like just some example config. You should
run the "named-bootconf.pl" script (or equivalent) to convert your
named.boot file into a named.conf file that will actually do what you
want. Then delete the named.boot file forever.

> [3] Last question please: how can i get a hold of the actual zone file
> from the primary server (an isp)?  is there a way to view this file
> across the net?

Why do you care? The slave copy has all of the records that the master
file has. The only differences are in formatting, comments and
"convenience" directives like $ORIGIN, $INCLUDE, $GENERATE and $TTL, none
of which are necessary to serve the zone as a slave, and even if you had
those, they'd just get overwritten every time the zone transfers.


- Kevin