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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
