An additional point about this: the case where the cheese shop solution works 
is really the case where large service provider DNS caches do the aggressive 
caching.   In this case we can get the same benefit without DNSSEC by simply 
keeping a complete copy of the root zone at the DNS cache.   This adds a small 
operational complexity in keeping that copy up to date, but eliminates the 
implementation complexity of the cheese shop or fullly aggressive NSEC cache.

So why isn't that a better way to address this problem?
________________________________________
From: DNSOP [[email protected]] on behalf of Ted Lemon 
[[email protected]]
Sent: Thursday, February 25, 2016 13:18
To: Warren Kumari; dnsop
Subject: Re: [DNSOP] Updated cheese-shop: cost/benefit analysis, please?

I'm sorry to be a sticky wicket here, but I have to ask: have you thought about 
what a guaranteed-correct implementation of this would look like?   I think you 
need to actually do that analysis before we proceed with this.   As best I 
understand it, getting this right is not trivial, and getting it wrong would be 
harmful.   While it clearly would help in the context of widespread adoption of 
DNSSEC, I'm not convinced that the security risk of the added complexity would 
be compensated for by an actual reduction in woe at the root.

I would like to see the WG seriously analyze this problem before considering 
proceeding with either this proposal or the other.
________________________________________
From: DNSOP [[email protected]] on behalf of Warren Kumari 
[[email protected]]
Sent: Wednesday, February 24, 2016 23:58
To: dnsop
Subject: [DNSOP] Updated cheese-shop.

Dear DNSOP,

We have recently updated "Believing NSEC records in the DNS root" 
(https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01).

This incorporates some comments, but also does a better job of explaining the 
technique, what the benefits are, and why we are only handling the special case 
of the root zone.
We believe that, in this limited use-case the suggestions in Section 4.5 of 
RFC4035 are not as relevant. We also believe that the NSEC case (and no 
wildcards :-)) is simpler to solve than the NSEC3 case.

For these reasons we think that it is worth pursuing this in parallel with 
Fujiwara-san's "Aggressive use of NSEC/NSEC3" document.
cheese-shop does not conflict with "Aggressive use...",  rather it complements 
it, and can demonstrate the technique (in this restricted use case).

We welcome any feedback, including tomatoes, howls of derisive laughter, etc.

W

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to