On 6/15/21 6:57 PM, ToddAndMargo via users wrote:
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
I hope this is the last time I hvae to revise this!
add the following to your "options" block: dnssec-validation yes; 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.
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! This will fail if it find them there already. Then things get really confusing.
/etc/named.conf copies to /var/named/chroot/etc/. /etc/named.root.key copies to /var/named/chroot/etc/.
The ones in your /etc directory are your masters.
When the named-chroot service is stopped. Make sure you do not have two copies of either or both `/named/conf` and `named.root.key` kicking around:
/etc/named.conf /var/named/chroot/etc/named.conf <-- should not be there when stopped
/etc/named.root.key /var/named/chroot/etc/named.root.key <-- should not be there when stopped
The ones in the chroot directory should have disappeared. Make sure you only have one /etc/named.conf and /etc/named.root.key.
If you have two named.root.key's kicking around, the one that starts with trust-anchors { is the good one.
To trigger the copy:
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) update /etc/named.conf and /etc/named.root.key as desired
e) restart the service # systemctl start named-chroot
4) the new version of bind-chroot enables "dns security validation" by default.
Note: make sure /etc/named.root.key starts with `trust-anchors {`. `managed-keys {` is depreciated.
Note: you should only have one named.root.key. /etc/named.root.key is your master. If the named-chroot service is stopped, the one in /var/named/chroot/etc should disappear.
To properly configure (repair), place the following in your named.conf:
add the following to your "options" block: dnssec-validation yes;
by itself at the bottom: include "/etc/named.root.key";
Then restart the service: # systemctl restart bind-named.service
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
Zones: # named-checkzone -t directory domain filename
Note: the "domain name" is theh "zone" name from named.conf zone, not `domainname`. For example:
zone "abc.local" { type master; file "slaves/abc.hosts"; allow-update { key DHCP_UPDATER; }; }; The "domain" is the name of the "zone". "abc.local" in the above. You should check both your forward and reverse zones.
Examples: # 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
Restart the service: # systemctl restart named-chroot.service
Check for and repair startup errors with:
$ systemctl status named-chroot.service # tail -f /var/log/messages