Foreman creates a duplicate DNS zone for `168.192.in-addr.arpa'` in /etc/bind/zones.conf

Support
1

Problem:

I’m provisioning my systems on a private network at 192.168.100.0/21.

For reasons that I do not understand, Foreman is adding a zone for 192.168.x.y to /etc/bind/zones.conf. Unfortunately, the bind9 DNS server considers this a duplicate configuration since that network is already stored under /etc/bind/zones.rfc1918, and
fails, as shown in the systemctl output below:

systemctl status bind9 --no-pager --full

● bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-03-12 01:45:37 UTC; 15h ago
     Docs: man:named(8)
  Process: 21467 ExecStop=/usr/sbin/rndc stop (code=exited, status=0/SUCCESS)
  Process: 21470 ExecStart=/usr/sbin/named -f $OPTIONS (code=exited, status=1/FAILURE)
 Main PID: 21470 (code=exited, status=1/FAILURE)

Mar 12 01:45:37 foreman named[21470]: adjusted limit on open files from 4096 to 1048576
Mar 12 01:45:37 foreman named[21470]: found 4 CPUs, using 4 worker threads
Mar 12 01:45:37 foreman named[21470]: using 3 UDP listeners per interface
Mar 12 01:45:37 foreman named[21470]: using up to 4096 sockets
Mar 12 01:45:37 foreman named[21470]: loading configuration from '/etc/bind/named.conf'
Mar 12 01:45:37 foreman named[21470]: /etc/bind/zones.conf:1: zone '168.192.in-addr.arpa': already exists previous definition: /etc/bind/zones.rfc1918:20
Mar 12 01:45:37 foreman named[21470]: loading configuration: failure
Mar 12 01:45:37 foreman named[21470]: exiting (due to fatal error)
Mar 12 01:45:37 foreman systemd[1]: bind9.service: Main process exited, code=exited, status=1/FAILURE
Mar 12 01:45:37 foreman systemd[1]: bind9.service: Failed with result 'exit-code'.

Expected outcome:

I didn’t expect the Foreman Installer to create a redundant zone under /etc/bind/zones.conf. How can I avoid this?

Foreman and Proxy versions:

  • OS version: Ubuntu 18.04.2

  • Foreman version: 1.21.0

  • Proxy versions:

    DHCP
    Version1.21.0
    Subnets CRT Provisioning (192.168.100.0/21)

    DNS
    Version1.21.0
    Domains None found

    TFTP
    Version1.21.0
    TFTP server 192.168.100.10

2

A little more information. If I remove the offending section from /etc/bind/zones.conf, the Foreman Installer puts it back:

[ WARN 2019-03-14T22:55:07 verbose]  /Stage[main]/Dns::Config/Concat[/etc/bind/zones.conf]/File[/etc/bind/zones.conf]/content:
[ WARN 2019-03-14T22:55:07 verbose] --- /etc/bind/zones.conf    2019-03-14 21:32:33.992086229 +0000
[ WARN 2019-03-14T22:55:07 verbose] +++ /tmp/puppet-file20190314-6167-1w42i2f   2019-03-14 22:55:07.028073942 +0000
[ WARN 2019-03-14T22:55:07 verbose] @@ -0,0 +1,14 @@
[ WARN 2019-03-14T22:55:07 verbose] + zone "168.192.in-addr.arpa" {
[ WARN 2019-03-14T22:55:07 verbose] +    type master;
[ WARN 2019-03-14T22:55:07 verbose] +    file "/var/cache/bind/zones/db.168.192.in-addr.arpa";
[ WARN 2019-03-14T22:55:07 verbose] +    update-policy {
[ WARN 2019-03-14T22:55:07 verbose] +            grant rndc-key zonesub ANY;
[ WARN 2019-03-14T22:55:07 verbose] +    };
[ WARN 2019-03-14T22:55:07 verbose] +};
3

Probably a bug in our puppet code handling debian systems differently? @ekohl

4

Not really a bug in our code, more undefined behavior I’d say. The root cause behind this is the localzonepath. On Debian this includes the RFC1918 zones, like 168.192.in-addr.arpa. This causes the duplication definition. In normal operation this prevents queries for NAT IPs to be sent to the internet. We don’t touch this file and trust the distro.

You can exclude loading of that file by adding dns::localzonepath: unmanaged to /etc/foreman-installer/custom-hiera.yaml or manually removing it from zones.rfc1918.

EL7 ships /etc/named.rfc1912.zones (RFC1912: Common DNS Operational and Configuration Errors) and doesn’t include the RFC1918 zones so you won’t see the issue there.

I hope this clarifies things and I’d appreciate what you as a user think is the best solution for us.

On a side note: I’m rethinking the DNS deployment model and intend to gather feedback to come up with a RFC.

1 Like