BIND slave expires rather than XFR?

Sean Straw (to email, replace lutefisk with mail) usenet at lutefisk.professional.org
Tue Mar 14 07:16:54 UTC 2000


BIND 8.2.2-P5 on Linux kernel 2.2.7

My slave DNS (which is specified as the primary DNS for several
domains - intended to offload processing from the master, which
performs other tasks), doesn't appear to be sending AXFR requests to
the master.

There's no logging that there have been attempts which have failed
either.

SOA has reasonable TTL and expires:

	refresh:28800s (8 hours)
	retry:7200s (2 hours)
	expire:604800s (7 days)
	minimum-ttl:86400s (24 hours)

(I'd of course change some of these if I were planning on moving hosts
between servers, but for day-to-day operations, these values are
comfortable)

nslint comes up clean (except expected warnings for CNAMEs defined
outside of my net, multiply-assigned IPs for virtual hosts, and lack
of locally defined PTRs for those IPs which I do not have direct
delegation for, all of which I should put into an nslint config file,
but haven't taken the time to do so).

Manual XFERs demonstrably work.  The named datafiles are getting
touched at each log mark interval (I assume this is expected), and if
I nslookup directly to the server, it does provide answers (and the
stats update accordingly).

I reset it a couple of weeks ago and tried a number of things in the
hopes that I'd get it to xfer, because it was reporting the following
in the system log:

Feb 25 14:20:38 wargames named[100]: secondary zone "somedomain.net"
expired

Needless to say, this was disturbing.  Looking back at older logs, I
found that there have been absolutely no transfers except for when the
primary notified the secondary that there has been changes to the
zone(s).  I would have thought that when the zone expired, it'd have
attempted a transfer at that time.

ndc restart  on the slave takes a couple of seconds, after which I see
all the zones having been loaded in the message log, but none of them
appear to have performed checks with the master to see if they were
outdated.

Root hints are refreshed once a month by an automation script, which
restarts the server.  That seems to work fine, but still, no XFERs
from the master..

There's no goofy warnings like "no TTL - using SOA minimum" - named
starts, loads the cached files and that's it.

The master is clearly performing AXFRs from the rDNS master (that is,
my master handles forward DNS, but the rDNS (PTR) records are managed
elsewhere, since they're part of a larger block - though I'd like to
know how to manage that delegation).  The master has been running
8.2.2-P5 for some time, whereas I only just recently upgraded the
slave (from 8.1.2), hoping that it would resolve this issue.

When I restart the master, I see the NOTIFYs to the secondary, and
also the NOTIFY answers.  All is good - the one possible exception is 

Mar 13 14:58:46 mail named[9031]: suppressing duplicate notify
("somedomain.net" IN SOA)

which is probably the result of the master being one of the NS records
in the zone, and notifying itself, and so I don't fret about it..

Pertinent bits from the slave's named.conf:

options {
        directory "/var/named";
        listen-on {
                127.0.0.1;                 /* Listen on localhost */
                this.server.ip.addr;    /* or ns2 IP assignment */
        };
        query-source address this.server.ip.addr port 53;
};

logging {
        category lame-servers { null; };
        category cname { null; };
};

zone "." in {
        type hint;
        file "named.cache";
};

zone "somedomain.net" in {
        type slave;
        file "slaves/somedomain.net";
        masters { master.server.ip.addr; };
        transfer-source this.server.ip.addr;
        allow-transfers { my.netblock/mask; };
};

where 'this.server.ip.addr' and 'master.server.ip.addr' are really the
dotted quads for the appropriate servers. and 'my.netblock/mask' is
the proper netblock and bitmask (/26) for my network.  I'm doing the
abovein this message like so  just so someone doesn't later come and
grunge the config bit and paste it into their own config file in an
attempt to get theirs working <g>


Diagnostic analysis welcomed.



More information about the bind-users mailing list