Non-transfering zone
Jim Reid
jim at rfc1035.com
Sat Mar 25 00:49:25 UTC 2000
>>>>> "GeekGrrl" == GeekGrrl <geekgrrl at geekgrrl.org> writes:
GeekGrrl> Is there a reason why a zone would not automatically be
GeekGrrl> transfered to it's secondary nameserver after a change,
GeekGrrl> serial increment, and hup on the primary, and a hup on
GeekGrrl> the secondary?
There are quite a few reasons:
[1] Misconfigured master or slave (primary or secondary) name
servers: for instance the slave doesn't query the actual
master name server for the zone(s) in question.
[2] No TCP/IP connectivity between the master and slave name
servers for zone transfers.
[3] Broken or missing named-xfer on the slave name server.
[4] Broken serial numbers in the zone's SOA record: ie the slave
server thinks the serial number is higher than the value on
the master server.
[5] Resource problems on either the master or slave servers that
prevent zone transfers from working.
[6] Filesystem problems - access permissions, non existent
pathnames, etc - that prevent (temporary) zone files being created
[7] The master name server loads a different zone file from the
one you've just updated.
[8] SIGHUP doesn't make the name server behave the way you think.
[9] The process that gets SIGHUP'ed is not a name server.
More information about the bind-users
mailing list