On Aug 13, 2021, at 8:40 AM, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> wrote: > I think we can summarize the recent DS-glue-signing drafts as follows: > > * draft-fujiwara-dnsop-delegation-information-signer: One new DS holding a > hash of all the glue records. > * draft-dickson-dnsop-ds-hack: Each new DS holds the hash of one glue RRSet > * draft-schwartz-ds-glue: Each new DS holds one glue record verbatim > > These represent three of the six possible combinations of scope (RR, RRSet, > all glue) and encoding (hash vs. verbatim). All six combinations are > possible, with different tradeoffs.
This concise list also points out a very serious terminology problem that affects this discussion: unsigned NS records in a response are not glue records. Similarly, SVCB records are not glue records. Proposed differentiation between the drafts: * draft-fujiwara-dnsop-delegation-information-signer: One new DS holding a hash of the NS records in the Authority section and all the address records in the Additional section * draft-dickson-dnsop-ds-hack: Each new DS holds the hash of NS records in the Authority section, the A records in the Additional section, and the AAAA records in the Additional section * draft-schwartz-ds-glue: Each new DS holds one record verbatim; the record might not appear in the rest of the response For the DRPIVE use cases, draft-schwartz-ds-glue allows a resolver to discover SVCB records in a response from the parent, even if that parent is not configured to put SVCB records in the Additional section. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
