Bug 563232 - Update to dnssec-conf-1.21-7.fc12.noarch causes named to quit
Update to dnssec-conf-1.21-7.fc12.noarch causes named to quit
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnssec-conf (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Paul Wouters
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: dnssecmods
  Show dependency treegraph
 
Reported: 2010-02-09 11:11 EST by Alan Schmidt
Modified: 2010-03-02 19:19 EST (History)
19 users (show)

See Also:
Fixed In Version: 1.21-8.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-02 19:19:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alan Schmidt 2010-02-09 11:11:57 EST
Description of problem:
I did an update this morning, which included dnssec-conf-1.21-7.fc12.noarch.

However, it was missing all files in the

   /etc/pki/dnssec-keys/production/reverse/

...directory, items from which are enumerated in /etc/named.dnssec.keys, so named quit.

Version-Release number of selected component (if applicable):
dnssec-conf-1.21-7.fc12.noarch

How reproducible:
100% of the 1 time I updated.

Steps to Reproduce:
1. Update to dnssec-conf-1.21-7.fc12.noarch.
2. Boom
  
Actual results:
Boom

Expected results:
No boom.

Additional info:
If you excise the missing items from /etc/named.dnssec.keys, named starts up fine.
Comment 1 Leszek Matok 2010-02-09 12:44:52 EST
Same problem here. I've commented out include "/etc/named.dnssec.keys"; at all, as I don't use dnssec anyhow (just few days ago I had to disable it for lookups to work, probably ISP's fault). This deserves high priority.
Comment 2 Matt Castelein 2010-02-09 12:45:46 EST
Same problem here, although I do not use dnssec, since it's caused me nothing but trouble.. I would appreciate it if the package update did not go stepping all over my configuration files without asking me, and causing named to go down in flames.  What ever happened to using .rpmnew files?
Comment 3 Kevin Fenzi 2010-02-09 12:47:41 EST
same here on both f11 and f12 hosts. ;(
Comment 4 Wolfgang Rupprecht 2010-02-09 13:07:12 EST
Same problem here.  As an added thrill, the *directory* was mode 644.  

# ll /etc/pki/dnssec-keys/production
total 36
-rw-r--r--. 1 root root 1678 2010-02-05 12:30 bg.conf
-rw-r--r--. 1 root root  315 2010-02-05 12:30 br.conf
-rw-r--r--. 1 root root  433 2010-02-05 12:30 cz.conf
-rw-r--r--. 1 root root  449 2010-02-05 12:30 gov.conf
-rw-r--r--. 1 root root  474 2010-02-05 12:30 museum.conf
-rw-r--r--. 1 root root  854 2010-02-05 12:30 org.conf
-rw-r--r--. 1 root root  444 2010-02-05 12:30 pr.conf
drw-r--r--. 2 root root 4096 2010-02-09 09:36 reverse
-rw-r--r--. 1 root root 1328 2010-02-05 12:30 se.conf

I can't seem to find the rpm's version of /etc/named.conf.  Doesn't it normally appear as /etc/named.conf.rpmnew if the original file was edited (which mine was)?  I'd really like to merge my file with the new rpm file.

BTW. I'm glad that someone is maintaining DNSSEC for fedora.  Thanks! It saves me lots of trouble digging up all the keys by hand.  It is unfortunate that the yum updates are so fragile.
Comment 5 Paul Wouters 2010-02-09 13:32:15 EST
Hmm, the named.dnssec.keys is in /etc/ on those systems? On mine it is in /etc/pki/dnssec-keys/ which is the one where we remove the keys form.

I'll do another update checking for that location too I guess. Strange.

Adam: dd you modify that location at some point for bind?
Comment 6 Kevin Fenzi 2010-02-09 13:36:14 EST
FWIW, the output here is: 

# /etc/init.d/named restart
ERROR: syntax check for named-checkconf /etc/named.conf failed:/etc/named.dnssec.keys:8: open: /etc/pki/dnssec-keys/production/reverse/0.4.1.0.0.2.ip6.arpa.conf: file not found
Stopping named:                                            [  OK  ]
Starting named:
Error in named configuration:
/etc/named.dnssec.keys:8: open: /etc/pki/dnssec-keys/production/reverse/0.4.1.0.0.2.ip6.arpa.conf: file not found
                                                           [FAILED]

and /etc/pki/dnssec-keys/productions/reverse/ is the directory with no contents.
Comment 7 Richard Fearn 2010-02-09 15:00:10 EST
Got the same problem on my F11 server today. When I installed F11 on 2009-06-13, these packages were installed:

  bind-9.6.1-0.3.b1.fc11.x86_64
  dnssec-conf-1.20-2.fc11.noarch

The BIND install caused dnssec-configure to be run, and in dnssec-conf 1.20 the path was hard-coded as /etc/named.dnssec.keys.

dnssec-conf 1.21 started using /etc/pki/dnssec-keys/named.dnssec.keys - but the old /etc/named.dnssec.keys wasn't moved/copied into the new location during the 1.20 → 1.21 upgrade. So anyone installing F11 before approximately 2009-06-18 (when the 1.21-1 update was pushed to stable) would have /etc/named.dnssec.keys instead of /etc/pki/dnssec-keys/named.dnssec.keys.

To fix this I moved /etc/named.dnssec.keys into /etc/pki/dnssec-keys, and ran the sed command from the dnssec-conf 1.21-3 spec. This got rid of all the 'reverse' lines.

I did notice one thing, however: my named.dnssec.keys file doesn't include production/org.conf (which was added in 1.21).

Perhaps instead of modifying the file during a dnssec-conf upgrade, it just needs to be completely regenerated? (dnssec-conf 1.21-4 will update /etc/named.dnssec.keys, but it still won't include org.conf.)
Comment 8 Paul Wouters 2010-02-09 15:23:39 EST
This bug seems to affect people who installed it on F-10 before March 19 and upgraded their systems since to F-10/F-11/F-12/

I am building new dnssec-conf packages that notice this old location as well.
Comment 9 Paul Wouters 2010-02-09 15:25:45 EST
Richard: All trust anchors will be removed shortly and only the DLV will be used as a trust anchor repository (until the root is signed in July)

I'll double check the hardcoded path in 1.20. The variable was changed in 1.18 > 1.19 for the new location.
Comment 10 Matt Castelein 2010-02-09 15:33:07 EST
(In reply to comment #8)
> This bug seems to affect people who installed it on F-10 before March 19 and
> upgraded their systems since to F-10/F-11/F-12/
> 
> I am building new dnssec-conf packages that notice this old location as well.    

What about named.conf getting stepped on and "dnssec-enable no;" and "dnssec-validation no;" getting changed to "yes" every time I do an update?  What's causing that?
Comment 11 Paul Wouters 2010-02-09 15:43:55 EST
Richard is right, though basedir= was changed earlier, the /etc/pki/dnssec-keys/named.dnssec.keys location did not get used until 1.21. So everyone who initially used a version < 1.21 is running into this issue. This means F-10 and F-11 installs done from ISO or those isntalled with yum before June 14 2009 suffer this problem.
Comment 12 Paul Wouters 2010-02-09 15:45:50 EST
(In reply to comment #10)

> What about named.conf getting stepped on and "dnssec-enable no;" and
> "dnssec-validation no;" getting changed to "yes" every time I do an update? 
> What's causing that?    

That should only happen if your /etc/sysconfig/dnssec file contains "yes" for those questions.
Comment 13 Mike C 2010-02-09 15:46:10 EST
Will the bind/bind-chroot package also need to be updated to accommodate any of
the changes to dnssec-conf?
Comment 14 Paul Wouters 2010-02-09 15:56:47 EST
Mike: not this round. But when we further phase out bind, it will required an update to the bind initscript to no longer look for /etc/sysconfig/dnssec and dnssec-configure.
Comment 15 Oron Peled 2010-02-09 17:23:12 EST
cross-reference:
 I attached to bug 505754 a minimal patch that prevent the most common
 cases of /etc/named.conf mutilation.
Comment 16 Nerijus Baliūnas 2010-02-09 18:18:27 EST
My named.conf was changed like this:

options {
        directory "/var/named";
        dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        forwarders {
                84.32.38.10;
                84.32.38.11;
        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside . trust-anchor dlv.isc.org.;
};

Now I get:
Starting named: 
Error in named configuration:
/etc/named.conf:12: expected IP address near 'dnssec-enable'

I had to move closing } before dnssec-enable yes and now it starts ok.
Comment 17 Fedora Update System 2010-02-09 18:56:10 EST
dnssec-conf-1.21-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/dnssec-conf-1.21-4.fc11
Comment 18 D. Wagner 2010-02-10 02:50:25 EST
I'm a bit puzzled why this is marked as "Priority: low", when it breaks DNS on every system that's been upgraded from F10/F11 and that is running its own nameserver.  For me, this caused puzzling and hard-to-diagnose poor performance in my browser, so I found this pretty annoying.

I didn't see anyone explain clearly in the comments how to work around this bug, so for the onlookers I'll explain explicitly for anyone else who gets hit by this how to work around the bug, until it gets fixed.  Look for a line like

include "/etc/named.dnssec.keys";

in /etc/named.conf.  Edit /etc/named.conf to delete that line.  Or, you can prepend a "// " in front of that line, so it looks like this:

// include "/etc/named.dnssec.keys";

Make sure that /etc/named.conf contains a line like the following elsewhere:

include "/etc/pki/dnssec-keys//named.dnssec.keys";

Then run "service named restart".  That should do it, if you're lucky.
Comment 19 Fedora Update System 2010-02-10 09:13:35 EST
dnssec-conf-1.21-8.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/dnssec-conf-1.21-8.fc12
Comment 20 Fedora Update System 2010-02-10 09:27:41 EST
dnssec-conf-1.21-8.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/dnssec-conf-1.21-8.el5
Comment 21 Paul W. Frields 2010-02-10 09:41:24 EST
In response to comment #18:

First, the priority flag in this Bugzilla instance is not meaningful.  Put more stock in the fact that the maintainer has already taken on the bug as ASSIGNED and has a fix waiting for the updates-testing repository, as seen in comment #17.

Second, please take the time to check our new, fixed package update.  The package hasn't yet been pushed to the official updates-testing repository.  To test it right now, go to one of these pages:

Fedora 11: http://koji.fedoraproject.org/koji/buildinfo?buildID=155214
Fedora 12: http://koji.fedoraproject.org/koji/buildinfo?buildID=155213

Look for the downloadable package under "noarch."  You should be able to simply click the package and PackageKit will offer to install/update it for you.  Once updated, if the package works, visit the update page for the package and let us know that it worked for you:

Fedora 11: https://admin.fedoraproject.org/updates/dnssec-conf-1.21-4.fc11
Fedora 12: https://admin.fedoraproject.org/updates/dnssec-conf-1.21-8.fc12

The sooner these updates receive testing and positive karma, the sooner we can push them with assurance to the stable updates repository.  Thanks for participating and helping to fix this problem for Fedora users.
Comment 22 Fedora Update System 2010-02-10 20:32:26 EST
dnssec-conf-1.21-8.el5 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dnssec-conf'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2010-0199
Comment 23 Fedora Update System 2010-02-11 09:34:21 EST
dnssec-conf-1.21-4.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dnssec-conf'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-1696
Comment 24 Fedora Update System 2010-02-11 09:51:26 EST
dnssec-conf-1.21-8.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dnssec-conf'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1748
Comment 25 Alan Schmidt 2010-02-12 12:40:38 EST
Still hasn't hit my mirror (I'm looking in updates-testing).

BUT I downloaded the package from Koji using the link in Comment 21, restored /etc/named.dnssec.keys to the state it was in when named broke, and installed the package, and /etc/named.dnssec.keys was duly cleansed (and named remained happy when restarted).

So I'll say the fix worksforme.

Thanks.
Comment 26 Fedora Update System 2010-02-12 19:39:31 EST
dnssec-conf-1.21-8.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 27 Edek Pienkowski 2010-02-13 15:16:39 EST
dnssec-conf-1.21-4.fc11.noarch, pulled from updates-testing has fixed reverse lookups, which is great.

However it messed up /etc/named.conf and named refused to start, related in a way to comment #10. The commented out three lines fix the problem of startup:

options {
	querylog yes;

allow-query {
	localhost;
	10.xx.xx.xx;
        192.168.xx.xxx/24;
//	dnssec-enable yes;
//	dnssec-validation yes;
//	dnssec-lookaside . trust-anchor dlv.isc.org.;
};
allow-transfer {
	10.xx.xxx.xxx;
};
...and so on, later dnssec is enabled and I think some secure lookups are attempted, but I don't know how this works really :/
Comment 28 Matt Castelein 2010-02-13 17:43:03 EST
(In reply to comment #27)
> However it messed up /etc/named.conf and named refused to start, related in a
> way to comment #10. The commented out three lines fix the problem of startup:

I think you need to also edit /etc/sysconfig/dnssec.  That is what I forgot to do. (see comment 12) The fixes for this bug are one thing, but your named.conf getting changed is probably this other file telling it to make the change.
Comment 29 Edek Pienkowski 2010-02-13 18:00:06 EST
Thanks; I also noticed that I don't know which version is which, the f11 and f12 seem to have different numberings.

However, it seems that this problem is not with switching 'no' to 'yes'; the error message below suggests that these tokens are not expected at this place of config file at all (the machine booted before update and bind was working and was not touched otherwise than by upgrade of dnssec-conf).

Starting named: 
Error in named configuration:
/etc/named.conf:16: missing ';' before 'yes'
/etc/named.conf:17: missing ';' before 'yes'
/etc/named.conf:18: missing ';' before '.'
/etc/named.conf:18: missing ';' before 'trust-anchor'
/etc/named.conf:18: missing ';' before 'dlv.isc.org.'

(and line 16 is the one with dnssec-enable in my comment 27 above).
Comment 30 Oron Peled 2010-02-14 03:45:28 EST
Just tested dnssec-conf-1.21-8.fc12.noarch
1. The default /etc/sysconfig/dnssec still has DNSSEC="on" by default.
2. So by default it still messed my /etc/named.conf
3. It even has the guts to hit you if you try to turn it off:
   a. Manually fixed my /etc/named.conf
   b. Than set DNSSEC="off" in /etc/sysconfig/dnssec
   c. A restart overwrote my named.conf again
   Yes, the stupid /etc/init.d/named, now checks if /etc/sysconfig/dnssec
   is newer than /etc/named.conf and runs the @#@$$@ dnssec-configure
4. Do you think that closing this ticket would magically solve the problem?

C'mon people, get your act together:
 * Ship it with DNSSEC="off" by default, at least until you found how
   not to clobber our /etc/named.conf
 * Try to ditch the half-baked /usr/sbin/dnssec-configure script. Using
   proper includes in the default /etc/named.conf can achieve this
   (see my comment 17 in bug 548851 for a quick howto)
 * As a minimum, make dnssec-configure count braces properly (I attached
   to bug 548851 a minimal patch to do just this).
Comment 31 Fedora Update System 2010-02-16 08:11:48 EST
dnssec-conf-1.21-4.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 32 Matt Castelein 2010-02-17 14:38:29 EST
restorecon doesn't like the contexts on the dnssec files, for example:

restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/reverse context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0
restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/pr.conf context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0
restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/org.conf context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0
restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/se.conf context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0
restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/museum.conf context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0
restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/gov.conf context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0

Shouldn't they stay "cert_t"?
Comment 33 Bill McGonigle 2010-02-17 15:45:59 EST
I took an update today to dnssec-conf-1.21-4.fc11.noarch and got another named restart failure.

There appears to be three problems.

1) the brace matching is still broken.  Here's what it did:

--- /etc/named.conf.bak	2010-02-17 08:07:22.999497000 -0500
+++ /tmp/named.conf	2010-02-17 08:04:31.436130604 -0500
@@ -21,7 +21,9 @@
 #               127.0.0.1;
                 xx.56.102.20;
                 xx.56.100.20;
-		};
+	dnssec-enable no;
+	dnssec-validation no;
+};
 	dnssec-enable yes;
 	dnssec-validation yes;
 	dnssec-lookaside . trust-anchor dlv.isc.org.;
@@ -404,4 +406,3 @@
 
 
 include "/etc/pki/dnssec-keys//named.dnssec.keys";
-include "/etc/pki/dnssec-keys//dlv/dlv.isc.org.conf";

this really needs to be fixed or reverted - shipping a known broken brace-matcher is guaranteed to break systems.  Oron has a patch.  This needs to be well-tested before shipping.

2) somehow it clobbered the chroot install of bind.  It looks like it created files in /etc (named.conf, rndc.key were symlinks), didn't modify anything in /var/named/chroot/etc and I needed to manually copy in /etc/pki/dnssec-keys/named.dnssec.keys and /etc/pki/dnssec-keys/dlv.  

Is the script aware of chroot installs?

So, this isn't fixed - this bug should probably be re-opened.
Comment 34 J.H. 2010-02-18 11:23:51 EST
(In reply to comment #33)
I will +1 the re-opening of the bug, it's not fixed, by any stretch of the imagination and this is causing untold problems for those of us running production name servers.
Comment 35 Paul W. Frields 2010-02-18 11:34:08 EST
Reopening this bug isn't as helpful as filing a new bug for each new problem, since these are different problems than the original one.  (An update that breaks things in a new way gets a new bug.)  Thanks in advance for filing these bugs.
Comment 36 Oron Peled 2010-02-18 15:31:12 EST
Refering to comment 33, 34, 35:
1. The braces problem is covered by an already open bug 505754
2. There are enough bug reports covering this from every possible angle:
  https://bugzilla.redhat.com/buglist.cgi?component=dnssec-conf&product=Fedora
   More reports will just create more work for bug-zappers to sort and close
   the dupes.
3. A week ago I attached a 3 line patch that solve the braces problem
   to bug 505754. Didn't see any response -- does this break other test cases?
Comment 37 Bill McGonigle 2010-02-18 16:51:49 EST
Yes, you're right Paul, this bug shouldn't be a dumping ground for all the related problems.

I created bug 566585 to try to organize this a bit and set a few of the outstanding issues around this to depend.  I think most of the unresolved complaints in this bug are fairly represented in the dependencies (though at least one needs a summary edit) except for the chroot one I need to file yet.

Thanks for pointing the way.
Comment 38 Matt Castelein 2010-02-18 17:03:52 EST
(In reply to comment #32)
> restorecon doesn't like the contexts on the dnssec files, for example:
> 
> restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/reverse
> context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0
> restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/pr.conf
> context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0
> restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/org.conf
> context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0
> restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/se.conf
> context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0
> restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/museum.conf
> context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0
> restorecon reset /var/named/chroot/etc/pki/dnssec-keys/production/gov.conf
> context system_u:object_r:cert_t:s0->system_u:object_r:etc_t:s0
> 
> Shouldn't they stay "cert_t"?    

--> Bug 566328
Comment 39 Fedora Update System 2010-03-02 19:19:22 EST
dnssec-conf-1.21-8.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.