At Fri, 27 Jul 2018 16:43:44 -0400, Warren Kumari <war...@kumari.net> wrote:
> > Right, so I think one main question is why the root DNS zone case is > > so special that a protocol extension is justified. Personally, I'm > > not yet fully convinced about it through the discussion so far. As > > several other people seem to be persuaded, however, maybe I'm too wary > > just because of my hat of handling eventual "named triggers an > > assertion failure after zone transfer for some bogus zone digest" > > CVEs. But at the same time, if my sense of the wg's take on the "DNS > > camel" discussion is correct, I think we (WG) should require a higher > > level of justification for new protocol features. > > This can, but does not have, to be built into the nameserver itself. True, and I might feel much better if the draft said "name server implementations MUST NOT compute or validate the zone digest in their code":-). More seriously, my concern with the "hat" wouldn't be addressed simply because it can be implemented outside of a name server implementation. In fact, I can see it'll eventually be included in code base I'll have to maintain if it's officially adopted and published. On the other hand, if we're okay with an out-of-band implementation (independently from whether we like it in a name server), then I guess it will become less distinguishable from out-of-band digest approaches. Either way it requires the operators to use an additional tool, and it's therefore more operationally costly, error prone, or easier to be ignored/forgotten. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
