Comment 0 for bug 2015793

bind9 releases 9.16.33 and 9.18.7 introduced a change[1] that can make bind9 fail to restart after an upgrade from earlier releases.

A bind9 server that was serving a DNSSEC zone before will refuse to start after this update if the administrator was relying on the "inline-signing yes" silent default previously.

For example, if you had a zone like this:

/var/lib/bind/db.example.fake:
$TTL 3600
@ IN SOA example.fake. root.example.fake. (
                              2 ; Serial
                         3600 ; Refresh
                          86400 ; Retry
                        2419200 ; Expire
                         3600 ) ; Negative Cache TTL
;
@ IN NS ns.example.fake.
@ IN A 192.168.10.1
ns IN A 192.168.10.1
banana IN A 192.168.10.2
avocado IN A 192.168.10.3

Configured like this (note the absence of "inline-signing yes"):
zone "example.fake" {
    type master;
    file "/var/lib/bind/db.example.fake";
    dnssec-policy default;
};

When you upgrade bind9 to the updated version in focal and kinetic, the named service will fail to start (example below depicted from a jammy update):
Apr 10 18:31:18 j-bind9-mre-upgrade named[4347]: loading configuration from '/etc/bind/named.conf'
Apr 10 18:31:18 j-bind9-mre-upgrade named[4347]: /etc/bind/named.conf.local:12: 'inline-signing yes;' must also be configured explicitly for zones using dnssec-policy without a configured 'allow-update' or 'update-policy'. See https://kb.isc.org/docs/dnssec-policy-requires-dynamic-dns-or-inline-signing
Apr 10 18:31:18 j-bind9-mre-upgrade named[4347]: loading configuration: failure
Apr 10 18:31:18 j-bind9-mre-upgrade named[4347]: exiting (due to fatal error)
Apr 10 18:31:18 j-bind9-mre-upgrade systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE
Apr 10 18:31:18 j-bind9-mre-upgrade systemd[1]: named.service: Failed with result 'exit-code'.
Apr 10 18:31:18 j-bind9-mre-upgrade systemd[1]: Failed to start BIND Domain Name Server.

The apt transaction won't fail, but will also not flag that the service is down:

Setting up bind9 (1:9.18.12-0ubuntu0.22.04.1) ...
named-resolvconf.service is a disabled or a static unit not running, not starting it.
Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142.
Setting up bind9-host (1:9.18.12-0ubuntu0.22.04.1) ...
Setting up bind9-dnsutils (1:9.18.12-0ubuntu0.22.04.1) ...
Processing triggers for ufw (0.36.1-4build1) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.35-0ubuntu3.1) ...

root@j-bind9-mre-upgrade:~# systemctl status bind9
× named.service - BIND Domain Name Server
     Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2023-04-10 18:31:18 UTC; 3s ago
       Docs: man:named(8)
    Process: 4346 ExecStart=/usr/sbin/named $OPTIONS (code=exited, status=1/FAILURE)
        CPU: 26ms

We haven't gotten reports about this yet, and maybe we won't, but it's a risky update.

I briefly checked the named-checkconf and named-checkzone utilities, to see if they would catch this configuration problem, but they just look at syntax errors, not this type of misconfiguration, so they don't flag it. If they did, maybe we could do something in preinst to fail the upgrade before the service is brought down.

The focal version of the bind9 MRE is currently in review, and will probably be halted until we have a better understanding of this issue and how to deal with it.

Ideas welcome.

1. https://kb.isc.org/docs/dnssec-policy-requires-dynamic-dns-or-inline-signing