Zone reload time after NOTIFY

[Scott, Casey]

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

I am not concerned specifically with disk operations or the internal 
transfer mechanics of BIND. That's working fine. I just want to 
reduce the amount of time it takes for a newly transferred zone to 
become available via the name resolution provided by the BIND server.
This effort is focused on getting BIND to match the 
responsiveness that the current Windows DNS infrastructure provides.


E.g. Some Windows box (many desktops using Windows DHCP w/ DNS
registered by 
Windows DHCP service) updates its DNS registration on the Windows name 
server that is primary for that zone. That Windows nameserver server
sends a 
NOTIFY and the new version of the zone is transferred in a very short 
time, about 2 seconds. The problem is that BIND can take at least
approx. 
20 minutes to start providing resolution based on an updated version 
of the zone.