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
ns2 IN A

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

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