Re: New error about zone files: record with inherited owner ... immediately after $ORIGIN

[Evan Hunt]

> Finally: "named -v" reports "BIND 9.9.4-RedHat-9.9.4-18.el7_1.1
> (Extended Support Version)" and named itself does support our zone
> files. It is only "named-checkconf -z" that is balking.

This fix was included in BIND 9.9.7:

4014. [bug] When including a master file origin_changed was
not being properly set leading to a potentially
spurious 'inherited owner' warning. [RT #37919]

I'm not sure that upgrading will address your specific issue, but it
seems like a pretty good bet.

--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.

[Andrew Gideon]

We've just tried configuring a CentOS7 environment as a DNS server for
the first time, and have hit an error not seen previously. This
occurred using zone files that have been in use for quite a while.
Specifically, this appears to be hitting a particular idiom that we use
a lot.

I cannot imagine that we're alone, so I'm wondering what I'm doing wrong
(esp. since I've not found many other messages discussing this despite
searching).

The errors are coming from:

/usr/sbin/named-checkconf -z /etc/named.conf

and are of the form:

primary/TAG.GENERIC.NAMESERVERS.include:1: record with inherited owner (yogawithjoe.com) immediately after $ORIGIN (yogawithjoe.com)
primary/CLIENTMX.include:1: record with inherited owner (yogawithjoe.com) immediately after $ORIGIN (yogawithjoe.com)

although we're seeing many variations. As I wrote, we use this idiom a lot.

The idiom is to $INCLUDE a file with records that are common to many
names. Most often, these are NS or MX records.

So, for example, the zone for yogawithjoe.com includes:

@ IN SOA ns1.tagonline.com. dns-admin.tagonline.com. (
2015030901
24h
1h
6w
8h
)
$INCLUDE primary/TAG.GENERIC.NAMESERVERS.include
IN A 207.111.76.135
$INCLUDE primary/CLIENTMX.include

The two include files are:

IN 24h NS ns1.tagonline.com.
IN 24h NS ns2.tagonline.com.
IN 24h NS ns3.tagonline.com.

and

5m IN MX 10 13.smtp.tagonline.com.
5m IN MX 20 20.smtp.tagonline.com.
5m IN MX 30 14.smtp.tagonline.com.
5m IN MX 40 1.smtp.tagonline.com.

We explicitly want to inherit the owner. In this case, we could avoid
the inheritance by using @ explicitly as the owner in the include files.
However, this breaks when we do something like:

host1 IN A 207.111.76.13
$INCLUDE primary/CLIENTMX.include

host2 IN A 207.111.76.14
$INCLUDE primary/CLIENTMX.include

host3 IN A 207.111.76.15
$INCLUDE primary/CLIENTMX.include

...

for many hosts that need MX records.

I'm guessing that this error is occurring because, even though we've not
specified that argument to $INCLUDE, named-checkconf still believes that
$ORIGIN is being set within the $INCLUDE. However, we're not setting
$ORIGIN and we don't want to use @ anyway.

Is there some way to work around this, or a better way to share or
duplicate records across many owners? Or is named-checkconf wrong?

Finally: "named -v" reports "BIND 9.9.4-RedHat-9.9.4-18.el7_1.1
(Extended Support Version)" and named itself does support our zone
files. It is only "named-checkconf -z" that is balking.

We got this to work by commenting out the use of named-checkconf as a
prerequisite in the service file. That just doesn't seem like a good
idea.

Thanks...

Andrew Gideon