local caching nameserver

Fri Mar 20 03:16:30 UTC 2009

Chris wrote:
> On Thu, 2009-03-19 at 21:18 -0500, Kevin Darcy wrote:
>   
>> Hmmm... I don't understand. You say the box is "not connected", yet 
>> you're running a reporting script that presumably is looking up Internet 
>> names/addresses and trying to resolve them (?). It needs access -- 
>> either directly or indirectly via forwarding -- to the Internet DNS in 
>> order to do that. Thus, for DNS purposes it is "connected".
>>
>> If you're querying the Internet DNS, you *should* be successfully 
>> loading those RFC 1918 (private-range)-oriented zones. Otherwise you 
>> risk polluting the Internet DNS infrastructure with pointless queries, 
>> i.e. querying public DNS for private addresses. It's not really 
>> acceptable to just ignore the zone-loading errors.
>>
>> Your nameserver is not running correctly since it's not finding zone 
>> files for zones which are defined as "master" in named.conf. My guess 
>> would be that you're running chroot'ed and those zone files are not in 
>> the correct location relative to the chroot point.
>>
>>                                                                          
>> - Kevin
>>
>>     
> Yes you're correct Kevin, I neglected to mention that I'm connected via
> a DSL line. I have this in my /etc/named.conf:
>
> // Access lists (ACL's) should be defined here
> include "/var/lib/named/etc/bogon_acl.conf";
> include "/var/lib/named/etc/trusted_networks_acl.conf";
>
> // Define logging channels
> include "/var/lib/named/etc/logging.conf";
>
> options {
>     version "";
>     directory "/var/lib/named";
>     dump-file "/var/tmp/named_dump.db";
>     pid-file "/var/run/named.pid";
>     statistics-file "/var/tmp/named.stats";
>     zone-statistics yes;
> //    datasize 256M;
>     coresize 100M; 
> //    fetch-glue no;
> //    recursion no;
> //    recursive-clients 10000;
>     auth-nxdomain yes;
>     query-source address * port *;
>     listen-on port 53 { any; };
>     cleaning-interval 120;
>     transfers-in 20;
>     transfers-per-ns 2;
>     lame-ttl 0;
>     max-ncache-ttl 10800;
>
> //    forwarders { first_public_nameserver_ip;
> second_public_nameserver_ip; };
>     
> //    allow-update { none; };
> //    allow-transfer { any; };
>
> // Prevent DoS attacks by generating bogus zone transfer 
> // requests.  This will result in slower updates to the 
> // slave servers (e.g. they will await the poll interval 
> // before checking for updates). 
>     notify no; 
> //    notify explicit; 
> //    also-notify { secondary_name_server };
>
> // Generate more efficient zone transfers.  This will place 
> // multiple DNS records in a DNS message, instead of one per 
> // DNS message. 
>     transfer-format many-answers; 
>
> // Set the maximum zone transfer time to something more 
> // reasonable.  In this case, we state that any zone transfer 
> // that takes longer than 60 minutes is unlikely to ever 
> // complete.  WARNING:  If you have very large zone files, 
> // adjust this to fit your requirements. 
>     max-transfer-time-in 60; 
>
> // We have no dynamic interfaces, so BIND shouldn't need to 
> // poll for interface state {UP|DOWN}. 
>     interface-interval 0; 
>
> // Uncoment these to enable IPv6 connections support
> // IPv4 will still work
> //      listen-on { none; };
> //      listen-on-v6 { any; };
>
> //    allow-query { trusted_networks; };
>     allow-recursion { trusted_networks; };
>
> // Deny anything from the bogon networks as
> // detailed in the "bogon" ACL.
>     blackhole { bogon; };
> };
>
> // workaround stupid stuff... (OE: Wed 17 Sep 2003)
> zone "ac" { type delegation-only; };
> zone "cc" { type delegation-only; };
> zone "com" { type delegation-only; };
> zone "cx" { type delegation-only; };
> zone "lv" { type delegation-only; };
> zone "museum" { type delegation-only; };
> zone "net" { type delegation-only; };
> zone "nu" { type delegation-only; };
> zone "ph" { type delegation-only; };
> zone "sh" { type delegation-only; };
> zone "tm" { type delegation-only; };
> zone "ws" { type delegation-only; };
>
> zone "." IN {
> 	type hint;
> 	file "/var/lib/named/named.ca";
> };
>
> zone "localdomain" IN {
> 	type master;
> 	file "/var/lib/named/var/lib/named/master/localdomain.zone";
> 	allow-update { none; };
> };
>
> zone "localhost" IN {
> 	type master;
> 	file "/var/lib/named/var/lib/named/master/localhost.zone";
> 	allow-update { none; };
> };
>
> zone "0.0.127.in-addr.arpa" IN {
> 	type master;
> 	file "/var/lib/named/var/lib/named/reverse/named.local";
> 	allow-update { none; };
> };
>
> #zone "168.192.in-addr.arpa" {
> #	type master;
> #	#file "mandrakesoft.reversed";
> #	file "/var/lib/named/var/lib/named/reverse/named.local";
> #	allow-update { none; };
> #};
>
> zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
> IN {
>         type master;
> 	file "/var/lib/named/var/lib/named/reverse/named.ip6.local";
> 	allow-update { none; };
> };
>
> zone "255.in-addr.arpa" IN {
> 	type master;
> 	file "/var/lib/named/var/lib/named/reverse/named.broadcast";
> 	allow-update { none; };
> };
>
> zone "0.in-addr.arpa" IN {
> 	type master;
> 	file "/var/lib/named/var/lib/named/reverse/named.zero";
> 	allow-update { none; };
> };
>
> zone "10.IN-ADDR.ARPA" {
>         type master;
>         file "/var/lib/named/var/lib/named/master/empty";
> };
>
> zone "16.172.IN-ADDR.ARPA" {
>         type master;
>         file "/var/lib/named/var/lib/named/master/empty";
> };
>
> zone "31.172.IN-ADDR.ARPA" {
>         type master;
>         file "/var/lib/named/var/lib/named/master/empty";
> };
>
> zone "168.192.IN-ADDR.ARPA" {
>         type master;
>         file "/var/lib/named/var/lib/named/master/empty";
> };
>
> My hosts file in /var/lib/named/etc and /var/lib/named/var/lib/named/etc
> is:
>
> 127.0.0.1	localhost.localdomain cpollock.localdomain cpollock localhost
>
> or is this more correct or does it make a difference?
>
> 127.0.0.1	localhost.localdomain localhost
>
>
> I was told that named is running chroot'd
> in /var/lib/named/var/lib/named, I have the same named.conf file in that
> directory. I'm not familiar at all with running something chroot'd so
> I'm only going by what I've been told. Any help you could give or
> anything else I can provide would be appreciated.
>   
Well, I'm not sure what all this "I've been told" stuff is about, 
because you originally said you set this up yourself, but I highly doubt 
that you're chroot'ed to /var/lib/named/var/lib/named, since your hosts 
files aren't relative to that (not that you should really need hosts 
file anyway, and certainly not *two* of them in different parts of the 
chroot hierarchy), and neither are your log files relative to that.

My guess would be that you're _actually_ chroot'ed to /var/lib/named. 
That would make a whole lot more sense.

In any case, wherever you're chroot'ed, all pathname references in 
named.conf  are interpreted relative to that. Adjust them accordingly.

My recommendation would be to eliminate the redundant components in your 
pathnames and just use subdomains of the chroot point, e.g. 
/var/lib/named/master and /var/lib/named/reverse. Repeating the pathname 
component sequence "/var/lib/named" multiple times in the (absolute) 
pathnames doesn't seem to me to add any particular value, it just makes 
them long and unwieldy and goofy-looking and more prone to being mistyped.

                                 - Kevin