Re: [DNSOP] signalling mandatory DNSSEC in the parent zone

Havard Eidnes <> Mon, 01 March 2021 19:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 366CD3A220F for <>; Mon, 1 Mar 2021 11:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3JIo92HKN4yl for <>; Mon, 1 Mar 2021 11:55:04 -0800 (PST)
Received: from ( [IPv6:2001:700:1:0:eeb1:d7ff:fe59:fbaa]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 245D33A220D for <>; Mon, 1 Mar 2021 11:55:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9395C43EA8C; Mon, 1 Mar 2021 20:54:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=he201803; t=1614628499; bh=OlgipPtpyXVS7shgbQeAQ+H5D2VXSB0H/ioDSLMsWI0=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=MVtE31iqvEy4w02PrKjWgAkOOd0KPOWWx86KU28lTCgz+OGdP8RasY1uESmgpiuLh ch2Kttdo2B+1s/5rYy4Jh446GFrM90V0AtSSdOBB2JMQOA0F85mmBqeZCpsK2hE3ox 5dXwp6dabaweP7FoymdBG805aUqQfLPG3vjXzfew=
Date: Mon, 01 Mar 2021 20:54:59 +0100 (CET)
Message-Id: <>
From: Havard Eidnes <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] signalling mandatory DNSSEC in the parent zone
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Mar 2021 19:55:06 -0000

>    - Switching providers while staying secure requires
>    inter-provider cooperation, including publishing ZSKs from
>    both providers in the DNSKEY RRSET served by both providers.


Maybe I just don't understand the context or conditions here, but

Isn't it possible to stand up a new signing and publishing setup
with new ZSKs and new KSKs, and have both the old DS record
pointing to the old setup's KSK and a new DS record pointing to
the KSK of the new setup registered in the parent zone, and then
change the actual delegation (NS records), while still retaining
both the two DS records for a while until the data from the old
setup has timed out?

There is then no need to share the secret part of the KSKs or the
ZSKs between the old and the new providers, or to include both
the new and the old ZSKs in the zone.


- Håvard