Re: My FC33->FC34 bind-chroot upgrade notes
Am 17.06.21 um 21:43 schrieb ToddAndMargo via bind-users: On 6/17/21 3:12 AM, Reindl Harald wrote: however, in the real world just write "sudo command" is the best you can do - for the average user it's complete and leaves no questions for power users which don't like sudo it should be no deal-breaker to type the command without "sudo" in a root shell case closed All I have to do is get over hating the sudo command i don't use it too but i have no problem pastign something with "sudo" in front without into a terminal And I kinda-sorta of expect anyone that uses "bind" (power uses in the extreme -- genius level) to know what # and $ at the prompt means i am that much power-user that my prompt don't show that because i perfer colors for different roles and as short as possible prompts :-) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/17/21 3:12 AM, Reindl Harald wrote: however, in the real world just write "sudo command" is the best you can do - for the average user it's complete and leaves no questions for power users which don't like sudo it should be no deal-breaker to type the command without "sudo" in a root shell case closed All I have to do is get over hating the sudo command. And I kinda-sorta of expect anyone that uses "bind" (power uses in the extreme -- genius level) to know what # and $ at the prompt means. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
Am 17.06.21 um 07:43 schrieb Todd Chester via bind-users: On 6/16/21 2:52 PM, Reindl Harald wrote: Does this alteration at the top make it any clearer? Note: at the command prompt, I use the following terminology: # means run as root $ means run as user Inside a file, "#" mean it is a comment not really - either use the ubuntu "sudo everything" or just type "root: command" and "user: command" : that would confuse the dickens out of me. I program in Raku (Perl 6) and ":" has a bunch of special meanings that I always forget. So ":" give me a start but when you follow a how-to which tells you commands to run in the terminal leaded by the user you don't do program in Raku a) the typical user don't program at all b) i expect from programmers some sense for context c) # is typcally a comment d) $ leads a variable in PHP, but we don't talk about PHP e) the typical user won't remember what # and $ means however, in the real world just write "sudo command" is the best you can do - for the average user it's complete and leaves no questions for power users which don't like sudo it should be no deal-breaker to type the command without "sudo" in a root shell case closed ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/16/21 2:52 PM, Reindl Harald wrote: Does this alteration at the top make it any clearer? Note: at the command prompt, I use the following terminology: # means run as root $ means run as user Inside a file, "#" mean it is a comment not really - either use the ubuntu "sudo everything" or just type "root: command" and "user: command" : that would confuse the dickens out of me. I program in Raku (Perl 6) and ":" has a bunch of special meanings that I always forget. So ":" give me a start. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
Am 16.06.21 um 20:31 schrieb ToddAndMargo via bind-users: On 6/16/21 2:16 AM, Reindl Harald wrote: Am 16.06.21 um 09:31 schrieb ToddAndMargo via bind-users: ... # means root $ means user ... Sometimes, in your configuration file extracts, you use '#' meaning 'this line is a comment'. I guess this is a write-up for a novice. The non-novices here have overlooked it, but I'm much closer to the novice end of the BIND user spectrum than they are and If I were a *complete* novice, I'd find these uses of '#' very confusing. Which lines? lines starting with # -- here it is a comment sign Change /etc/resolv.conf back to search your_domain nameserver your_IP # nameserver 208.67.222.123 -- here it is meant as command running as root Then restart the service: # systemctl restart bind-named.service Does this alteration at the top make it any clearer? Note: at the command prompt, I use the following terminology: # means run as root $ means run as user Inside a file, "#" mean it is a comment not really - either use the ubuntu "sudo everything" or just type "root: command" and "user: command" ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/16/21 12:45 PM, Richard T.A. Neal wrote: On 16 June 2021 7:31 pm, ToddAndMargo wrote: Does this alteration at the top make it any clearer? Note: at the command prompt, I use the following terminology: # means run as root $ means run as user Inside a file, "#" mean it is a comment Others might have better suggestions but the way I tend to do this is to simply prefix any commands that must be run as root with 'sudo', eg; $ sudo rndc reconfig $ tail /var/log/syslog Thus it’s hopefully clear which lines need to be run with root privileges and demonstrates using sudo to achieve this. Best, Richard. I have used su for such in the past: $ su root -c "command and parameters" to make it obvious it is a root command. I personally can't stand the sudo command, so I usually avoid it. Lately, I just use # and $, but I can see now where that would cause some confusion. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: My FC33->FC34 bind-chroot upgrade notes
On 16 June 2021 7:31 pm, ToddAndMargo wrote: > > Does this alteration at the top make it any clearer? > > Note: at the command prompt, I use the following terminology: ># means run as root >$ means run as user > Inside a file, "#" mean it is a comment Others might have better suggestions but the way I tend to do this is to simply prefix any commands that must be run as root with 'sudo', eg; $ sudo rndc reconfig $ tail /var/log/syslog Thus it’s hopefully clear which lines need to be run with root privileges and demonstrates using sudo to achieve this. Best, Richard. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/16/21 2:16 AM, Reindl Harald wrote: Am 16.06.21 um 09:31 schrieb ToddAndMargo via bind-users: ... # means root $ means user ... Sometimes, in your configuration file extracts, you use '#' meaning 'this line is a comment'. I guess this is a write-up for a novice. The non-novices here have overlooked it, but I'm much closer to the novice end of the BIND user spectrum than they are and If I were a *complete* novice, I'd find these uses of '#' very confusing. Which lines? lines starting with # -- here it is a comment sign Change /etc/resolv.conf back to search your_domain nameserver your_IP # nameserver 208.67.222.123 -- here it is meant as command running as root Then restart the service: # systemctl restart bind-named.service Does this alteration at the top make it any clearer? Note: at the command prompt, I use the following terminology: # means run as root $ means run as user Inside a file, "#" mean it is a comment ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
Am 16.06.21 um 09:31 schrieb ToddAndMargo via bind-users: ... # means root $ means user ... Sometimes, in your configuration file extracts, you use '#' meaning 'this line is a comment'. I guess this is a write-up for a novice. The non-novices here have overlooked it, but I'm much closer to the novice end of the BIND user spectrum than they are and If I were a *complete* novice, I'd find these uses of '#' very confusing. Which lines? lines starting with # -- here it is a comment sign Change /etc/resolv.conf back to search your_domain nameserver your_IP # nameserver 208.67.222.123 -- here it is meant as command running as root Then restart the service: # systemctl restart bind-named.service ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/15/21 11:54 PM, G.W. Haywood via bind-users wrote: Hi there, On Wed, 16 Jun 2021, ToddAndMargo wrote: Re: My FC33->FC34 bind-chroot upgrade notes I hope this is the last time I have to revise this! ... Unfortunately perhaps not. :'( ... # means root $ means user ... Sometimes, in your configuration file extracts, you use '#' meaning 'this line is a comment'. I guess this is a write-up for a novice. The non-novices here have overlooked it, but I'm much closer to the novice end of the BIND user spectrum than they are and If I were a *complete* novice, I'd find these uses of '#' very confusing. Which lines? BIND is a hair puller at times. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
Hi there, On Wed, 16 Jun 2021, ToddAndMargo wrote: Re: My FC33->FC34 bind-chroot upgrade notes I hope this is the last time I have to revise this! ... Unfortunately perhaps not. ... # means root $ means user ... Sometimes, in your configuration file extracts, you use '#' meaning 'this line is a comment'. I guess this is a write-up for a novice. The non-novices here have overlooked it, but I'm much closer to the novice end of the BIND user spectrum than they are and If I were a *complete* novice, I'd find these uses of '#' very confusing. -- 73, Ged. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/15/21 6:59 PM, ToddAndMargo via bind-users wrote:
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:
I hope this is the last time I have to revise this!
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 stopnamed-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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the
Re: My FC33->FC34 bind-chroot upgrade notes
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
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 stopnamed-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:
/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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
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
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 stopnamed-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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
My FC33->FC34 bind-chroot upgrade notes
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
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 stopnamed-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.
To repair, place the following in your named.conf:
by itself at the bottom:
include "/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`
it is a bug in named-checkconf.
See the following I posted on 2021-06-14. Just ignore
the message.
named-checkconf gives confusing depreciated
'managed-keys' message
https://bugzilla.redhat.com/show_bug.cgi?id=1972022
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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
