It still happens quite a lot that auths produce wrong NSEC(3) records. If these records end up in the aggressive NSEC cache and are used to deny other name/qtypes it can be very useful to know which query lead to the original insertion and the consequential denial of another query. For NSEC entries it is often possible to guess, but for NSEC3 it is much harder. From experience it seems NSEC3 denials are more often wrong than NSEC ones.
So it would be nice to know details of the query that lead to an entry into the aggressive cache being inserted. As an extra bonus we might consider adding such info into an EDE when producing a denial for another name (does this reveal too much?). But at least rec_control dump-cache should show the info.
Suggested by @qvr on IRC but already independently pondered by mysef and @rgacogne some time ago I believe.
It still happens quite a lot that auths produce wrong NSEC(3) records. If these records end up in the aggressive NSEC cache and are used to deny other name/qtypes it can be very useful to know which query lead to the original insertion and the consequential denial of another query. For NSEC entries it is often possible to guess, but for NSEC3 it is much harder. From experience it seems NSEC3 denials are more often wrong than NSEC ones.
So it would be nice to know details of the query that lead to an entry into the aggressive cache being inserted. As an extra bonus we might consider adding such info into an EDE when producing a denial for another name (does this reveal too much?). But at least
rec_control dump-cacheshould show the info.Suggested by @qvr on IRC but already independently pondered by mysef and @rgacogne some time ago I believe.