using $INCLUDE with views

[Bill Larson]

On Oct 10, 2006, at 9:53 AM, Bill Moseley wrote:

> On Tue, Oct 10, 2006 at 11:27:34AM +0300, Stefan Puiu wrote:
>
> [quoting out of order]
>
>> Oct 10 11:21:34 tuxws43 named[9050]: /var/lib/named/foo.common:1: no
>> TTL specified; using SOA MINTTL instead
>> Oct 10 11:21:34 tuxws43 named[9050]: dns_master_load: foo.zone:3: no
>> current owner name
>
> According to the FAQ:
>
>     This error is produced when a line in the master file contains
>     leading white space (tab/space) but the is no current record owner
>     name to inherit the name from. Usually this is the result of
>     putting white space before a comment. Forgeting the "@" for the
>     SOA record or indenting the master file.
>
> So, perhaps the $INCLUDE is forcing white space before the SOA
> record?

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:

	$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

The included file, "db.test.inc", is just the SOA record and looks like:

	@	IN	SOA	ns1 hostmaster (1 6H 1H 1W 1D )

(I hope my formatting comes across.  Each line of these files is  
indented, and there is an additional indent only for the two NS  
records.)

Running this through the "named-checkzone" tool, as the zone file is  
currently written, you will receive messages of:

	dns_master_load: db.test:3: no current owner name
	dns_master_load: db.test:4: no current owner name

This is identifying that the problem is with line 3 and 4, the two  
"NS" records.

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.

Now, simply changing the first NS record to include an "@" at the  
beginning of the line solves the problem.  The inclusion of the "@"  
specifies the name that the record belongs to.

The logic that I am using to reconcile this is that in this example,  
before the $INCLUDE there was no previous RR owner name specified and  
although this it is named in the included file, it doesn't carry over  
after the $INCLUDE has been completed.

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 "no current owner name" message is caused by the "current domain  
name" reverting back to what it was prior to the $INCLUDE.  Prior to  
the $INCLUDE, this name was undefined!

This hopefully shows that although the FAQ is very helpful, it isn't  
intended to be the definitive answer to all possible questions.  The  
example used in the FAQ is prefixed with "usually".    The BIND ARM  
should be considered the definitive answer to BIND configuration  
syntax and used extensively when you have a configuration error.

Then again, when there doesn't appear to be an easy answer, maybe by  
creating a VERY simple zone file and testing it with the "named- 
checkzone" command, the solution can become apparent.  The same can  
be said about testing a configuration file using "named-checkconf".   
The whole trick is to use as simple a file, zone or configuration, as  
possible that demonstrates the same problem and using this as a basis  
for identifying a solution.

Bill Larson