Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
"rndc reconfig" vs. "rndc reload"
2,689 views
Skip to first unread message
Mark Pettit
Mar 16, 2012, 4:10:32 AM3/16/12
to bind-...@lists.isc.org
I've read carefully through the BIND ARM and am still not sure of the answer to this, so I figured I'd ask on here.
"rndc reconfig" causes BIND to re-load its config file, but unlike "rndc reload", BIND will not scan the zone files it's mastering to see if there have been any updates. This is very useful in our situation because most of our name servers have tens of thousands of zones.
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.
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.
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.
I was considering doing "rndc reconfig", followed by a "rndc reload <zone>" for each of the new zones.
Would this work?
"rndc reconfig" causes BIND to re-load its config file, but unlike "rndc reload", BIND will not scan the zone files it's mastering to see if there have been any updates. This is very useful in our situation because most of our name servers have tens of thousands of zones.
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.
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.
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.
I was considering doing "rndc reconfig", followed by a "rndc reload <zone>" for each of the new zones.
Would this work?
Anand Buddhdev
Mar 16, 2012, 4:53:49 AM3/16/12
to Mark Pettit, bind-...@lists.isc.org
On 16/03/2012 09:10, Mark Pettit wrote:
Hi Mark,
> However, I'm curious what I should do when an update contains both a
> new config file and new zone files.
If you have *new* zones, "rndc reconfig" will also load them. You don't
need to run "rndc reload" for them when they are first added to the
configuration.
Regards,
Anand Buddhdev
RIPE NCC
Hi Mark,
> However, I'm curious what I should do when an update contains both a
> new config file and new zone files.
need to run "rndc reload" for them when they are first added to the
configuration.
Regards,
Anand Buddhdev
RIPE NCC
Peter Andreev
Mar 16, 2012, 5:24:14 AM3/16/12
to Mark Pettit, bind-...@lists.isc.org
2012/3/16 Mark Pettit <pet...@yahoo-inc.com>
I've read carefully through the BIND ARM and am still not sure of the answer to this, so I figured I'd ask on here.
"rndc reconfig" causes BIND to re-load its config file, but unlike "rndc reload", BIND will not scan the zone files it's mastering to see if there have been any updates. This is very useful in our situation because most of our name servers have tens of thousands of zones.
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.
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.
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.
I was considering doing "rndc reconfig", followed by a "rndc reload <zone>" for each of the new zones.
Would this work?
"rndc reconfig" forces BIND to re-read config file and load *only* new zones. So if you add a new zone and want BIND to load it, you don't need "rndc reload <zone>" at all, "rndc reconfig" is completely sufficient.
"rndc reload <zone>" is needed only if you modify existing zone.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
AP
Jonathan Vomacka
Mar 16, 2012, 5:49:14 AM3/16/12
to bind-...@lists.isc.org
On 3/16/2012 4:10 AM, Mark Pettit wrote:
> I've read carefully through the BIND ARM and am still not sure of the answer to this, so I figured I'd ask on here.
>
> "rndc reconfig" causes BIND to re-load its config file, but unlike "rndc reload", BIND will not scan the zone files it's mastering to see if there have been any updates. This is very useful in our situation because most of our name servers have tens of thousands of zones.
>
> 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.
>
> 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.
>
> 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.
>
> I was considering doing "rndc reconfig", followed by a "rndc reload<zone>" for each of the new zones.
>
> Would this work?
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
an rndc reload is usually for an individual zone file. If you update a
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
zone (and change the serial number) a reload will implement the new
changes.
a reconfig will check the BIND config file (named.conf) where you would
configure the software to add new zones like "include
/var/namedb/com/<yourdomain>/db.yourdomain.com" or something to that effect.
Matus UHLAR - fantomas
Mar 16, 2012, 7:09:48 AM3/16/12
to bind-...@lists.isc.org
>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
>>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.
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.
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.
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?
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.
individual zone file, it takes very long. The question is, if/how can
it be made to run faster.
--
Matus UHLAR - fantomas, uh...@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.
Evan Hunt
Mar 16, 2012, 10:43:30 AM3/16/12
to Mark Pettit, bind-...@lists.isc.org
> I was considering doing "rndc reconfig", followed by a "rndc reload
> <zone>" for each of the new zones.
>
> Would this work?
'reconfig' reloads the configuration without reloading all of the zones,
> <zone>" for each of the new zones.
>
> Would this work?
but if it sees that you've added or removed any zones in the config file,
it will load or unload those. So, when you say "new zones" above, if you
meant actually *new*, then it's not necessary to do a subsequent reload.
But if you meant existing zones that have been updated, then I believe
your approach would work.
BIND 9.9.0 has improved reconfig time somewhat, you might try it if
you have a chance. Used to be, reconfig would pause the system, then
parse the config file and apply the necessary changes, then resume.
In 9.9.0, it parses the config file *first*, and *then* pauses the
system to apply the changes. If you have a really big config file
due to a large number of zones, that can save a noticeable amount
of downtime.
--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.
Mark Pettit
Mar 19, 2012, 4:49:10 PM3/19/12
to Matus UHLAR - fantomas, bind-...@lists.isc.org
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>".
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>".
>>> I was considering doing "rndc reconfig", followed by a "rndc
>>> reload<zone>" for each of the new zones.
>
>>> Would this work?
>
>>> 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, uh...@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.
>
> 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, uh...@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.
Chris Thompson
Mar 22, 2012, 1:05:29 PM3/22/12
to Bind Users Mailing List
On Mar 16 2012, Mark Pettit wrote:
[...]
the zone files whose modification times have changed, on an "rndc reload".
It does still have to stat() them all, though, which could be bad enough.
>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.
This is better, of course, if you can do it.
--
Chris Thompson
Email: ce...@cam.ac.uk
[...]
>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.
It may be worth noting that recent versions of BIND (at least) only re-read
>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.
the zone files whose modification times have changed, on an "rndc reload".
It does still have to stat() them all, though, which could be bad enough.
>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.
--
Chris Thompson
Email: ce...@cam.ac.uk
0 new messages