I have no problem to understand the need and wish to test new configuration before it is alive, but I do not think that it is correct to increase the complexity of the DNSSEC protocol as the draft suggests. There are other ways to achieve the same goal.
Zonemaster (https://zonemaster.net/) and other tools can test a proposed delegation of a zone before it is delegated. Zonemaster also partially meets the needs by the draft by allowing proposed DS RRset to be included in the test. The model is there, but you can only test the zone, not a specific name by Zonemaster. When reading the documentation for DNSViz (https://github.com/dnsviz/dnsviz) it says that if you run DNSViz on the command line, you can insert a DS RRset. A DNS resolver, e.g. Bind, can be configured with a trust anchor for any domain and DS. With such a configuration the proposed DS record can be tested without publishing it and affecting production. I do not say that the tools above are ready for the use cases in the draft, but it shows that there is an alternative path to meed the needs of the use cases in the draft. Instead there are opportunities for some party to create a tool, maybe based on the tools above, to make it easy to test names and record types in a zone based on a proposed DS RRset. Keep testing outside the protocol as much as possibly to keep complexity down. I am against turning the draft into an RFC, especially since it is propsed to be a standards track RFC. Yours, Mats --- Mats Dufberg mats.dufb...@internetstiftelsen.se<mailto:mats.dufb...@internetstiftelsen.se> Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ From: DNSOP <dnsop-boun...@ietf.org> on behalf of Willem Toorop <wil...@nlnetlabs.nl> Date: Tuesday, 12 July 2022 at 16:36 To: DNSOP Working Group <dnsop@ietf.org> Subject: Re: [DNSOP] New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-01.txt Dear dnsop, We submitted a new version of a “dry-run DNSSEC” draft. The draft describes a method that allows for testing DNSSEC deployments in real world DNS(SEC) deployments without affecting the DNS service in case of DNSSEC errors. Any encountered errors are signaled to the DNS operator of the faulty zone with DNS Error Reporting (draft-ietf-dnsop-dns-error-reporting). This is a new idea which will be presented during dnsop at the IETF114 and was also presented at the IETF113. A recording of the IETF113 presentation is here: https://youtu.be/watch?v=7HxcmvFOnlU&t=3675s Slides here: https://datatracker.ietf.org/meeting/113/materials/slides-113-dnsop-dry-run-dnssec-01 We received a lot of feedback with our presentation which we used to reorganize the draft to convey the idea more clearly and coherently. We also received some critique and objections which were non-technical in nature. Below is a list with these objections followed by our response. ** This is another straw on the camel’s back ** Not all resolvers have to support/implement it. Most important is that provisioning at the registry and signaling of Dry-run is supported. If needed we can say it is OPTIONAL for resolvers in the draft. We intend to implement it ourselves in Unbound and have it enabled by default when error reporting is enabled. We know from experience with trust-anchor signaling and sentinel record that with only a small, up to date resolver population, the signaling is already quite substantial. There are different kinds of straws and this one is one that has the good cause of enabling operators to deploy DNSSEC with confidence. ** Why not have a duplicate parallel test deployment? ** There is nothing better than testing with your actual user population to dry-run your DNSSEC deployment. Note that slack’s parallel test deployment did not show them the Route53 failure that caused them to have an DNSSEC outage eventually[1] ** Why not sell DNSSEC domains cheaper? ** Yes, we’re all for that too, but that’s orthogonal to seeing what the actual effect of starting DNSSEC with your deployment with your real user population would be. The other objections which were more technical, like for example “registries supporting only fixed sized hashes per algorithm” and “couldn’t we normalize the different DS hacks somehow” are all addressed in the new version of the document. We’re looking forward to a new round of feedback and critique ;) Both on-list and in-person at the IETF-114! Kind regards, Yorgos, Willem and Roy Op 11-07-2022 om 23:58 schreef internet-dra...@ietf.org: > > A new version of I-D, draft-yorgos-dnsop-dry-run-dnssec-01.txt > has been successfully submitted by Yorgos Thessalonikefs and posted to the > IETF repository. > > Name: draft-yorgos-dnsop-dry-run-dnssec > Revision: 01 > Title: dry-run DNSSEC > Document date: 2022-07-11 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-01.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-01.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec > Diff: > https://www.ietf.org/rfcdiff?url2=draft-yorgos-dnsop-dry-run-dnssec-01 > > 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 a new DS > Type Digest Algorithm that signals 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 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 https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
