Zone reload time after NOTIFY

Wed May 24 15:33:01 UTC 2006

 

> -----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?

Casey