Re: [DNSOP] On obsoleting DNSSEC RFCs; Example from RFC 4035

Joe Abley <> Mon, 11 November 2019 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17904120A32 for <>; Mon, 11 Nov 2019 11:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PZ7fdhEErorP for <>; Mon, 11 Nov 2019 11:32:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA00D12081C for <>; Mon, 11 Nov 2019 11:32:37 -0800 (PST)
Received: by with SMTP id q70so12187314qke.12 for <>; Mon, 11 Nov 2019 11:32:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IXYHoAn0bti2ceN4HY05el6WumTMYXNazl8cflr2puM=; b=JMvH2rUt3FbgOh2VTL/6lN6Llq0mXbUYiEJqc2ytbmVqBOkItxVvfLPik9HX6pX20l +HpE3ROh69mt0x07bAaIWW7blhuCwqP9VAfvff/RI75kzz5cW90aBg7OdoGxBVvjGNYm hNTTUaeqU+oYTQoq/Io0r/ZB9ppGIRPBVatn4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IXYHoAn0bti2ceN4HY05el6WumTMYXNazl8cflr2puM=; b=NXcGVGu9B6TgnXrk6E/hqhcdcuGfeaHTmS9eyLFktH+G7tn2UM8gylxsmFgG9mO0w5 6h5cI2dTlv51zJsZ6eAyFWhAC2tQNxQTIb/QE6LYqhSZHy5YFJT0+EfCjLfvZ3gToiq6 ZWcn0dTlI/SA6NE0jqh4ZNsmbcJ2skdIhHeooFZlAJfmNU66VfoR+q0Dfgm2ArQVhiOj iDI85EorL5uMJbirVjU5C7aNcYd0Z1RvWhwrhGsCYT9KCT56546NiPZqZZuynZGrbTc3 ZZi0jx7AcZqFNZBFoxoIcJ9Ml0sNz5/ow8YkWkeRUqM0ujRONbgdPGtu4nEvCMbBpL36 DDRQ==
X-Gm-Message-State: APjAAAWYqgTw/F30KFcn9YKtR0PdHi/VIyMT7xx7IxTgJVTGvzu8H8DL q/Ko+P2ohHAM5mnR10uPYJoLFg==
X-Google-Smtp-Source: APXvYqwsSfQVAUqHip+sda1BlBpTCqFKNWIqGmQ42DpaxjgdVl7If4b+glSzQ1fLT9wyAzBPPSGfkw==
X-Received: by 2002:ae9:f80d:: with SMTP id x13mr2305687qkh.63.1573500756615; Mon, 11 Nov 2019 11:32:36 -0800 (PST)
Received: from ?IPv6:2607:f2c0:e784:350b:1d93:b099:e222:2b73? ([2607:f2c0:e784:350b:1d93:b099:e222:2b73]) by with ESMTPSA id q16sm5830391qkm.27.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Nov 2019 11:32:35 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Joe Abley <>
In-Reply-To: <>
Date: Mon, 11 Nov 2019 14:32:34 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: =?utf-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <>
Subject: Re: [DNSOP] On obsoleting DNSSEC RFCs; Example from RFC 4035
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, 11 Nov 2019 19:32:55 -0000

Hi Дилян,

On 11 Nov 2019, at 14:07, Дилян Палаузов <> wrote:

> Why the example from RFC 4035 Appendix A generats RRSIG for DNSKEY signed by the ZSK, but for IANA.ORG there is no such

Some signing toolchains sign every RRSet in the a zone with the ZSK and additionally sign the DNSKEY RRSet with a KSK (in situations where both ZSK and KSK are used). Some toolchains specifically suppress the signature over the DNSKEY RRSet. Some toolchains give you one of those as a default with an option to switch to the other behaviour.

Using ZSKs and KSKs is conventional and often assumed, but perhaps it's reasonable for some implementers to worry about making assumptions and to err on the side of too many signatures. It's might not always be possible to infer intent from a single SEP bit on one RR. In a conventional scenario the signature by the ZSK over the DNSKEY RRSet is not needed, since for the ZSK to be useful the KSK must already be trusted, and the mechanism for gaining trust in a published ZSK is to verify the signature by a trusted KSK over the DNSKEY RRSet. The ZSK signature adds nothing useful.

More generally, I suppose, this is an example of the specification not demanding a particular behaviour, and implementers having the freedom to make their own decisions. In this case I can't think of a reason why the ambiguity is harmful, though.

> If this is not the right mailing list, which is the right one?

I think this is a perfectly good place to ask that question.