New error about zone files: record with inherited owner ... immediately after $ORIGIN
andrew-bind-user-182 at tagonline.com
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
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 (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. (
IN A 126.96.36.199
The two include files are:
IN 24h NS ns1.tagonline.com.
IN 24h NS ns2.tagonline.com.
IN 24h NS ns3.tagonline.com.
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 188.8.131.52
host2 IN A 184.108.40.206
host3 IN A 220.127.116.11
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
More information about the bind-users