Bind 9 slaves - new zones are never picked up
Mark_Andrews at isc.org
Sat Feb 25 21:50:52 UTC 2006
> > > Interestingly enough, I was debugging this very issue earlier today on a
> > > BIND 9.3.1 authoritative nameserver.
> > >
> > > I get a "server reload successful" in reply to the reload command and
> > > nothing in reply to a reconfig. Zones listed in the config file are
> > > not retransferred (I deleted 10.in-addr.arpa just to see) and the new
> > > zones added are not transferred either. Server returns SERVFAIL for
> > > requests.
> > If you want to re-transfer a zone use "rndc retransfer".
> > Reload / reconfig will not retransfer a existing zone.
> > > I've not come to a resolution just yet. I hate to go gunning down the
> > > server to force the issue...
> "reconfig" implies it won't retransfer an existing zone.
> "reload" doesn't seem to imply that.
> reload Reload configuration file and zones.
> reload zone [class [view]]
> Reload a single zone.
> refresh zone [class [view]]
> Schedule immediate maintenance for a zone.
> retransfer zone [class [view]]
> Retransfer a single zone without checking serial number.
> freeze zone [class [view]]
> Suspend updates to a dynamic zone.
> thaw zone [class [view]]
> Enable updates to a frozen dynamic zone and reload it.
> reconfig Reload configuration file and new zones only.
> Basically I need a command that tells the nameserver to "get yer rear in
> gear and serve your configured zones. Fetch 'em if you need to, whatever."
> For us, this is not a game; we're not willing to sit there and twiddle
> around with various different commands trying to make different revisions
> of BIND feel good, because the automatics are expected to be able to go
> and provision a new zone and get it working without lots of human
> intervention and manual verification. I also don't expect to have to go
> through a lot of manual twiddling if I decide something's amiss and I
> blow away the secondaries zone directory, there should be some command I
> can issue to have it just go about its business and make everything good
> again. If I have to use "retransfer", that means iterating zone by zone
> through the conf file.
So you stuff up and change things under named and expect it
to detect that when in normal operations there is no need for
it to look at the cached zone file. That is only there to
speed up the next restart. Remember that it actually costs
cycles to look to see if the cache file still exists. Anything
which touches the disk is slow.
> I would have expected, based on the documentation, that the universal
> reload-it-all command would be "reload".
It is. You just expect the reload to be complete when the
reload command returns. All deletes zones will be removed.
All the new master zones will be loaded, any existing master
zones will be checked to see if the modifation time is newer
than the last modifation time and if so the zone will be
reloaded. New slave zones will queued for zone transfer.
New stub zones will be queued for "transfer".
> Anyways, it turns out that in 9.3.1, if you omit the port on transfer-source,
> it apparently uses a wildcard even though you've supplied an address. At
> least, the logs showed it as 0.0.0.0#0 or whatever... sigh.
No you are seeing alt-transfer-source. Set
1446. [func] Implemented undocumented alternate transfer sources
from BIND 8. See use-alt-transfer-source,
alt-transfer-source and alt-transfer-source-v6.
SECURITY: use-alt-transfer-source is ENABLED unless
you are using views. This may cause a security risk
resulting in accidental disclosure of wrong zone
content if the master supplying different source
content based on IP address. If you are not certain
ISC recommends setting use-alt-transfer-source no;
> ... JG
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and] then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CN
> With 24 million small businesses in the US alone, that's way too many apples.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users