Bug 572848

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