[DNSOP] Re: The conservative approach and the liberal approach for DNSSEC algorithm rollover

[Cathy Zhang <[e-mail]>]

Hi Fred,


At 2026-05-13 20:44:35, "Frederico A C Neves" <fneves=[e-mail]> wrote:

>Hi Cathy,
>
>On Wed, May 13, 2026 at 09:44:50AM +0800, Cathy Zhang wrote:
>> 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?
>>
>
>Yes.
>
>> 
>> 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.
>>
>
>It is important to note RFC 6840 sec. 5.11 witch clarifies 4035 sec.
>2.2 stating that it applies to servers, not validators. 4035 2.2
>specifies signer requirements with the aim to prevent downgrande

>attachs.


In the same passage in RFC 6840, it uses "MUST NOT".

   This requirement applies to servers, not validators.  Validators
   SHOULD accept any single valid path.  They SHOULD NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work.  A validator
   MAY have a configuration option to perform a signature completeness
   test to support troubleshooting.
It follows that there is no longer any ambiguity regarding how recursive resolvers should handle multi-algorithm scenarios.
Thanks for your information.


> >> >> Thanks again for your kind support and insights. >> >> >> Cathy > >Fred > >> At 2026-05-12 22:49:17, "Frederico A C Neves" <fneves=[e-mail]> 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 -- [e-mail] >> >To unsubscribe send an email to [e-mail] > >_______________________________________________ >DNSOP mailing list -- [e-mail] >To unsubscribe send an email to [e-mail]