Bug 556365 - dnssec keys not up-to-date, makes bind send thousands of 'no valid KEY' messages to syslog
Summary: dnssec keys not up-to-date, makes bind send thousands of 'no valid KEY' messa...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dnssec-conf
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Paul Wouters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-18 04:44 UTC by Kieran Clancy
Modified: 2010-04-07 17:43 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-04-07 17:43:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Kieran Clancy 2010-01-18 04:44:05 UTC
Description of problem:
I noticed that bind had begun to generate thousands of messages like this in /var/log/messages:
Jan 17 20:07:47 localhost named[1521]: no valid KEY resolving '80.in-addr.arpa/DNSKEY/IN': 202.12.29.59#53

In fact, in little over 24 hours I had 240,000 of these messages, all for different reverse zones, and bind was chewing through a surprising amount of bandwidth. This was prompted solely by the occasional reverse lookup by sshd.

Now, I think there's probably a bug in bind in that it seems to forget it has no valid key and just repeatedly tries to request DNSKEY's for the same reverse zones from the same servers. For example, for just the 80.in-addr zone, in 24 hours bind retried the DNSKEY query almost 2000 times for each of 9 DNS servers (nearly 18000 retries in total)! Multiply this by the number of reverse zones with keys and this becomes fairly annoying. I'm almost surprised that I didn't receive a complaint from my ISP. (I think I will file a separate bug about this.)

Anyway, I was able to resolve this by upgrading to dnssec-conf 1.22 from rawhide. I don't really understand the DNSSEC key infrastructure, but obviously the updated reverse zone keys are important. Please consider updating it in earlier Fedora releases, particularly if other users are affected.

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

Comment 1 Mike 2010-02-01 12:23:25 UTC
Fedora 11 is affected too.

Temporary solution might be to disable "dnssec-enable" and "dnssec-validation" in "named.conf" file.

I wonder if this problem is related to http://www.root-dnssec.org/

: January, 2010: The first root server begins serving the signed root in
: the form of the DURZ (deliberately unvalidatable root zone). The DURZ
: contains unusable keys in place of the root KSK and ZSK to prevent these
: keys being used for validation.

Comment 2 Kieran Clancy 2010-02-01 14:12:22 UTC
I'm not sure that disabling DNSSEC is required to fix this. For me, just upgrading to dnssec-conf-1.22 (which has new keys) was enough.

# yum --enablerepo='rawhide' update dnssec-conf

Comment 3 Chris Adams 2010-02-05 13:59:00 UTC
The problem appears to be a RIPE NCC key roll-over event on 2009-12-16.  See:

https://lists.dns-oarc.net/pipermail/dns-operations/2010-February/004931.html

This package needs an immediate update to fix this problem.

If Fedora is going to make dnssec-conf a mandatory prerequisite for BIND, then it is up to Fedora to keep this package absolutely current, or Fedora BIND configs will be broken regularly.

Comment 4 Paul Wouters 2010-04-07 17:43:29 UTC
This has been fixed in updates to dnssec-conf in EL-5, devel, F-11, F-12 and F-13 a while ago.


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