* Stephane Bortzmeyer wrote:
On Fri, Feb 16, 2007 at 10:29:41AM +0000, Lutz Donnerhacke <lutz@iks-jena.de> wrote
Of course, it's a slightly modified bind. What's wrong with using the NSEC data for negative caching?
RFC 4035, "4.5. Response Caching"
In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace.
I do not block new authoritative data, because I listen to NOTIFY on 232.<crc24-of-canonical-soa's-name> and ff35:8000:<crc32-...>. If authoritive server sends a NOTIFY to this group and the zone data is pruned on the listening resolver. Originally the multicast hack was done to update (hidden) secondaries behind firewalls. Using multicast there is no need for peeling holes into the firewall.