Hi Fred,
Thanks for your reply and the report. Based on the publication timeline of the relevant RFCs, I would speculate the evolution is as follows: In 2005, RFC 4033–4035 were published. In 2006, RFC 4641 specify DNSKEY key rollover procedures, introducing the "pre-publish" and "double-signature" methods. However, it doesn't address cases involving algorithm rollover. Subsequently, some recursive DNS servers strictly adhered to the RFC 4035 requirements when handling scenarios with multiple DNSSEC algorithms coexisting. In 2012, RFC 6781 observed this real-world behavior and added a dedicated section for algorithm rollover, which further subdivided and refined the double-signing workflow.The document notes that "there are implementations of validators". It is my understanding that this section was created primarily for compatibility with those validators. So I would like to clarify one point:If those validator implementations no longer maintain such strict compliance constraints, could we correspondingly simplify the operational steps on the authoritative DNS side? Thank you very much for sharing the report.If the test with .br second level domains in 2018 using RIPE Atlas measurements targeted recursive resolvers, it would suggest that we can safely simplify the algorithm rollover process. By contrast, if the tests were focused on the authoritative side, the original concern raised in RFC 6781 still exists. Thanks again for your kind support and insights. Cathy At 2026-05-12 22:49:17, "Frederico A C Neves" <[email protected]> wrote: >On Tue, May 12, 2026 at 04:31:22PM +0200, Libor Peltan wrote: >> Hi Cathy, >> >> it is slightly puzzling me that one RFC (6781) encourages "loose >> interpretation" (in fact, violation) of another RFC (4035). >> >> I'd stick with what is called the "conservative approach" , until >> draft-huque-dnsop-multi-alg-rules makes it to RFC (I wish!). >> >> Libor >> >> On 12. 05. 26 11:27, Cathy Zhang wrote: >> > Hi all, >> > RFC 6781 defines two modes for algorithm rollover: the conservative >> > approach and the liberal approach. >> > And the relevant description is given on page 29 of RFC 6781 as follows: >> > However, there are implementations of validators known to follow the >> > more conservative approach. Performing a Double-Signature KSK >> > algorithm rollover will temporarily make your zone appear as Bogus by >> > such validators during the rollover. Therefore, the rollover >> > described in this section will explain the stages of deployment and >> > will assume that the conservative approach is used. >> > Is this distinction still necessary today, or is it possible to >> adopt the same approach as for ZSK/KSK rollover? > >Since at least 2017 many TLDs have done algroll using the liberal >approach. > >The presentations bellow illustrate our journey on how to do it >safely. The first one has the root of the question based on the >events that happened in Jan/2011. > >https://indico.dns-oarc.net/event/28/contributions/513/attachments/487/794/algorith-rollover-approach.pdf > >https://icann-hamster.nl/ham/soac/ssac/dnssec/icann62/br%20DNSSEC.pdf > >To answer your question in our experience today you could follow the >liberal approach quite safely. > >> > BR, >> > Cathy > >Fred > >_______________________________________________ >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]
