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