> How can one argue with logic like that? (That's a serious question.) I know, it sucks.
> If a protocol requires DNSSEC (which more are these days), then only > systems that have DNSSEC can implement them. That's an operational > choice. Yes. But the case where aggressive NSEC caching works appreciably better than just copying the zone is in the precise case that this draft excludes. So if we are _just_ trying to protect the root, this seems like an overly complex solution. > Or are you saying we should not deploy any protocols that require DNSSEC > (such as DANE) until some group decides that DNSSEC has been widely > enough deployed? Absolutely not. I want us to deploy DNSSEC sooner rather than later. I'm just not convinced that this draft is making an effective use of DNSSEC. I'm willing to be argued around on the topic, but I think this particular problem is adequately addressed by IXFR. >> You query for "l". The authority gives back "!kk->m" and "!@->aa". >> How should you update your state as a resolver? The !ll->mm and >> !kk->m rules are mutually inconsistent. Do you store inconsistent >> data? If asked about "m" do you answer "NXDOMAIN" or go recurse to >> find out the answer? Do you flush any specific NXDOMAIN entries you >> have in your O(1) cache that might be affected (maybe you made them >> for performance reasons), or do changes to the tree only affect new >> resolutions? >RFC 4035 is silent on this situation, I believe. At least, I don't see >it covered in Section 4.5. Maybe this should be an update to RFC 4035. >> IMO, the only "right" thing to do is to drop !ll->mm and keep !kk->m >> since it is more recent. (In this example, we know it is more recent, >> but in the real world how do you know you're not talking to a slave >> that's behind? Are you meant to look at the serial in the SOA RR too >> or signature expiration times?) I'm OK with not flushing things out >> of the O(1) cache. > This sounds right, but I hope someone more familiar with RFC 403[3-5] > would chime in. That wouldn't be me. But if you will refer back to what I originally requested, it was not that we scuttle this document, but that we seriously consider how it would be implemented, in detail, and not just say "cache NSEC" as if how that's done is obvious. And we should do the cost/benefit analysis: is what we are proposing to do better than what we can already do? _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
