Re: [DNSOP] CDS and multi-provider DNSSEC

Shumon Huque <> Sat, 23 March 2019 23:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B85B1278CF for <>; Sat, 23 Mar 2019 16:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IN9gYNStXnap for <>; Sat, 23 Mar 2019 16:00:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60EE71277E6 for <>; Sat, 23 Mar 2019 16:00:16 -0700 (PDT)
Received: by with SMTP id e13so4706801ioq.6 for <>; Sat, 23 Mar 2019 16:00:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n1odYONGHWzeLQmDhpx9WU/zUb7wuN7cMI/LE5/yCDY=; b=iIEwqd8SZu7odn6lw/6dj8UU7Dq1N4XZREHrYbnfliB3uaYvl1ezVBBaIyo8Vt4tC0 bZgQW8uT4kuNNdWFABeRAQcGjfBMD5077jpyldDdvkbgQA+uZ1O4XNlOpcjRQwIfxuSk oAtwZH1LitVQOKCMMe/pUKIE8V62xoTXWW/otP+kNTYAe03+4dbuCzF7mQl7G7GGcnNN ztd5qLN9A7twSqcg59vaTl10Uk3YQlGp0t6uUYn1ff8aqyiF5XRKsKeVckRIX3LJNAoX DJPTYOwkFR0xqk6m2kb0UzzUd+obdKleh3sJw1ojcqe08L6+0vorfwPrQnpUmnD5ZXFw WfLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n1odYONGHWzeLQmDhpx9WU/zUb7wuN7cMI/LE5/yCDY=; b=dxDeRI1OiTB0kEGAHc7yQpS7Ma/JYX6sZca5l+sv8bhIZsrpX4JQUzdtQDslPzcoZf ImMJPGXey8kMhBbqA2AwwQnnRYqtKKJeDK51NZSqAHJFQY7BMbSRbOOuxdcTRbwUNzJF hLvQTDEPCMz8PnXST3LAatkTv/TXZxZVtFILIfZG5zdkUF5+aL9rypsupwg+7Uz1lURZ 5qaP02kCp8xQ55mrdclIxFPKFXXk6TKO2CW9TWuctFJ3s02X9q/qcAQZewXlTMbZCkvl 0+Jt4iQxMbRkds9m/bJAGtJGxiuZjIIoGkwKyJgqlwbEQQYmI9DxSdVizmgoXluDc3EG 1Kgg==
X-Gm-Message-State: APjAAAV4wf4rW08j9cL00jSAVXOUTRB4fLXXBzgMuZTMVfzHcuBV/CQN MOrmmxFpYssxkh6+1ZzA+jLb7lDElNnMiodO21Y=
X-Google-Smtp-Source: APXvYqwpxBp7e3fRuxwtU63jh7uNKbpw6fcy2S80K8FxM10M5Uydlx/yr7byiNd7Y7Fvg3TEicO+iSs3xkUvBDPEht4=
X-Received: by 2002:a6b:f10f:: with SMTP id e15mr11966007iog.106.1553382015558; Sat, 23 Mar 2019 16:00:15 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Shumon Huque <>
Date: Sun, 24 Mar 2019 00:00:04 +0100
Message-ID: <>
To: Tony Finch <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="0000000000003ce9b70584caef3b"
Archived-At: <>
Subject: Re: [DNSOP] CDS and multi-provider DNSSEC
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: Sat, 23 Mar 2019 23:00:19 -0000

On Fri, Feb 1, 2019 at 1:35 PM Tony Finch <> wrote:

> I'm working on tools for KSK rollover automation at the moment.
> It turns out that CDS records are very useful even if your parent zone
> doesn't check them.
> KSK rolls work better when the DS records are not simply generated from
> the current DNSKEY RRset. You need to be a bit more clever if you want to
> minimize interactions with the parent zone, or minimize the DNSKEY RRset
> size, or do an algorithm rollover.
> So your tool for setting DS records needs some way to ask the key store
> what DS records should be. The nice thing about CDS records is that they
> provide a standard way to do this, independent of the key store or signing
> software. This allows registrar API clients to be decoupled from the
> DNSSEC implementation.
> This makes me wonder how well this observation generalizes to
> multi-provider DNSSEC.

Sorry for answering this message so late. I'm in Prague for IETF104 and
am gradually catching myself up with miscellaneous mailing lists ..

> In model 1, the zone owner manages the KSK, so all the CDS/DS logic
> remains centralized.

Yes, that's true.

However, for automated CDS->DS updates, the zone owner still needs
to propagate the CDS (or CDNSKEY) down to each of the signing providers.
Since CDS/CDNSKEY are signed by an active KSK (that is managed by the
zone owner), the providers will still likely need to provide an API that
allows a
signed CDS/CDNSKEY RRset to be pushed to them. This is analogous to how
the current draft requires them to support an API mechanism to have a signed
DNSKEY RRset pushed to them.

In model 2, each DNS provider has its own KSK, and does its own DNSKEY
> RRset management. In order to support CDS/CDNSKEY, I think it is necessary
> for each provider to (somehow) generate RRsets that are the union of their
> CDS/CDNSKEY RRsets and the other provider's.
> In normal cases, I think the "somehow" involves getting the other
> provider's RRset, replacing any records corresponding to this provider's
> keys with what this provider thinks they should be, and retaining any
> records for unknown keys (which presumably belong to the other provider).
> There's a mildly awkward risk of zombie records that are copied back and
> forth despite neither provider knowing about them, but I suppose that can
> be fixed manually if it arises. Or maybe it's simpler if this is done via
> an API, like ZSK sharing :-)

I am in agreement with your last statement. We might as well extend the ZSK
sharing API to also include CDS/CDNSKEY sharing.

The risk of potential zombie records also exists with the DNSKEY RRset, and
expect that would be addressed by active management by the zone owner. Or,
post bootstrapping, active pollling of providers by one another.