Configuring caching-only name server

[Kai Lanz]

I'm trying to set up a caching-only name server under Redhat 7.3, using
the already-installed BIND-9.2.1 distribution.  I had no trouble getting
BIND-8.4.1 running on our Tru64 box, but the proper Linux/BIND-9 setup
eludes me.  The named runs fine, we are getting name service, but as
far as I can tell no cache is being maintained or used for responding to
queries.

(1) If I do "rndc stats", named.stats says:

success 1
referral 0
nxrrset 0
nxdomain 0
recursion 1502
failure 1501

(2) And with logging set to level "debug", the log file shows repeated 
entries:

createfetch: pangea.stanford.edu A
createfetch: pangea.stanford.edu A

Googling suggests that "createfetch" means a nameserver lookup has taken
place, i.e., the query was not answered from cache.

(3) Doing a "rndc dumpdb" gives me a named_dump.db file which contains only
a header, no cached names or IP addresses.

(4) Trying a lookup on a nearby host, I get:

>dig pangea

; <<>> DiG 9.2.1 <<>> pangea
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59923
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;pangea.                                IN      A

;; AUTHORITY SECTION:
.                       9041    IN      SOA     A.ROOT-SERVERS.NET.
NSTLD.VERISIGN-GRS.COM. 2003091500 1800 900 604800 86400

;; Query time: 1 msec
;; SERVER: 171.64.7.77#53(171.64.7.77)
;; WHEN: Mon Sep 15 13:44:39 2003
;; MSG SIZE  rcvd: 99

The server reported above is 171.64.7.77, one of our campus name servers;
it is not the server my caching named is running on. (This is after over
a hundred lookups of the name "pangea" as indicated by those "createfetch"
entries.)

Am I right in concluding from 1-4 that we aren't getting cached name service?

Here is the named.conf I'm currently using:

options {
        directory "/var/named";
        // query-source address * port 53;
};

controls {
        inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};

logging {
        channel laurentia_log{
            file "/var/named/laurentia.log" versions 3;
            severity debug;
        };
        category default{
            laurentia_log;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

//zone "localhost" IN {
//      type master;
//      file "localhost.zone";
//      allow-update { none; };
//};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        allow-update { none; };
};

include "/etc/rndc.key";

I originally had the zone "localhost" defined in named.conf, with a matching
file in /var/named; commenting that out (as shown above) didn't help.

And here's the contents of named.local:

$TTL    86400
@       IN      SOA     laurentia. root.laurentia.  (
                                      1997022700 ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      86400 )    ; Minimum
              IN      NS      laurentia.

1       IN      PTR     laurentia.

I've tried using the word "localhost" instead of "laurentia" in the 
named.local file, but I get the same behavior.

In our resolv.conf, the first namserver listed is the IP address of 
laurentia, the host running the caching named (not 127.0.0.1, and not 
"localhost", in case that matters).

Sorry for the verbose post.  Can anyone suggest what I'm missing in all this?

-- 

 Kai Lanz   lanz at pangea.stanford.edu   School of Earth Sciences   650 723-3400