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