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.

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?

same here on both f11 and f12 hosts. ;(

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.

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?

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.

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.)

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.

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.

(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?

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.

(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.

Will the bind/bind-chroot package also need to be updated to accommodate any of
the changes to dnssec-conf?

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.

cross-reference:
 I attached to bug 505754 a minimal patch that prevent the most common
 cases of /etc/named.conf mutilation.

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.

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

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.

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

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

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.

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

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

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

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.

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.

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 :/

(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.

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).

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).

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.

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"?

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.

(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.

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.

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?

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.

(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

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.