Bug 1267991
Summary: | some entries in named.ca are outdated | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | debugitu <RedHat-Bug> |
Component: | bind | Assignee: | Tomáš Hozza <thozza> |
Status: | CLOSED ERRATA | QA Contact: | qe-baseos-daemons |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 6.8 | CC: | ovasik, psklenar |
Target Milestone: | rc | Keywords: | 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 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. (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. 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. (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 (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... (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). 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 ~]# 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 The hints file is part of the package and always was in RHEL-6+ and Fedora. 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? (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 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 |