Configuring caching-only name server

Mark_Andrews at isc.org Mark_Andrews at isc.org
Tue Sep 16 00:38:46 UTC 2003


> 
> 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.

	I suggest that you look at the firewall configuration on the
	Linux box.
 
> (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-340
> 0
> 
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org


More information about the bind-users mailing list