Zone reload time after NOTIFY

Wed May 24 15:30:31 UTC 2006

 

> -----Original Message-----
> From: bind-users-bounce at isc.org 
> [mailto:bind-users-bounce at isc.org] On Behalf Of Kevin Darcy
> Sent: Tuesday, May 23, 2006 5:57 PM
> To: comp-protocols-dns-bind at isc.org
> Subject: Re: Zone reload time after NOTIFY
> 
> 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 9909782  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
> 
> 
> 
> 
There was about 18 minutes before the zone updated. Although 
the zones transferred,none of the newer versions were 
implemented by BIND. The zone went from 9909782 at 16:37 to 
version 9909786 at 16:56. None of the other versions were 
ever implemented. The zone went from 9909782 to 9909786.

Casey