On 6/14/21 10:00 PM, ToddAndMargo via 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 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) position named.conf and named.root.key:
When the bind-chroot service starts, it 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: /var/named/chroot/etc/named.conf /var/named/chroot/etc/named.root.key d) restart the service # systemctl start named-chroot
4) 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 ...
5) 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
6) 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