Upgrade from Fedora 33 to Fedora 34: bind-chroot-9.16.16-1.fc34.x86_64 When upgrading a perfectly functioning FC33 server running gind-chroot to FC34, the upgrade process for bind-chroot-9.16.16-1.fc34.x86_64 disables the service, breaking the server and causes unnecessary downtime. No other service is disabled by the upgrade process. Please correct this. Many thanks, -T
# systemctl status named-chroot ● named-chroot.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2021-06-15 04:27:29 EDT; 1min 9s ago Process: 62270 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t /var/named/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Process: 62272 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} -t /var/named/chroot $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 62273 (named) Tasks: 4 (limit: 2148) Memory: 53.1M CPU: 82ms CGroup: /system.slice/named-chroot.service └─62273 /usr/sbin/named -u named -c /etc/named.conf -t /var/named/chroot čen 15 04:27:29 fedora named[62273]: zone 0.in-addr.arpa/IN: loaded serial 0 čen 15 04:27:29 fedora named[62273]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: lo… serial 0 čen 15 04:27:29 fedora named[62273]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 čen 15 04:27:29 fedora named[62273]: zone localhost.localdomain/IN: loaded serial 0 čen 15 04:27:29 fedora named[62273]: zone localhost/IN: loaded serial 0 čen 15 04:27:29 fedora named[62273]: all zones loaded čen 15 04:27:29 fedora systemd[1]: Started Berkeley Internet Name Domain (DNS). čen 15 04:27:29 fedora named[62273]: running čen 15 04:27:39 fedora named[62273]: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out čen 15 04:27:39 fedora named[62273]: resolver priming query complete # rpm -q bind-chroot bind-chroot-9.11.32-1.fc33.x86_64 # dnf upgrade --release 34 ... # rpm -q bind-chroot bind-chroot-9.16.16-1.fc34.x86_64 # systemctl status named-chroot named ● named-chroot.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2021-06-15 04:45:26 EDT; 1min 19s ago Process: 506 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t /var/named/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Process: 517 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} -t /var/named/chroot $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 518 (named) Tasks: 5 (limit: 2146) Memory: 25.5M CPU: 79ms CGroup: /system.slice/named-chroot.service └─518 /usr/sbin/named -u named -c /etc/named.conf -t /var/named/chroot Jun 15 04:45:26 fedora named[518]: network unreachable resolving './DNSKEY/IN': 192.5.5.241#53 Jun 15 04:45:26 fedora named[518]: network unreachable resolving './NS/IN': 192.5.5.241#53 Jun 15 04:45:26 fedora named[518]: network unreachable resolving './DNSKEY/IN': 198.97.190.53#53 Jun 15 04:45:26 fedora named[518]: network unreachable resolving './NS/IN': 198.97.190.53#53 Jun 15 04:45:26 fedora named[518]: network unreachable resolving './DNSKEY/IN': 192.33.4.12#53 Jun 15 04:45:26 fedora named[518]: network unreachable resolving './NS/IN': 192.33.4.12#53 Jun 15 04:45:26 fedora named[518]: network unreachable resolving './DNSKEY/IN': 198.41.0.4#53 Jun 15 04:45:26 fedora named[518]: network unreachable resolving './NS/IN': 198.41.0.4#53 Jun 15 04:45:26 fedora named[518]: resolver priming query complete Jun 15 04:45:26 fedora named[518]: managed-keys-zone: Unable to fetch DNSKEY set '.': failure ○ named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled) Active: inactive (dead) Everything seems as smooth as it should be. Is it possible you did not properly enable your named-chroot service, just started it once? I cannot reproduce your issue.
Hi Petr, I posted this over on the Bind and Fedora mailing list. Mayu it will show you where the problem(s) are: -T Well, if at first you don't succeed, revise! See changes to named.root.key Broken bind-chroot repair after upgrading to Fedora 34: # means root $ means user 1) temporary workaround so you can surf the Internet for help: Change /etc/resolv.conf to # search your_domain # nameserver your_IP nameserver 208.67.222.123 2) in their "ultimate wisdom", the rpm maintainers disabled the service after upgrading it. See the following bug I posted on 2021-06-14: Bind-chroot upgrade from FC3 to FC34 disables the service breaking a server https://bugzilla.redhat.com/show_bug.cgi?id=1972000 To repair: # systemctl enable named-chroot.service # systemctl start named-chroot.service Other useful command(s): # systemctl stop named-chroot.service # systemctl status named-chroot.service # systemctl restart named-chroot.service 3) the new version of bind-chroot enables "dns security validation" by default. Make sure you do not have two `named.root.key` kicking around. One in /etc/named.root.key and one in /var/named/chroot/etc/named.root.key The bad one is the one that starts with `managed-keys {`, which is depreciated. The good one starts with `trust-anchors {` If the one in chroot is bad: # mv /var/named/chroot/etc/named.root.key /var/named/chroot/etc/named.root.key.deprediated # mv /etc/named.root.key /var/named/chroot/etc/named.root.key # ln -s /var/named/chroot/etc/named.root.key /etc/named.root.key To repair, place the following in your named.conf: by itself at the bottom: include "/etc/named.root.key"; Note: the actual location is: /var/named/chroot/etc/named.root.key add the following to your "options" block: dnssec-validation yes; Other useful command(s): Validation check: $ delv @$IP com ds $ delv @208.67.222.123 com ds ; fully validated ... 4) check (and repair) your configurations: named.conf: # named-checkconf -l -t /var/named/chroot /etc/named.conf Note: if you get the following error message, `/etc/named.root.key:1: option 'managed-keys' is deprecated` you may have to seperate named.root.conf files. This will read the one in chroot. Zones: # named-checkzone -t directory domain filename Note: the "domain name" in the following comes from named.conf zone, not `domainname`. For example: zone "abc.local" { type master; file "slaves/rent-a-nerd.hosts"; allow-update { key DHCP_UPDATER; }; }; The "domain" is the name of the "zone". "abc.local" in the above # named-checkzone -t /var/named/chroot/var/named/slaves abc.local abc.hosts zone abc.local/IN: loaded serial 265 OK # named-checkzone -t /var/named/chroot/var/named/slaves 255.168.192.in-addr.arpa abc.hosts.rev zone 255.168.192.in-addr.arpa/IN: loaded serial 213 OK 5) restart the bind-chroot service: Change /etc/resolv.conf back to search your_domain nameserver your_IP # nameserver 208.67.222.123 # systemctl restart named-chroot.service check for and repair errors with: $ systemctl status named-chroot.service # tail -f /var/log/messages
I have upgraded 4 VM's that are running named. There were no failures after the upgrades from F33 to F34. One system was configured with named-chroot.service and the other 3 were configured with named.service. In all cases, the service was not disabled and they all started upon reboot into F34.
If I ever figure out why I am different, I will get back
I were not able to find a reason for your failure. Any from reported things looks good. I were not able to reproduce reported issue. If you know what might be wrong, please reopen the bug with new details.
Hi Petr, I had so many stupid things wrong that I had to go through and do a total wipe and reinstall of both bind and bind-chroot. Now it is working perfectly. So if any of the issues I initially reported ever come back, I will reopen a new case. Thank you for helping! -T