using $INCLUDE with views

[Mark Andrews]

> Bill Larson wrote:
> > On Oct 10, 2006, at 2:19 PM, Stefan Puiu wrote:
> >
> >> On 10/10/06, Bill Larson <wllarso at swcp.com> wrote:
> >>> I've been following this thread and simply tried to replicate what
> >>> you were running into.  In particular, I was looking for an answer
> >>> to the "no current owner name" message.  I simply created a zone
> >>> file, "db.test", that looks like this:
> >> [...]
> [wrapping corrected]
> >>> Now, going back to the BIND ARM, there is a note along with the
> >>> description of the $INCLUDE statement:
> >>>
> >>>         RFC 1035 specifies that the current origin should be
> >>>         restored after an $INCLUDE, but it is silent on whether
> >>>         the current domain name should also be restored. BIND 9
> >>>         restores both of them. This could be construed as a
> >>>         deviation from RFC 1035, a feature, or both.
> >>>
> >>> So, the issue is what is the origin defined as AFTER the include
> >>> statement.  Apparently how BIND is operating, the origin hasn't been
> >>> defined before the $INCLUDE is performed and so with the $INCLUDE is
> >>> completed the origin is again undefined.  This is the cause of the
> >>> "no current owner name" message.
> 
> Why would it be unefined before the $INCLUDE is performed? Shouldn't it 
> be defiend as soon as the zone begins loading (well, before it's 
> contents begin to load I mean) ? Otherwise this seems like a completely 
> useless "feature" in this regard. I see no reason why the "current 
> domain" - aka "owner" - shouldn't be the first thing defined. Including 
> a shared zone header like the OP wanted to seems perfect reasonable.
> 
> (Is this fixed in newer versions of Bind? - the OP was using 9.2.4 so 
> this may have changed by now.)
> 
> >> This is only to clarify: the ARM says that the $ORIGIN is defined to
> >> be the zone name if not otherwise specified:
> 
> So I'd expect it to be defined from the start of the zone's processing. 
> What I want to know is, if $ORIGIN is set (by default), then why is the 
> "owner" not set from the get go as well?
> 
> >> <quote>
> >> When a zone is first read in there is an implicit $ORIGIN <zone-name>
> >> </quote>
> >>
> >> That's from the same section I quoted in my post earlier today.
> >>
> >> The problem is not the $ORIGIN (the domain appended to any hostnames
> >> which don't end in a dot (.) in the zone file), but the current
> >> domain after the $INCLUDE directive, that is, the owner for the NS
> >> records - that one is undefined.
> 
> I'd almost call this a bug, as I can't think of ny use for having an 
> "undefined" owner could posibly have. If $ORIGIN is set from the start, 
> there's no reason the owner shouldn't be either?

	$ORIGIN can theoretically be undefined as well.  It is just a long
	defined implemetation detail that it starts out as the zone's name.
	
RFC 1035:
				     Domain names which do not end in a
dot are called relative; the actual domain name is the concatenation of
the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
an argument to the master file loading routine.  A relative name is an
error when no origin is available.

> > To not pick and choose the sections to quote, I also included, but
> > you didn't reference:
> >
> >> The BIND ARM states this as:
> >>
> >> The origin and the current domain name revert to the values
> >> they had prior to the $INCLUDE once the file has been read.
> >
> > The current domain name is undefined after a $INCLUDE statement is
> > executed at the beginning of the zone file.
> 
> IMHO, it /should/ be set /before/ the $INCLUDE, as having an undefined 
> owner (current domain name) seem utterly useless, as it prevents the 
> zone from loading.
> 
> -- 
> CL 

RFC 1035:

    $ORIGIN <domain-name> [<comment>]

    $INCLUDE <file-name> [<domain-name>] [<comment>]

    <domain-name><rr> [<comment>]

    <blank><rr> [<comment>]

		...

The last two forms represent RRs.  If an entry for an RR begins with a
blank, then the RR is assumed to be owned by the last stated owner.  If
an RR entry begins with a <domain-name>, then the owner name is reset.

	Now what is the "last stated owner" when the first line is
	" A 1.2.3.4"?  

	Given the origin example the problem would have been easily
	addressed by adding a @ to the first NS record. 

e.g.

$TTL 86400
$INCLUDE db.test.inc
@ IN NS ns1
  IN NS ns2

ns1 IN A 192.168.1.1
ns2 IN A 192.168.1.2

	F.Y.I. The reason why named doesn't take the ownername as
	found in db.test.inc is that that would create subtle bugs
	that would be very difficult to diagnose.  The current
	behaviour allows you to read a master file and know what the
	ownername is after the $INCLUDE without having to read the
	$INCLUDE.  i.e. IT HAS NOT CHANGED.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org