This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[dns-wg] Re: What about the last mile, was: getting DNSSEC deployed
- Previous message (by thread): [dns-wg] Re: What about the last mile, was: getting DNSSEC deployed
- Next message (by thread): [dns-wg] What about the last mile, was: getting DNSSEC deployed
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Lutz Donnerhacke
lutz at iks-jena.de
Fri Feb 16 13:27:13 CET 2007
* Stephane Bortzmeyer wrote: > On Fri, Feb 16, 2007 at 10:29:41AM +0000, > Lutz Donnerhacke <lutz at 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.
- Previous message (by thread): [dns-wg] Re: What about the last mile, was: getting DNSSEC deployed
- Next message (by thread): [dns-wg] What about the last mile, was: getting DNSSEC deployed
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]