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:
 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.
 No TCP/IP connectivity between the master and slave name
servers for zone transfers.
 Broken or missing named-xfer on the slave name server.
 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.
 Resource problems on either the master or slave servers that
prevent zone transfers from working.
 Filesystem problems - access permissions, non existent
pathnames, etc - that prevent (temporary) zone files being created
 The master name server loads a different zone file from the
one you've just updated.
 SIGHUP doesn't make the name server behave the way you think.
 The process that gets SIGHUP'ed is not a name server.
More information about the bind-users