Bug 1972022

Summary: named-checkconf gives confusing depreciated 'managed-keys' message
Product: [Fedora] Fedora Reporter: Todd <ToddAndMargo>
Component: bindAssignee: Petr Menšík <pemensik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 34CC: aegorenk, anon.amish, dns-sig, mruprich, msehnout, pemensik, pzhukov, vonsch, zdohnal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-06-15 20:04:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Todd 2021-06-15 04:50:33 UTC
Fedora 34
bind 9.16


When

  include "/etc/named.root.key";

is included in named.conf, named-checkconf gives the following confusing depreciated 'managed-keys' message:


# named-checkconf -l -t /var/named/chroot /etc/named.conf
/etc/named.root.key:1: option 'managed-keys' is deprecated

# cat --number named.root.key
     1	trust-anchors {

Line 1 is NOT 'managed-keys'.

Please fix,

-T

Comment 1 Petr Menšík 2021-06-15 08:14:38 UTC
/etc/named.root.key file is configuration file. If it was modified, it will stay the same.

Please check command output of "rpm -V bind". It should list file /etc/named.root.key as modified. That means upgrade did not replace that file.

Package bind-9.16.16-1.fc34.x86_64 following contents of named.root.key:
trust-anchors {
        # ROOT KEYS: See https://data.iana.org/root-anchors/root-anchors.xml
        # for current trust anchor information.
        #
        # This key (20326) was published in the root zone in 2017.
        # Servers which were already using the old key (19036) should
        # roll seamlessly to this new one via RFC 5011 rollover. Servers
        # being set up for the first time can use the contents of this
        # file as initializing keys; thereafter, the keys in the
        # managed key database will be trusted and maintained
        # automatically.
        . initial-ds 20326 8 2 "E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D";
};

Such configuration does not report any warning on named-checkconf /etc/named.root.key.

Do you have copy of files in /var/named/chroot/etc in case named-chroot.service is stopped? Is /etc/named.root.key used from host root /etc and unmodified? I tried upgrade from f33 to f34 and it was smooth. It seems to me your /etc/named.root.key was modified manually, therefore it stayed in original way.

If you remove that file and reinstall bind package, it should be installed fresh.

Comment 2 Todd 2021-06-15 19:46:51 UTC
For bind, which I am NOT running:

# rpm -V bind
......G..  c /etc/named.conf
....L.G..  c /etc/named.root.key


For bind-chroot, which I AM running:
# rpm -V bind-chroot
.....U...  c /var/named/chroot/etc/named.conf


OH POOP!!!

I have TWO named.root.key's.  

The one in
   /etc/named.root.key
is the good one from Fedora 34

and the one in
   /var/named/chroot/etc/named.root.key
is the depreciated one from Fedora 33.

I manually fixed the issue.

Now I get:

# named-checkconf -l -t /var/named/chroot /etc/named.conf
abc.local IN _default master
255.168.192.in-addr.arpa IN _default master
0.0.127.in-addr.arpa IN _default master



Question: was the named-chroot RPM post installation script suppose to update named.root.key in chroot, or was I suppose to do it manually?

If I am suppose to do this manually, then, not-a-bug.  If the post install script is suppose to do this, then change the title and make this the bug

Many thanks,
-T

Comment 3 Petr Menšík 2021-06-15 20:04:35 UTC
No, it was not supposed to update ANY file in /var/named/chroot, excluding few empty directories.

bind-chroot uses mount --bind to make files from normal /etc available in chroot directory after named-chroot.service start. That means you should NOT copy any file into chroot directory.
Instead, use just existing configuration and /etc/named directory for any new configuration snippets. Then the same config should work both for named.service as well as named-chroot.service, whatever you choose to use.

I would recommend to stop named-chroot.service and move existing configuration and data copies to normal /etc and /var/named. Then start named-chroot.service again.

Check both files point to the same file on file system:

stat /etc/named.root.key
stat /var/named/chroot/etc/named.root.key

Their Device: and Inode: should match.

Similar with other files. Make sure to backup it first. Target files in /var/named/chroot should not exist or be empty directory in order to be mounted this way. List of files configured this way is prepared by named-chroot-setup.service, open file /etc/named-chroot.files to get its list.

Closing therefore as not bug was found.

Anyway, unless you turn off selinux, I think there is no longer good reason for bind-chroot usage. SELinux offers much better protection than offers chroot. Consider using just named.service with SELinux enabled.

Comment 4 Todd 2021-06-16 04:24:17 UTC
Hi Oetr,


I want to model what I have at my customer sites.  One of them runs a peice of specialty software (meanming $$$$$) that does not get along with SELinux.  (They won't fix it either.)

Thank you for straightening me out.

-T

My latest.

# stat /etc/named.root.key
  File: /etc/named.root.key
  Size: 686       	Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d	Inode: 60033354    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (   25/   named)
Context: system_u:object_r:etc_t:s0
Access: 2021-06-15 18:43:07.720811481 -0700
Modify: 2021-06-03 07:47:41.000000000 -0700
Change: 2021-06-15 18:42:54.638027506 -0700
 Birth: 2021-06-11 23:39:43.081693863 -0700

# stat /var/named/chroot/etc/named.root.key
  File: /var/named/chroot/etc/named.root.key
  Size: 686       	Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d	Inode: 60033354    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (   25/   named)
Context: system_u:object_r:etc_t:s0
Access: 2021-06-15 18:43:07.720811481 -0700
Modify: 2021-06-03 07:47:41.000000000 -0700
Change: 2021-06-15 18:42:54.638027506 -0700
 Birth: 2021-06-11 23:39:43.081693863 -0700