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

Frederico A C Neves <fneves@registro.br> Wed, 13 May 2026 12:44 UTC

Return-Path: <fneves@registro.br>
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 4D259EDB3262 for <dnsop@mail2.ietf.org>; Wed, 13 May 2026 05:44:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1778676282; bh=tHwBRexYpFIqK5CVIvXgooyQ6qsyWKC77/pGL2qowEQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=yUM4Yg+TDOpYOVOWNOYF+R1gwy4mMSvDkvCl3LKxC0YI3j2Desm0zYunqqdVkqUXc /Zzdd1sqwn6kcqRusqFwOajLvPefquMjmK2cmFBYtJkB2CcqONEY/JRr5zY99yZYpL 9gu0vUsmIn2junZFV8ifyYbwu6VClx0/gIFbagKg=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Level:
X-Spam-Status: No, score=-4.397 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, RCVD_IN_DNSWL_MED=-2.3, 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=registro.br
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 9rhrGnx0DfnH for <dnsop@mail2.ietf.org>; Wed, 13 May 2026 05:44:37 -0700 (PDT)
Received: from clone.registro.br (clone.registro.br [200.160.2.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 8E922EDB3258 for <dnsop@ietf.org>; Wed, 13 May 2026 05:44:37 -0700 (PDT)
Received: by clone.registro.br (Postfix, from userid 1000) id DF9246098D; Wed, 13 May 2026 09:44:35 -0300 (-03)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=registro.br; s=clone; t=1778676275; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7k9FwYvJ55QyLnaBaCRmgNmNibpFUNRcLCyTHE0YxPI=; b=X4n+WFlTxcuAolRJC9IcfGD65RBNu4OFV8J4LSSmA51cW4/Wssh6s3ZepbwYTxsq+/6ja7 2OP9uXX1AQ1Q0IQWAa9knVU5n2X+FLGZu1FPTBk2Z7Sno1wPsxr9lr6OcvfZoNJeqUNE39 zIu5WgxBpeztzVHkQrwVZat2FDxYVkrOwzBap8+N4UaUw4RnYonO9TDwwYrQdDYtwdkBCT wi8pXfNTEjF13iYv1a9UrNny/v/9olATFb1v1X+cAvpQioF+SaeZRr3hjzNU+gJwt6FNSj Yeoj3LjALPhnK74XAR3JgVrg4bGP+DF66I/Ww4TfhbcYIMYT7iebqLqS8ofo0g==
ARC-Seal: i=1; s=clone; d=registro.br; t=1778676275; a=rsa-sha256; cv=none; b=LEplU0kmrFbZKilq0lgVdj792tIg4MWOQlSv96gOTDhN1yZVn418KRXmi6yLw2uIfHQd7w F4BRnGHjl5O+2SMQnuK9EdD+2MWxGhG4TZTdgNDXonGt4wp0PUUipuCWtIPlipj+9hOZs5 rbQbIzbUb97NVTJJii58+ONhBJka8jnoSifDUnkYGv00vzGEhA4/S7eFcUmcEr6bsRkFC8 knX7X3ZB0g3/u7QAckM2UfNlj8VIltbNYkm3WskQz2HwUAxWAS7qDgBbmVXCvRPBrLB4fL BNoZpg/HDAD3uWvUwp/Y2lGlIdIhbsu296gBwvD/vSbvachqIpUXI6mk0MA6KA==
ARC-Authentication-Results: i=1; clone.registro.br; none
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=registro.br; s=clone; t=1778676275; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7k9FwYvJ55QyLnaBaCRmgNmNibpFUNRcLCyTHE0YxPI=; b=VgHBb1FCN5IZ9pVA4fK49KDN8/lgEfPwEEm9BQtpO0BcFmiwodniKR5WFx9Ein/6N14r+a 1vagFLvxc2OvRpAeIcMvY3j0Gr0SwiyaR04P10FklpDREezEkOOUyBfT+rHQcAXHQkPH1Y a+DNzn8ojQL7LycKRXnXYhsK6GSMyf0HCGUYrkmvqJDIFexaOyVMlt6fk9K3JWPAanbj/t N4MRFACftHlzJYiAEmwZcSdfIKrKWNrjKSJWCqpauKmcqfesxdIwB6046xt6MFXeDx+2cC PY6Ex0XbZHQd0oSaVxKmDZoiAkucoL4EmoaufIlSCRMWpA2DraZ8ypX3LlcZmA==
Date: Wed, 13 May 2026 09:44:35 -0300
From: Frederico A C Neves <fneves@registro.br>
To: Cathy Zhang <scooct@163.com>
Message-ID: <agRyM8Lln6Gq9I4L@registro.br>
References: <57c4f22.390be.19e1b8328d2.Coremail.scooct@163.com> <5f9c95b0-6667-4e1a-8057-7940373b061b@nic.cz> <agM97XwTCU5TvXar@registro.br> <1ca91895.16dc.19e1f021315.Coremail.scooct@163.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1ca91895.16dc.19e1f021315.Coremail.scooct@163.com>
X-Rspamd-Queue-Id: DF9246098D
X-Rspamd-Server: clone.registro.br
X-Spamd-Result: default: False [-3.10 / 15.00]; BAYES_HAM(-3.00)[100.00%]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[163.com]; NEURAL_HAM(-0.00)[-1.000]; FREEMAIL_ENVRCPT(0.00)[163.com]; RCVD_COUNT_ZERO(0.00)[0]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DKIM_SIGNED(0.00)[registro.br:s=clone]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_SIGNED(0.00)[registro.br:s=clone:i=1]
X-Rspamd-Action: no action
Message-ID-Hash: 4SI7OKUA6K3HH7VXXVVCIFTWEQWBRKHE
X-Message-ID-Hash: 4SI7OKUA6K3HH7VXXVVCIFTWEQWBRKHE
X-MailFrom: fneves@registro.br
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/_UiD_Oh6cK4x6NQqKmlYAd22kWc>
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 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.

> 
> Thanks again for your kind support and insights.
> 
> 
> Cathy

Fred

> 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