Notify / Transfer Delays
Barry Margolin
barmar at alum.mit.edu
Fri May 13 00:47:30 UTC 2005
In article <d5unes$2tvm$1 at sf1.isc.org>, "Unlisted" <unlisted at gmail.com>
wrote:
> Random on the master or the slaves part?
RFC 1996 suggests that it should be on the master:
4.3. If a master server seeks to avoid causing a large number of
simultaneous outbound zone transfers, it may delay for an arbitrary
length of time before sending a NOTIFY message to any given slave.
It is expected that the time will be chosen at random, so that each
slave will begin its transfer at a unique time. The delay shall not
in any case be longer than the SOA REFRESH time.
Note:
This delay should be a parameter that each primary master name
server can specify, perhaps on a per-zone basis. Random delays
of between 30 and 60 seconds would seem adequate if the servers
share a LAN and the zones are of moderate size.
> And did this just change with
> 9.3.x because I dont think we've ever had this problem in the past.
> When reecords have a 30 second ttl and the zone transfer takes half
> that we get ~45 seconds until its live - not what we wanted to hear
> after the upgrade. :(
Note that they say that the delay shouldn't be larger than the refresh
time, but don't say anything about the relationship with the TTL.
I don't think notify has ever been intended to be an instant replication
mechanism, it's just supposed to be an improvement over the previous
system of periodic SOA queries by the slave.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
More information about the bind-users
mailing list