Zone reload time after NOTIFY

Kevin Darcy kcd at daimlerchrysler.com
Wed May 24 17:50: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 5:33 PM
>>To: Scott, Casey
>>Cc: Barry Margolin; comp-protocols-dns-bind at isc.org
>>Subject: Re: Zone reload time after NOTIFY 
>>
>>
>>    
>>
>>> 
>>>
>>>      
>>>
>>>>-----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. 
>>>      
>>>
>>	No.  The zone took < 1 second to update.  It took 18 minutes
>>	to write it to disk.  Delayed writes are a feature not a
>>	bug.  The updated contents of the zone were on disk (in the
>>	journal).  This is done to minimise the impact of disk I/O
>>	which is very important with large zones or when there are
>>	many dynamic zones.
>>
>>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)
>>
>>	Mark
>>--
>>Mark Andrews, ISC
>>1 Seymour St., Dundas Valley, NSW 2117, Australia
>>PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
>>
>>    
>>
>Ok, forgive my semantic mistake. How can I reduced the amount of time
>that a zone is synced with its journal?
>
Why would you want to? You should be dealing with named's in-core 
version of the zone, not the actual zone file, the contents of which are 
not trustworthy at any given time while named is running. If you need to 
see all of the zone contents at once, do a local zone transfer.

- Kevin





More information about the bind-users mailing list