Bug 1267991

Summary: some entries in named.ca are outdated
Product: Red Hat Enterprise Linux 6 Reporter: debugitu <RedHat-Bug>
Component: bindAssignee: Tomáš Hozza <thozza>
Status: CLOSED ERRATA QA Contact: qe-baseos-daemons
Severity: low Docs Contact:
Priority: low    
Version: 6.8CC: ovasik, psklenar
Target Milestone: rcKeywords: EasyFix
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-10 20:28:13 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 debugitu 2015-10-01 14:17:00 UTC
The file /var/named/named.ca is relatively old which comes within the "bind" rpm package (~ 8 years). Do you have a plan to have a process in place which updates that file in the package if a new version of the hint zone is available at http://www.internic.net/domain/named.root ?

My syslog is flooded with messages like:

Oct  1 13:44:00 crehelf named[1622]: checkhints: d.root-servers.net/A (199.7.91.13) missing from hints
Oct  1 13:44:00 crehelf named[1622]: checkhints: d.root-servers.net/A (128.8.10.90) extra record in hints
Oct  1 13:44:01 crehelf named[1622]: checkhints: d.root-servers.net/A (199.7.91.13) missing from hints
Oct  1 13:44:01 crehelf named[1622]: checkhints: d.root-servers.net/A (128.8.10.90) extra record in hints
Oct  1 13:44:03 crehelf named[1622]: checkhints: d.root-servers.net/A (199.7.91.13) missing from hints
Oct  1 13:44:03 crehelf named[1622]: checkhints: d.root-servers.net/A (128.8.10.90) extra record in hints
Oct  1 13:44:05 crehelf named[1622]: checkhints: d.root-servers.net/A (199.7.91.13) missing from hints
Oct  1 13:44:05 crehelf named[1622]: checkhints: d.root-servers.net/A (128.8.10.90) extra record in hints

The messages are coming after the name server is up since more than 21 days (half of the TTL value of the hint records?)

Comment 2 Tomáš Hozza 2015-10-01 14:24:23 UTC
The file is not 8 years old, it has been updated. You didn't stated your RPM version so I can not tell what version you are using.

Anyway BIND does root NS priming on startup - fetches the up-to-date list of root NS IPs list. Therefore having some outdated entries in named.ca is not really an issue.

