rrcache: don't store NSEC3 and their signatures

They would end up cached by their hashed owner names and then even returned if explicitly queried by that hashed name, which is not correct: https://tools.ietf.org/html/rfc4035#section-2.3

Internally we only need these for non-existence proofs, and those are stored in pktcache instead.

You need to be able to return them as a proof for non-existence for DNSSEC aware clients. So they need to be cached.

@ondrej: as I mentioned, negative answers are cached as whole packets and separately, by the pktcache module.

Ok, then. We probably should have deckard tests for both providing negative answers and not leaking NSEC(3) records.

I didn't touch NSEC (yet). Their owner-name isn't hashed so I don't think you could get any information not easily available otherwise, but there's probably not much sense in it anyway, as some domain names may hold two distinct NSEC RRsets (parent+child).

mentioned in commit 1b1decde

merged