Hi Paul, I agree that it would be foolish to change 4034/4035 without understanding the implications of doing so (e.g. breaking validators).
However, it's possible that it would be a fairly minor semantic change, e.g. if signing records with an owner name below a zone cut was optional and if validator code paths were not much affected (they could either validate when they saw the RRSIG or ignore the RRSIG, either way it's possible that things would not break). Before the idea of using RRSIGs to sign records that are currently specified not to be signed is thrown away, is it perhaps worth exploring it a little more deeply? Joe > On Aug 1, 2018, at 12:14, Paul Hoffman <[email protected]> wrote: > > Maybe changing RFC 4034 and RFC 4035 to have RRSIGs over non-authoritative > data is not the right way to go. It could break some current validators, and > it would be hard to let zones sign some but not all of the non-authoritative > data. (For example, I could imagine a zone owner wanting to sign the child NS > records but not the glue records.) > > Instead, of the WG wants this functionality, it might be cleaner to create a > new record that acts like RRSIG but is used only on non-authoritative data. > Think of it as NONAUTH-RRSIG. We would need to define the new RRtype (with a > lot of pointers to RFC 4034), how it is used to sign (with a lot of pointers > to RFC 4035), how authoritative servers would include those records in > responses, and how validators would handle the records (this would probably > be the trickiest part). > > This would lead to a cleaner upgrade path both for authoritative servers and > resolvers, and thus maybe make it more palatable to the current DNSSEC-using > population. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
