$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