> On 27 Jul 2018, at 12:15 pm, Davey Song <songlinj...@gmail.com> wrote: > > > - It was not really clear exactly what kind of problem this digest > tries to solve, especially given that the primarily intended usage > is for the root zone, which is DNSSEC-signed with NSEC. > > It puzzled me as well. > > It is said in the document that diffferent from DNSSEC (and NSEC), the zone > digest is for the intergirty of unsigned NS and Glue of the zone. As I asked > in IETF102: why unsigned NS and glue is worth of protecting by introducing a > new RRtype, addtional complexity of degesting and validation. Is it really > necessary for local resolver(or local-root) aware the integity of NS and > glue? any technical problems if the NS RR and glue are modified locally?
The problem is that when you have every recursive server in the world with a copy of the root zone from “random places” you want to reduce the possible error spaces into manageable chunks when things go wrong which they will. Being able to verify the contents of the root zone you have are not modified helps. It also prevents privacy leaks to parties other than the owners of the delegated zones by ensuring the NS and glue addresses records have not been changed. QNAME minimisation helps with the residual privacy leaks by reducing it to the child zone. > As to the discussion of re-inventing the wheels, I mean If the problem > statement of zone digest is not a significance of worthing a heavey inband > approach, an lightweight and existing outband approch may be a first option > to consider.. > > -Davey > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
