Bind 9 slaves - new zones are never picked up

Mark Andrews 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
	"use-alt-transfer-source no;"

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
> N)
> 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 mailing list