I think dry-run DNSSEC is an interesting idea. I suggest that the authors also consider how it would interact with DELEG, which aims to improve the state of DNSSEC configuration and improve delegation flexibility. Some variants of the DELEG proposal might already enable some kind of dry-run DNSSEC capability.
For this draft, I find the current text hard to read. I also think that the expectations are underspecified. This specification permits some rather complex arrangements with mixtures of "dry-run" and "production" DS records, and I couldn't say with any confidence what a resolver is supposed to do when confronted with such a mixture. I'm also interested in the possibilities for malicious use of this extension. Can a malicious domain cause a resolver to do an enormous amount of work? Can a malicious intermediary cause an enormous volume of error reports? --Ben ________________________________ From: Yorgos Thessalonikefs <[email protected]> Sent: Tuesday, July 16, 2024 10:34 AM To: [email protected] <[email protected]> Subject: [DNSOP] Fwd: New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-02.txt 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: [email protected] To: Roy Arends <[email protected]>, Willem Toorop <[email protected]>, Yorgos Thessalonikefs <[email protected]> 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://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-02.txt__;!!Bt8RZUm9aw!9yxbk6zobQ5e2KAbITIs5ksKFCgMQL_bo2J1iUYKBhWlpDCxuRgYvdi_j-8kynjmfe0e2W93qeY0jMc$ Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-yorgos-dnsop-dry-run-dnssec/__;!!Bt8RZUm9aw!9yxbk6zobQ5e2KAbITIs5ksKFCgMQL_bo2J1iUYKBhWlpDCxuRgYvdi_j-8kynjmfe0e2W93V7AZJBM$ HTML: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-02.html__;!!Bt8RZUm9aw!9yxbk6zobQ5e2KAbITIs5ksKFCgMQL_bo2J1iUYKBhWlpDCxuRgYvdi_j-8kynjmfe0e2W93NMRAJNU$ HTMLized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec__;!!Bt8RZUm9aw!9yxbk6zobQ5e2KAbITIs5ksKFCgMQL_bo2J1iUYKBhWlpDCxuRgYvdi_j-8kynjmfe0e2W93aAlvuRU$ Diff: https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-yorgos-dnsop-dry-run-dnssec-02__;!!Bt8RZUm9aw!9yxbk6zobQ5e2KAbITIs5ksKFCgMQL_bo2J1iUYKBhWlpDCxuRgYvdi_j-8kynjmfe0e2W9343QzeyE$ 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 -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
