+++ This bug was initially created as a clone of Bug #556366 +++ Description of problem: In bug 556365 I reported how as the dnssec reverse zone keys were not up to date, bind was generating a lot of unwanted messages. To copy a bit from that report: ----- 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. It seems bind forgets 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. ----- Version: bind-9.6.1-13.P2.fc12.x86_64 I don't really understand how DNSSEC works, so please excuse me if I'm wrong, but this is what I think is happening: - bind sends a DNSKEY request for a particular reverse zone - bind receives a response, but it is signed with a key that bind doesn't know Now, bind shouldn't stop trying after the first response with an unknown key, since otherwise a third party malicious host may be able to forge responses with bad keys so that bind would give up in its search for the DNSKEY. However, is there a point at which, after a number of responses with unknown keys (and not a single response for that zone with a known key), bind should decide to wait a period of time before trying that zone again? I hope that makes some amount of sense.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, the named demon, configured as recursive nameserver, could have continuously asked for missing DNSKEY keys which could have caused a Distributed Denial of Service on authoritative servers for a particular domain. With this update, when DNSKEY of a domain cannot be fetched, the named demon caches it and asks again.
=> VERIFIED
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0032.html