"rndc reconfig" vs. "rndc reload"

[Mark Pettit]

Yeah, I'm familiar with the improvements to "reconfig".  You all have answered my questions.

To be clear, the issue was that "reload" by itself was taking way too long.  We have already implemented changes for when the *list of zones* has not changed, we do "reload <zone>" for each individually-changed zone file.  But I was wondering what to do if we have a *new zone* added to named.conf.

I've learned from the various responses that the best solution is just "rndc reconfig" with BIND 9.9.  It will cause minimum downtime and will pick up the new zones without having to subsequently do "rndc reload <new zone>".

On Mar 16, 2012, at 4:09 AM, Matus UHLAR - fantomas wrote:

>> On 3/16/2012 4:10 AM, Mark Pettit wrote:
>>> We have an antiquated push process that copies files into the 
>>> zonefile directory and then tells BIND "rndc reload".  For various 
>>> reasons, "rndc reload" takes about 120 seconds to complete.  BIND is 
>>> not answering queries for a very large part of that time.
> 
>>> I recently started experimenting with a different process: instead of 
>>> "rndc reload" after updaing some of the zone files, I loop through 
>>> the list of updated zone files and run "rndc reload<zone>" for each 
>>> one.
> 
> could the push process be changed to reload each individual zone after 
> it's changed?
> 
>>> This is a vast improvement, because BIND doesn't appear to ever stop 
>>> answering queries.
> 
>>> However, I'm curious what I should do when an update contains both a 
>>> new config file and new zone files.
> 
> as others have already mentioned, 'rndc reconfig' will rescan config 
> file and load new zones. You must still reload those updated.
> 
>>> Normally a "rndc reload" would rescan the config and then scan all 
>>> zone files (including the new ones), loading the new ones into 
>>> memory and starting to serve them.  But obviously we want to avoid 
>>> "rndc reload" at all costs.
> 
> iiuc, reload forcifullly reloads all zones from disk, without checking 
> for files' timestamps (just for cases where timestamp didn't change but 
> files did). That would explain the delays. loading zones is very slow, 
> BIND 9.9 should make it faster.
> 
>>> I was considering doing "rndc reconfig", followed by a "rndc 
>>> reload<zone>" for each of the new zones.
> 
>>> Would this work?
> 
> yes, this should work.
> 
> On 16.03.12 05:49, Jonathan Vomacka wrote:
>> an rndc reload is usually for an individual zone file. If you update 
>> a zone (and change the serial number) a reload will implement the new 
>> changes.
> 
> Well, iirc the OP's problem is that when "rndc reload" is NOT for 
> individual zone file, it takes very long. The question is, if/how can 
> it be made to run faster.
> 
> -- 
> Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> I just got lost in thought. It was unfamiliar territory. 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users