Especially with the prevalence of passive DNS services, I believe that publishing something in the DNS makes it "public" - sure, you can hide some things behind split-DNS, but putting `super-skrit-key.exmaple.com IN 600 TXT "Hunter3"` is guaranteed to end poorly.
NSEC5 has some very cute tricks, but I don't agree with the premise that it solves a real world problem. W On Fri, Mar 10, 2017 at 12:26 PM, Evan Hunt <e...@isc.org> wrote: > On Fri, Mar 10, 2017 at 03:16:05PM +0000, Woodworth, John R wrote: >> > Is there a community of zone admins who want this so much that they >> > won't start signing until it exists? >> >> With the draft's aliasing of algorithms, why couldn't (wouldn't) a zone >> at least experimenting with this be able to provide 2 sets of keys, >> one pre-NSEC5 and the other NSEC5 and forward? > > I think the question pertains to whether it's worthwhile for us to adopt > this. > > If there are operators who need NSEC5 badly enough that they won't deploy > DNSSEC until it exists, then it makes sense for the working group to take > it on. If it turns out, however, that everyone who might like NSEC5 is also > reasonably satisified with NSEC3, then we'd be wasting time on an academic > exercise. It's clever, but it's only necessary if we broadly agree that > NSEC3 isn't meeting our needs. I'm not sold on that point. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
