Hi Fred,
At 2026-05-13 20:44:35, "Frederico A C Neves"
<[email protected]> 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"
> >> >> <[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]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
