using $INCLUDE with views

Clenna Lumina savagebeaste at
Sun Jul 8 16:05:55 UTC 2007

Bill Larson wrote:
> On Oct 10, 2006, at 2:19 PM, Stefan Puiu wrote:
>> On 10/10/06, Bill Larson <wllarso at> 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?

> 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.


More information about the bind-users mailing list