10:50 p.m.
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
11:16 p.m.
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.
--
Todd
11:42 p.m.
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
11:51 p.m.
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
https://bugzilla.redhat.com/show_bug.cgi?id=1972022
-T
2:41 a.m.
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.
--
Remind me to ignore comments which aren't germane to the thread.
7 a.m.
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
--
Remind me to ignore comments which aren't germane to the thread.
9:44 a.m.
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 :-).
10:31 a.m.
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.
--
Todd
2:57 p.m.
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.
--
uname -rsvp
Linux 5.11.21-100.fc32.x86_64 #1 SMP Fri May 14 18:03:50 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
1045
days inactive
1045
days old
8 comments
5 participants
participants (5)
-
Ed Greshko -
Tim -
Todd Zullinger -
ToddAndMargo -
Tom Horsley