My FC33->FC34 bind-chroot upgrade notes

ToddAndMargo ToddAndMargo at
Wed Jun 16 01:59:20 UTC 2021

On 6/15/21 12:51 PM, ToddAndMargo via bind-users wrote:
> On 6/14/21 10:02 PM, ToddAndMargo via bind-users wrote:
>> Hi All,
>> Thank you all for the enormous help in me getting bind-chroot
>> working after upgrading to Fedora 34.  Here are my notes.
>> Hope this helps someone else.
>> -T

Here are my revised, revised note.  Ed had to
straighten me out on some boo-boos:

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

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

    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) position named.conf and named.root.key:

    When the bind-chroot service starts, it copies the following into 
the chroot directory.
    Don't you do it!

       cp /etc/named.conf     /var/named/chroot/etc/.
       cp /etc/named.root.key /var/named/chroot/etc/.

    So the ones in your /etc/ directory are your masters.

    To trigger this:

       a) make sure /etc/named/conf and /etc/named.root.key are your masters
       b) stop name-bind
            # systemctl stop named-chroot
       c) make sure the follow do not exist:
       d) restart the service
            # systemctl start named-chroot

4) the new version of bind-chroot enables "dns security validation" by 

    Make sure you do not have two `named.root.key` kicking around.  One in
    and one in

    The bad one is the one that starts with `managed-keys {`, which is 
    The good one starts with `trust-anchors {`

    If the one in chroot is bad:
       # mv /var/named/chroot/etc/named.root.key 
       # 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 @ com ds
          ; fully validated

5) check (and repair) your configurations:


          # 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 

                you may have to seperate named.root.conf files.  This will
                read the one in chroot.

          # 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

          # named-checkzone -t /var/named/chroot/var/named/slaves abc.hosts.rev
          zone loaded serial 213

6) restart the bind-chroot service:

    Change /etc/resolv.conf back to
       search your_domain
       nameserver your_IP
       # nameserver

      # systemctl restart named-chroot.service

    check for and repair errors with:

      $ systemctl status named-chroot.service
      # tail -f /var/log/messages

More information about the bind-users mailing list