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

Cathy Zhang <scooct@163.com> Wed, 13 May 2026 01:45 UTC

Return-Path: <scooct@163.com>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 86805ED72CAC for <dnsop@mail2.ietf.org>; Tue, 12 May 2026 18:45:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1778636735; bh=WSiuRX0VxyVsvaeoNA61ddoNNg5q+PjLFo1heWqT6aM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=J7s4ENOQXT+wU5OzZiUrvRnVtk0i9IS8L1/KPf0U3mwIPxk99qygCjVFipbin2pei 31IvhBuThhc5ATdLclGXdGxJKbiKSFmwOFX8BltPxHwcielZDXSgMBdFq4sCqXt6Ze 9m9UkNxtVQ1uSu2c7z7+LrPUBtcbTxR4UZaGUz1s=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=163.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikw_iPJGLNoN for <dnsop@mail2.ietf.org>; Tue, 12 May 2026 18:45:29 -0700 (PDT)
Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 24C0CED728EF for <dnsop@ietf.org>; Tue, 12 May 2026 18:45:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:To:Subject:Content-Type:MIME-Version: Message-ID; bh=WSiuRX0VxyVsvaeoNA61ddoNNg5q+PjLFo1heWqT6aM=; b=I NKz3Sqd0bLGL6PQhWij99ldnYUTOqOd7bYKyFlr9YAPzn4be9k/jEL78vVrX2yUu DKlfO76pNJsIZgGj/27Gn+QNXR9xrLmXNDuSG1F9qYKiyxDSYWUgNgUI/e6LuKTY rgKU4HO90of0NPDanRLJDgZGJp5I3Cl4xzkqswX7C0=
Received: from scooct$163.com ( [2001:dc7:dd00:6800::f2] ) by ajax-webmail-wmsvr-40-107 (Coremail) ; Wed, 13 May 2026 09:44:50 +0800 (CST)
X-Originating-IP: [2001:dc7:dd00:6800::f2]
Date: Wed, 13 May 2026 09:44:50 +0800
From: Cathy Zhang <scooct@163.com>
To: Frederico A C Neves <fneves=40registro.br@dmarc.ietf.org>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version 2023.4-cmXT build 20260403(27802f6d) Copyright (c) 2002-2026 www.mailtech.cn 163com
In-Reply-To: <agM97XwTCU5TvXar@registro.br>
References: <57c4f22.390be.19e1b8328d2.Coremail.scooct@163.com> <5f9c95b0-6667-4e1a-8057-7940373b061b@nic.cz> <agM97XwTCU5TvXar@registro.br>
X-NTES-SC: AL_Qu2cCvqYuU4i5iGQZOkcnk0Xgeg4WMe5u/wg1YdSc+AEnTnUwQkNcVR/NHL5+8OuIS2FvQO4ciNN48tqfY1ZVvgdMOCbzr/gNiWK4ROFLA==
Content-Type: multipart/alternative; boundary="----=_Part_21920_1160423626.1778636690191"
MIME-Version: 1.0
Message-ID: <1ca91895.16dc.19e1f021315.Coremail.scooct@163.com>
X-Coremail-Locale: zh_CN
X-CM-TRANSID: aygvCgC30PGS1wNqmxmiAA--.451W
X-CM-SenderInfo: 5vfr0urw6rljoofrz/xtbC4xJ1gWoD15LrHwAA3d
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Message-ID-Hash: LHA2KZT4REFA3EN3LCHLVUYN7RE2HZKE
X-Message-ID-Hash: LHA2KZT4REFA3EN3LCHLVUYN7RE2HZKE
X-MailFrom: scooct@163.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: The conservative approach and the liberal approach for DNSSEC algorithm rollover
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PEBoEsTXsJ4F1fqoNAiV-qNr-Dk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

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" <fneves=40registro.br@dmarc.ietf.org> 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 -- dnsop@ietf.org
>To unsubscribe send an email to dnsop-leave@ietf.org