DS is the wrong logical point to signal dry run or at least there should also be a key flag otherwise a parent can downgrade the security of zones that don’t want dry run semantics. Additional validation doesn’t require the DS to be present. It is only required to validate the DNSKEY RRset. -- Mark Andrews
> On 17 Jul 2024, at 00:35, Yorgos Thessalonikefs <yor...@nlnetlabs.nl> wrote: > > Dear dnsop, > > We submitted a new version of the "dry-run DNSSEC" draft. > This work was reinitiated now that RFC9567 (DNS Error Reporting) is a > standard document and my plan to incorporate it into Unbound during the > IETF120 Hachathon. > > This update mainly addresses the following feedback we got from IETF114 and > the mailing list: > > ** Burn a bit of the DS Type Digest Algorithms ** > The difference between a dry-run DS and a normal DS will be the Type Digest > Algorithm. There will be a dry-run equivalent value for normal digest > algorithms. The document currently only specifies one dry-run DS Type Digest > Algorithm (for SHA256) but this could change in a later revision to generally > use the most-significant bit for this distinction. > > This results in static lengths for each dry-run DS Type Digest Algorithm. > > > ** NOERROR reports ** > The idea of an upstream to signal that it would like NOERROR reports sent to > the reporting agent (from RFC9567), was going to be included in that RFC but > with no concrete use-case at the time it was left out. > NOERROR reporting is definitely a requirement for this draft since a zone > operator would appreciate a signal that notices the existence of dry-run > validators with no errors to report. > > Currently it is described as an unsolicited EDNS option next to the > Report-Channel but future revisions could treat generation of NOERROR reports > as implied in the presence of dry-run DSes. > > > We are looking forward for any feedback either here on the mailing list or in > person in Vancouver. > > Best regards, > -- Yorgos > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-02.txt > Date: Mon, 08 Jul 2024 13:12:06 -0700 > From: internet-dra...@ietf.org > To: Roy Arends <roy.are...@icann.org>, Willem Toorop <wil...@nlnetlabs.nl>, > Yorgos Thessalonikefs <yor...@nlnetlabs.nl> > > A new version of Internet-Draft draft-yorgos-dnsop-dry-run-dnssec-02.txt has > been successfully submitted by Yorgos Thessalonikefs and posted to the > IETF repository. > > Name: draft-yorgos-dnsop-dry-run-dnssec > Revision: 02 > Title: dry-run DNSSEC > Date: 2024-07-08 > Group: Individual Submission > Pages: 14 > URL: https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-02.txt > Status: https://datatracker.ietf.org/doc/draft-yorgos-dnsop-dry-run-dnssec/ > HTML: > https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-02.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-yorgos-dnsop-dry-run-dnssec-02 > > Abstract: > > This document describes a method called "dry-run DNSSEC" that allows > for testing DNSSEC deployments without affecting the DNS service in > case of DNSSEC errors. It accomplishes that by introducing new DS > Type Digest Algorithms that when used in a DS record, referred to as > dry-run DS, signal to validating resolvers that dry-run DNSSEC is > used for the zone. DNSSEC errors are then reported with DNS Error > Reporting, but any bogus responses to clients are withheld. Instead, > validating resolvers fallback from dry-run DNSSEC and provide the > response that would have been answered without the presence of a dry- > run DS. A further EDNS option is presented for clients to opt-in for > dry-run DNSSEC errors and allow for end-to-end DNSSEC testing. > > > > The IETF Secretariat > > > > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
