Bug 1972000

# 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