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

Andrew Gideon andrew-bind-user-182 at
Fri Jun 5 19:07:51 UTC 2015

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

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 ( immediately after $ORIGIN (
        primary/CLIENTMX.include:1: record with inherited owner ( immediately after $ORIGIN (

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

        @       IN      SOA        (
        $INCLUDE                                primary/TAG.GENERIC.NAMESERVERS.include
                        IN      A     
        $INCLUDE                                primary/CLIENTMX.include

The two include files are:

        IN      24h     NS    
        IN      24h     NS    
        IN      24h     NS    


        5m              IN      MX      10
        5m              IN      MX      20
        5m              IN      MX      30
	5m              IN      MX      40

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
        $INCLUDE		primary/CLIENTMX.include
        host2	IN	A
        $INCLUDE		primary/CLIENTMX.include
        host3	IN	A
        $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


	Andrew Gideon

More information about the bind-users mailing list