Zone reload time after NOTIFY

Wed May 24 00:56:34 UTC 2006

Scott, Casey wrote:

> 
>
>  
>
>>-----Original Message-----
>>From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org] 
>>Sent: Tuesday, May 23, 2006 4:30 PM
>>To: Scott, Casey
>>Cc: Barry Margolin; comp-protocols-dns-bind at isc.org
>>Subject: Re: Zone reload time after NOTIFY 
>>
>>
>>    
>>
>>>>>I have a BIND machine configured as a secondary server 
>>>>>          
>>>>>
>>with 1 zone. 
>>    
>>
>>>>>The zone can receive many DDNS update from Windows clients. 
>>>>>          
>>>>>
>>>>The DDNS
>>>>        
>>>>
>>>>>updates occur on the primary server, which is Windows 2003. My 
>>>>>question is that although the primary DNS server sends
>>>>>          
>>>>>
>>>>NOTIFY's to the
>>>>        
>>>>
>>>>>BIND server, the BIND server takes quite a while before it
>>>>>          
>>>>>
>>>>implements any of the changes.
>>>>        
>>>>
>>>>>I can not find any BIND config option that will effect the 
>>>>>responsiveness of BIND to NOTIFY's. I don't want to 
>>>>>          
>>>>>
>>force BIND to 
>>    
>>
>>>>>reload the zone for every NOTIFY, but I would like to have some 
>>>>>control over the amount of time taken to implement the
>>>>>          
>>>>>
>>>>changes in the zone.
>>>>
>>>>What is "quite a while"?  BIND waits a random amount of time, to 
>>>>avoid a thundering herd problem if all the slaves tried 
>>>>        
>>>>
>>to transfer 
>>    
>>
>>>>immediately.
>>>>But this shouldn't be much more than a minute, I think.
>>>>
>>>>--
>>>>Barry Margolin, barmar at alum.mit.edu
>>>>Arlington, MA
>>>>*** PLEASE post questions in newsgroups, not directly to me ***
>>>>*** PLEASE don't copy me on replies, I'll read them in 
>>>>        
>>>>
>>the group ***
>>    
>>
>>>>
>>>>        
>>>>
>>>Its been between 15-30 minutes each time. BIND is installed 
>>>      
>>>
>>from RPM, 
>>    
>>
>>>and running on a RHEL 4 machine.
>>>
>>>Thanks,
>>>Casey
>>>      
>>>
>>	Are you measuring the time it takes named to write the
>>	master file or the time it takes named to transfer the
>>	updated zone contents and to serve the contents.  These
>>	are usually very different times.
>>
>>	Are the notify messages being sent from a address in the
>>	masters clause.  Named will, by default, only act on notify
>>	messages that match a master.  Notifies from non masters
>>	will be acknowledge but otherwise ignored.
>>
>>	Lastly there are many different versions of BIND.  It is
>>	useful to report which version you are running,  "named -v"
>>	will report it.
>>
>>	Mark
>>--
>>Mark Andrews, ISC
>>1 Seymour St., Dundas Valley, NSW 2117, Australia
>>PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
>>
>>    
>>
>
>BIND 9.2.4 running on RHEL-4 U2
>
>The zone is configured with Ips of all the primary nameservers as
>masters.
>
>This is a relevant portion of /var/log/messages:
>
>May 23 16:37:28 RHEL-4-Test named[2572]: zone examplezone.com/IN:
>transferred serial 9909782
>May 23 16:37:28 RHEL-4-Test named[2572]: zone examplezone.com/IN:
>sending notifies (serial 9909782)
>May 23 16:38:03 RHEL-4-Test ntpd[1990]: kernel time sync enabled 0001
>May 23 16:38:04 RHEL-4-Test named[2572]: received notify for zone
>'examplezone.com'
>May 23 16:38:04 RHEL-4-Test named[2572]: journal file
>/etc/slave/examplezone.com.slave.jnl does not exist, creating it
>May 23 16:38:04 RHEL-4-Test named[2572]: zone examplezone.com/IN:
>transferred serial 9909783
>May 23 16:38:04 RHEL-4-Test named[2572]: zone examplezone.com/IN:
>sending notifies (serial 9909783)
>May 23 16:38:58 RHEL-4-Test named[2572]: received notify for zone
>'examplezone.com'
>May 23 16:38:58 RHEL-4-Test named[2572]: zone examplezone.com/IN:
>transferred serial 9909784
>May 23 16:38:58 RHEL-4-Test named[2572]: zone examplezone.com/IN:
>sending notifies (serial 9909784)
>May 23 16:40:01 RHEL-4-Test crond(pam_unix)[2674]: session opened for
>user root by (uid=0)
>May 23 16:40:01 RHEL-4-Test crond(pam_unix)[2674]: session closed for
>user root
>May 23 16:50:01 RHEL-4-Test crond(pam_unix)[2874]: session opened for
>user root by (uid=0)
>May 23 16:50:01 RHEL-4-Test crond(pam_unix)[2874]: session closed for
>user root
>May 23 16:52:13 RHEL-4-Test named[2572]: received notify for zone
>'examplezone.com'
>May 23 16:52:13 RHEL-4-Test named[2572]: zone examplezone.com/IN:
>transferred serial 9909785
>May 23 16:52:13 RHEL-4-Test named[2572]: zone examplezone.com/IN:
>sending notifies (serial 9909785)
>May 23 16:53:28 RHEL-4-Test named[2572]: received notify for zone
>'examplezone.com'
>May 23 16:53:29 RHEL-4-Test named[2572]: zone examplezone.com/IN:
>transferred serial 9909786
>May 23 16:53:29 RHEL-4-Test named[2572]: zone examplezone.com/IN:
>sending notifies (serial 9909786)
>
>At 16:54, the zone was still at version 9909782 and 16:56 the zone
>updated to 9909786. So,
>in this case, it took about 18 minutes to update. 
>
The log indicates that it transferred serial #9909782 at 16:37:28, 
serial #9909783 at 16:38:04, serial #9909784 at 16:38:58, serial 
#9909785 at 16:52:13 and finally serial #9909786 at 16:53:29. Not sure 
where you're getting 18 minutes from. This all looks fairly typical, 
although perhaps a correlation between the master and slave logs would 
be informative. If you have a large number of frequently-changing zones 
and/or a large number of slaves, then there might be some 
NOTIFY-throttling occurring on the master.

- Kevin