"rndc reconfig" vs. "rndc reload"

[Peter Andreev]

2012/3/16 Mark Pettit <pettit at 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-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
AP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120316/07a08eb3/attachment.html>