Hi All,
FC34 bin 9.16
Placing include "/etc/named.root.key"; in my bind.conf, give me the following error
# named-checkconf -l -t /var/named/chroot /etc/named.conf /etc/named.root.key:1: option 'managed-keys' is deprecated
What do I use it its place? (The Duck is failing me.)
Many thanks, -T
ToddAndMargo via users wrote:
Placing include "/etc/named.root.key"; in my bind.conf, give me the following error
# named-checkconf -l -t /var/named/chroot /etc/named.conf /etc/named.root.key:1: option 'managed-keys' is deprecated
What do I use it its place? (The Duck is failing me.)
The fine manual¹ covers this:
managed-keys
Is identical to trust-anchors; this option is deprecated in favor of trust-anchors with the initial-key keyword, and may be removed in a future release.
¹ https://bind9.readthedocs.io/en/latest/reference.html#index-0
Bind has some very thorough documentation. It's even easily searchable if you view it online. That's better than any general search engine.
On 6/14/21 9:16 PM, Todd Zullinger wrote:
ToddAndMargo via users wrote:
Placing include "/etc/named.root.key"; in my bind.conf, give me the following error
# named-checkconf -l -t /var/named/chroot /etc/named.conf /etc/named.root.key:1: option 'managed-keys' is deprecated
What do I use it its place? (The Duck is failing me.)
The fine manual¹ covers this:
managed-keys Is identical to trust-anchors; this option is deprecated in favor of trust-anchors with the initial-key keyword, and may be removed in a future release.¹ https://bind9.readthedocs.io/en/latest/reference.html#index-0
Bind has some very thorough documentation. It's even easily searchable if you view it online. That's better than any general search engine.
Hi Todd,
Then I do believe I just tripped across a bug:
# cat --number named.root.key 1 trust-anchors {
Line 1 is NOT 'managed-keys'.
Or perhaps it was just a warning to confuse the dickens out of the uninitiated?
-T
On 6/14/21 9:42 PM, ToddAndMargo via users wrote:
On 6/14/21 9:16 PM, Todd Zullinger wrote:
ToddAndMargo via users wrote:
Placing include "/etc/named.root.key"; in my bind.conf, give me the following error
# named-checkconf -l -t /var/named/chroot /etc/named.conf /etc/named.root.key:1: option 'managed-keys' is deprecated
What do I use it its place? (The Duck is failing me.)
The fine manual¹ covers this:
managed-keys
Is identical to trust-anchors; this option is deprecated in favor of trust-anchors with the initial-key keyword, and may be removed in a future release.
¹ https://bind9.readthedocs.io/en/latest/reference.html#index-0
Bind has some very thorough documentation. It's even easily searchable if you view it online. That's better than any general search engine.
Hi Todd,
Then I do believe I just tripped across a bug:
# cat --number named.root.key 1 trust-anchors {
Line 1 is NOT 'managed-keys'.
Or perhaps it was just a warning to confuse the dickens out of the uninitiated?
-T
Just posted:
named-checkconf gives confusing depreciated 'managed-keys' message
On 15/06/2021 12:42, ToddAndMargo via users wrote:
On 6/14/21 9:16 PM, Todd Zullinger wrote:
ToddAndMargo via users wrote:
Placing include "/etc/named.root.key"; in my bind.conf, give me the following error
# named-checkconf -l -t /var/named/chroot /etc/named.conf /etc/named.root.key:1: option 'managed-keys' is deprecated
What do I use it its place? (The Duck is failing me.)
The fine manual¹ covers this:
managed-keys
Is identical to trust-anchors; this option is deprecated in favor of trust-anchors with the initial-key keyword, and may be removed in a future release.
¹ https://bind9.readthedocs.io/en/latest/reference.html#index-0
Bind has some very thorough documentation. It's even easily searchable if you view it online. That's better than any general search engine.
Hi Todd,
Then I do believe I just tripped across a bug:
# cat --number named.root.key 1 trust-anchors {
Line 1 is NOT 'managed-keys'.
Or perhaps it was just a warning to confuse the dickens out of the uninitiated?
If I were you I may consider checking the upgrade logs.
While not using the chroot service I just upgraded my internal bind system from F33 to F34. I do have all of these installed on the upgraded system.
bind-license-9.16.16-1.fc34.noarch bind-dnssec-doc-9.16.16-1.fc34.noarch bind-libs-9.16.16-1.fc34.x86_64 bind-utils-9.16.16-1.fc34.x86_64 bind-dnssec-utils-9.16.16-1.fc34.x86_64 bind-9.16.16-1.fc34.x86_64 bind-chroot-9.16.16-1.fc34.x86_64
There exists only one
[root@f33k ~]# locate named.root.key /etc/named.root.key
And the first line of that file contains
trust-anchors {
I didn't change anything in /etc/named.root.key since my named.conf contains
dnssec-enable yes; dnssec-validation yes;
And using your example in your notes post.
[egreshko@f33k ~]$ delv @208.67.222.123 com ds ; fully validated
Also, the named.service was enabled, it started at the boot, and there were no errors.
On 15/06/2021 15:41, Ed Greshko wrote:
If I were you I may consider checking the upgrade logs.
While not using the chroot service I just upgraded my internal bind system from F33 to F34. I do have all of these installed on the upgraded system.
I had another F33 VM which needed upgrading. Before the upgrade I established a named-chroot environment.
I performed the upgrade.
Upon reboot named-chroot was still enabled and it started just fine. No problems noted.
FWIW, I would also check to make sure that the inodes /etc/named.root.key is the same as /var/named/chroot/etc/named.root.key
[root@f33g etc]# ll -i /var/named/chroot/etc/named.root.key /etc/named.root.key 486885 -rw-r--r--. 1 root named 686 Jun 3 22:47 /etc/named.root.key 486885 -rw-r--r--. 1 root named 686 Jun 3 22:47 /var/named/chroot/etc/named.root.key
On Tue, 15 Jun 2021 00:16:01 -0400 Todd Zullinger wrote:
Bind has some very thorough documentation. It's even easily searchable if you view it online. That's better than any general search engine.
Bind has 47,589,322 pages of documentation you can't search unless you already know all the proper jargon. The actual docs are the last place I ever want to look for anything :-).
Tom Horsley wrote:
On Tue, 15 Jun 2021 00:16:01 -0400 Todd Zullinger wrote:
Bind has some very thorough documentation. It's even easily searchable if you view it online. That's better than any general search engine.
Bind has 47,589,322 pages of documentation you can't search unless you already know all the proper jargon. The actual docs are the last place I ever want to look for anything :-).
Heh. If you're not sure of the terminology, bind is the last thing you should be running¹. ;)
I'd argue that the overwhemling majority of folks on this list are better served by a name server other than bind.
Use dnsmasq or something else for most home-based DNS services (and even for plenty of production-grade DNS services).
¹ A good friend of mine with too many scars from the early days of bind would remove the qualifying condition from that sentence. He's not wrong.
Tom Horsley wrote:
Bind has 47,589,322 pages of documentation you can't search unless you already know all the proper jargon. The actual docs are the last place I ever want to look for anything :-).
Todd Zullinger:
Heh. If you're not sure of the terminology, bind is the last thing you should be running¹. ;)
Though, to be fair, most of the time when you're researching a problem with BIND, you'll be looking up snippets from your config files, or error messages, so you do have codewords to search for.
I'd argue that the overwhemling majority of folks on this list are better served by a name server other than bind.
Use dnsmasq or something else for most home-based DNS services (and even for plenty of production-grade DNS services).
I'd agree with that. Most people just need name resolution, they're not actually being a public DNS server.
I use it because it and DHCPD were what I had to play with when I got started, long ago. I figured out what I needed to do for that, which wasn't too much of a complex requirement, and manage to work out how to handle any changes across different releases.
I do come a cropper with a few modern gadgets that do a half-arsed job of using DHCP and normal DNS, and seem to just want to use some bodge of avahi/zeroconf/auto self configuration expecting it to be there, somewhat like the UPnP nightmare of many years ago of NAT unfriendly things. And avahi, et al, are useless to various older devices that only handled DHCP or completely manual configuration.
-
Ed Greshko -
Tim -
Todd Zullinger -
ToddAndMargo -
Tom Horsley