Comment 3 debugitu 2015-10-01 14:47:26 UTC
(In reply to Tomas Hozza from comment #2)
> The file is not 8 years old, it has been updated. You didn't stated your RPM
> version so I can not tell what version you are using.
> 
> Anyway BIND does root NS priming on startup - fetches the up-to-date list of
> root NS IPs list. Therefore having some outdated entries in named.ca is not
> really an issue.

Inside the file:

;       last update:    Nov 01, 2007
;       related version of root zone:   2007110100

The output of "ls -l /var/named/named.ca":

-rw-r--r--. 1 root named 2516 Nov 23  2007 /var/named/named.ca

The rpm package version:

bind-9.8.2-0.37.rc1.el6_7.4.x86_64

Sorry for missing the details.

Comment 4 Tomáš Hozza 2015-10-02 07:58:45 UTC
Something is wrong with the package you have. I updated named.ca due to Bug #917356 in RHEL 6.7.

[root@rhel-6 ~]# ls -l /var/named/named.ca
-rw-r-----. 1 root named 2075 apr 23  2014 /var/named/named.ca

[root@rhel-6 ~]# rpm -q bind
bind-9.8.2-0.37.rc1.el6_7.4.x86_64

[root@rhel-6 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.7 (Santiago)


/var/named/named.ca is marked in the SPEC file as %config without "noreplace". This means that even if you changed the file yourself, RPM will install the file from package and backup your modified file with ".rpmsave" suffix.

It is hard to say what caused the state on your system. Please try to reinstall the bind package.

Comment 5 debugitu 2015-10-02 10:03:43 UTC
(In reply to Tomas Hozza from comment #4)
> Something is wrong with the package you have. I updated named.ca due to Bug
> #917356 in RHEL 6.7.
> 
> [root@rhel-6 ~]# ls -l /var/named/named.ca
> -rw-r-----. 1 root named 2075 apr 23  2014 /var/named/named.ca
> 
> [root@rhel-6 ~]# rpm -q bind
> bind-9.8.2-0.37.rc1.el6_7.4.x86_64
> 
> [root@rhel-6 ~]# cat /etc/redhat-release 
> Red Hat Enterprise Linux Server release 6.7 (Santiago)
> 
> 
> /var/named/named.ca is marked in the SPEC file as %config without
> "noreplace". This means that even if you changed the file yourself, RPM will
> install the file from package and backup your modified file with ".rpmsave"
> suffix.
> 
> It is hard to say what caused the state on your system. Please try to
> reinstall the bind package.

The actual problem is that the upgrade of the "bind" package does not create a file /var/named/named.ca.rpmnew.

Here is from the install log the relevant part:

Jun 01 08:31:29 Installed: 32:bind-9.8.2-0.30.rc1.el6_6.3.x86_64
Aug 01 17:08:59 Updated: 32:bind-9.8.2-0.37.rc1.el6_7.2.x86_64
Sep 09 13:33:05 Updated: 32:bind-9.8.2-0.37.rc1.el6_7.4.x86_64

I installed first the new Linux system at 1st of June.
Then I copied over from the old Tru64 UNIX system all the zone files (including the very old named.ca):

Output of the "ls -ltc /var/named/named.ca" for the inode change time:

-rw-r--r--. 1 root named 2516 Jun  1 08:38 /var/named/named.ca

The copy has been done 7 minutes later than the installation of the package.
Since than there was two "bind" package update executed. The old file was not touched via the upgrade. That may be fine, since the file is locally customized and so it is protected. But the real problem is that there is no /var/named/named.ca.rpmnew created at the time of upgrade! So I assumed that my locally customized file is coming with the package.

Steps to reproduce the problem:

1. Install an earlier version of "bind" rpm package.
2. Modify the /var/named/named.ca
3. Upgrade the "bind" rpm package.

Symptom:

No /var/named/named.ca.rpmnew created

Comment 6 Tomáš Hozza 2015-10-02 11:25:34 UTC
(In reply to debugitu from comment #5)
> The copy has been done 7 minutes later than the installation of the package.
> Since than there was two "bind" package update executed. The old file was
> not touched via the upgrade. That may be fine, since the file is locally
> customized and so it is protected. But the real problem is that there is no
> /var/named/named.ca.rpmnew created at the time of upgrade! So I assumed that
> my locally customized file is coming with the package.

As I stated in comment #4, the file is NOT marked as "noreplace" therefore it should be ALWAYS replace and the modified file should be backed up with ".rpmsave" suffix. So there will be no .rpmnew file.

> Steps to reproduce the problem:
> 
> 1. Install an earlier version of "bind" rpm package.
> 2. Modify the /var/named/named.ca
> 3. Upgrade the "bind" rpm package.
> 
> Symptom:
> 
> No /var/named/named.ca.rpmnew created

I'll try to reproduce it and find the cause...

Comment 7 debugitu 2015-10-05 07:28:20 UTC
(In reply to Tomas Hozza from comment #6)
> I'll try to reproduce it and find the cause...

Here is the output of my test (I just did it again on a test system):

[root@mail2 ~]# yum -q -y --disablerepo=updates install bind
[root@mail2 ~]# rpm -q bind
bind-9.8.2-0.37.rc1.el6.x86_64
[root@mail2 ~]# ls -l /var/named/named.ca*
-rw-r-----. 1 root named 2075 Apr 23  2014 /var/named/named.ca
[root@mail2 ~]# echo >> /var/named/named.ca
[root@mail2 ~]# ls -l /var/named/named.ca*
-rw-r-----. 1 root named 2076 Oct  5 09:21 /var/named/named.ca
[root@mail2 ~]# yum -q -y upgrade bind
[root@mail2 ~]# rpm -q bind
bind-9.8.2-0.37.rc1.el6_7.4.x86_64
[root@mail2 ~]# ls -l /var/named/named.ca*
-rw-r-----. 1 root named 2076 Oct  5 09:21 /var/named/named.ca
[root@mail2 ~]# 

No .rpmnew, no .rpmsave (asterisk is there in the argument of "ls" for glob replacement).

Comment 8 debugitu 2015-10-05 10:05:50 UTC
Sorry, I forgot the clean-up that the test could be redone:

[root@mail2 ~]# yum -q -y erase bind bind-libs
warning: /var/named/named.ca saved as /var/named/named.ca.rpmsave
[root@mail2 ~]# rm -rvf /var/named/
removed `/var/named/named.ca.rpmsave'
removed directory: `/var/named'
[root@mail2 ~]#

Comment 9 debugitu 2015-12-04 14:08:01 UTC
I just started to receive the following messages in syslog:

Dec  2 09:06:35 crehelf named[2783]: checkhints: h.root-servers.net/A (198.97.190.53) missing from hints
Dec  2 09:06:35 crehelf named[2783]: checkhints: h.root-servers.net/A (128.63.2.53) extra record in hints
Dec  2 09:06:35 crehelf named[2783]: checkhints: h.root-servers.net/AAAA (2001:500:1::53) missing from hints
Dec  2 09:06:35 crehelf named[2783]: checkhints: h.root-servers.net/AAAA (2001:500:1::803f:235) extra record in hints

having /var/named/named.ca version of:
-rw-r-----. 1 root named 2075 Apr 23  2014 named.ca
# sha1sum named.ca
6a38643c16bf0a7251278481b24a704742bb67b5  named.ca

This is related to:
https://www.isc.org/blogs/h-root-will-change-its-addresses-on-1-december-2015-what-does-this-mean-for-you/

I think that the bind-9 distribution of isc.org does not contain named.ca or root.hint file. It must be added at the time of Fedora/RedHat packaging.

The command "dig +norec NS . @a.root-servers.net > named.ca" just works fine,
but is it possible to have the original hint file in the package from
http://www.iana.org/domains/root/files ? It looks much nicer.
They even have a signature for verification:
http://www.internic.net/domain/named.root.sig

Comment 10 Tomáš Hozza 2015-12-04 15:21:04 UTC
The hints file is part of the package and always was in RHEL-6+ and Fedora.

Comment 11 debugitu 2015-12-04 15:56:57 UTC
Sure, the rpm packages contain the hints file.

I just downloaded the real original source from ISC:

ftp://ftp.isc.org/isc/bind9/9.8.2/bind-9.8.2.tar.gz

Other than ./lib/dns/rootns.c there is no reference to the actual root servers. (No explicit root hint zone file)

What my question is, how the named.ca file found its way into the rpm packages?

Comment 12 Tomáš Hozza 2016-01-11 14:10:12 UTC
(In reply to debugitu from comment #11)
> What my question is, how the named.ca file found its way into the rpm
> packages?

Unfortunately I don't know. It was added in Fedora in 2006 by this commit http://pkgs.fedoraproject.org/cgit/rpms/bind.git/commit/?id=0cd02aa18f76fca3a52a81df26804036142b80f2

This is the best information I can find. However given that the root server IP addresses are included only in source, from RHEL point of view it makes sense to ship the hits file. The reason is that the version of BIND in RHEL-6 is old and IP addresses of root servers changed over the time. We will not update BIND in RHEL-6 to the latest version (which would include the new IPs in the code), however we can update just the hints file. This gives us more flexibility and also makes sure that users will have more current information. Anyway BIND does priming on startup, so after startup, the IPs of root servers are always current.


I tested the updating of BIND and can say, that what you are observing is actually expected behavior, based on [1]. The thing is, that RPM will write the .rpmsave file only in case it changed in the new RPM, compared to the previously installed RPM. If it didn't, it will just leave there the user-modified version. The logic behind this is that, since the configuration file in RPM didn't change, the changes made by user should still work, therefore is the file kept as is.

If needed, you can always check the changed files by running 'rpm --verify bind'

[1] http://www-uxsup.csx.cam.ac.uk/~jw35/docs/rpm_config.html


I'll update the named.ca in the BIND package to the latest version from http://www.iana.org/domains/root/files

Comment 18 errata-xmlrpc 2016-05-10 20:28:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0784.html