bind 9.1.1 - sample needed

[Kevin Darcy]

You told named to load the "localhost" zone from a file called "named.local", but
you show the contents of a file called "localhost", and that's presumably what
you checked with named-checkzone as well. What's in "named.local"?

As for the problem resolving debian.local.tux, I suspect that named is stuck in
"eternal priming" because you haven't defined a root zone, and it can't reach the
Internet nameservers (not surprising, since you're on a 192.168.*.*
address) which are configured as internal defaults when no root zone is
explicitly defined.

If you're on a totally private network, you need to set up your own internal root
zone.


- Kevin

Kevin at nowhere.invalid wrote:

> Le 6 Jul 2001 17:27:05 -0700, Kevin Darcy a ecrit:
> |
> | You need to understand some of the relationships between the various
> | files. BIND administration is not something that lends itself to
> | mindless cut-and-paste'ing.
> |
> Yes. I read the doc, tried my own files, and it doesn't work.
> I tried then to cut-and-paste in order to be sure to follow the right
> way. It doesn't work.
>
> | Now, if you want to post some examples of files that didn't work, along
> | with the log messages that were generated at the time of failure, then
> | maybe we might be able to help you understand where you went wrong.
> | Also, since you're using BIND 9, you might want to look into using the
> | "named-checkzone" utility to check your zone files.
> |
> ok, let's go for the big post:
> my file /usr/local/etc/named.conf:
> options {
>         directory "/var/named";
>         auth-nxdomain yes;
>         listen-on
>         {
>                 127.0.0.1;
>                 192.168.1.222;
>         };
> };
>
> // localhost
> zone "localhost"{
>         type master;
>         file "named.local";
> };
>
> // my domain
> zone "local.tux"{
>         type master;
>         notify no;
>         file "local.tux";
> };
>
> named-checkconf doesn't complain about anything.
>
> my file /var/named/localhost
> $TTL    86400
> $ORIGIN localhost.
> @                       1D IN SOA       @ root (
>                                         50              ; serial
>                                         3H              ; refresh
>                                         15M             ; retry
>                                         1W              ; expiry
>                                         1D )            ; minimum
>
>                         1D IN NS        @
>                         1D IN A         127.0.0.1
> [root at slackware:~]# named-checkzone /var/named/localhost
> dns_master_load: /var/named/localhost:3: ignoring out-of-zone data (localhost)
> dns_zone_load: zone /var/named/localhost/IN: could not find NS and/or
>                                                                 SOA records
> dns_zone_load: zone /var/named/localhost/IN: has 0 SOA records
> dns_zone_load: zone /var/named/localhost/IN: no NS records
>
> Ok, where's the error?
>
> my file /var/named/local.tux
> $TTL 86400
> @       IN SOA ns.local.tux. root.slackware.local.tux. (
>         2001031102      ; Serial number yyyymmddvv
>         10800   ; Refresh  (3, was 8 hours)
>         3600    ; Retry (1, was 2 hours)
>         604800  ; Expire (7 days)
>         86400   ;
> )
> ;
> ; Descriptions of name servers for this domain
>                         IN      NS      ns.local.tux.
> ns                      IN      A       192.168.1.222
> slackware               IN      A       192.168.1.222
> debian                  IN      A       192.168.1.8
> win                     IN      A       192.168.1.6
>
> [root at slackware:~]# named-checkzone /var/named/local.tux
> OK
>
> looks good.
>
> I launch named. nothing in the logs. Well, time to test:
> [root at slackware:~]# nslookup - 127.0.0.1
> Note:  nslookup is deprecated and may be removed from future releases.
> Consider using the `dig' or `host' programs instead.  Run nslookup with
> the `-sil[ent]' option to prevent this message from appearing.
> > debian.local.tux
> ;; connection timed out; no servers could be reached
>
> Ok. What should I do, now? I've adapted my examples from the files:
> http://www.securityportal.com/articles/bind9_20010430.html
> --
> Kevin