$INCLUDEing an SOA record

Mark.Andrews at nominum.com Mark.Andrews at nominum.com
Tue Apr 10 22:25:41 UTC 2001


> 
> I am using the include because I am also using views.  If I don't use
> includes, it involves alot of duplication of effort, hosts that are
> internally and externally resolvable have to get entered twice.  I'd like
> to put the SOA in the included file, because otherwise if I add a host
> common to both views (in the included file), I have to increment 2
> serials, one for each view.  That's how I have it working now, 2 SOA's and
> only hosts in the included file.
> 
> BIND 8 would check the $INCLUDE if the file's modification time hasn't
> changed, and loaded the zone in an example I set up with an included SOA.
> This tells me it should work in BIND 9.

	BIND 8 noted that there were included files and just reloads
	on spec.

	BIND 9 was supposed to just note that there were include
	files and reload on spec.

	Using $INCLUDE for keeping internal/external zones in sync
	is reasonable.

	$INCLUDE tends to be abused when every master zone being
	served by a server includes the same SOA even when the
	zones are otherwise independent.  Forward and reverse zones
	are independent.  It also makes the server do a lot more
	work on reloads as it doesn't track the modification times.

	Mark

> 
> On Mon, 9 Apr 2001, Jim Reid wrote:
> 
> > >>>>> "chris" == chris  <chris at monmouth.com> writes:
> >
> >     chris> The serial HAS changed.  The SOA is in the included file.
> >     chris> If it was one bog file, it would have reloaded.  That's
> >     chris> what's so perplexing.
> >
> > Just a guess.....
> >
> > You have a zone file which $INCLUDEs another file containing the SOA
> > record (yuk!). When BIND loads a zone file, it remembers the time it
> > did that and the date the file was last changed. It probably doesn't
> > see the changed SOA record because it's not in the zone file given in
> > the coresponding zone{} statement in named.conf. As far as the name
> > server is concerned the zone hasn't changed because the zone file
> > hasn't been updated since the last time the server loaded it.
> >
> > You probably should stick to having exactly one zone file for each
> > zone. Life is a lot easier for everyone that way. I suspect the above
> > scenario explains one of the reasons why one zone, one file is a good
> > idea. Having all your zone files share the same SOA record is messy
> > and clumsy, but you probably know that now. :-)
> >
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com


More information about the bind-users mailing list