IETF Logo Mail Archive

[DNSOP] signalling mandatory DNSSEC in the parent zone

Jim Reid <jim@rfc1035.com> Mon, 01 March 2021 14:19 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84FF3A1CED for <dnsop@ietfa.amsl.com>; Mon, 1 Mar 2021 06:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngu9eSKGFgyy for <dnsop@ietfa.amsl.com>; Mon, 1 Mar 2021 06:19:05 -0800 (PST)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125833A1CEC for <DNSOP@ietf.org>; Mon, 1 Mar 2021 06:19:04 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id E6CBF2421481; Mon, 1 Mar 2021 14:18:59 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <789EBF89-24CC-452A-A1D0-AE5583D6A476@wisser.se>
Date: Mon, 01 Mar 2021 14:18:59 +0000
Cc: dnsop <DNSOP@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A148F043-6DC6-47B0-B6B0-F112BF346E73@rfc1035.com>
References: <4C3B1EF7-D37F-40D4-9C39-70FADF2B71CC@wisser.se> <789EBF89-24CC-452A-A1D0-AE5583D6A476@wisser.se>
To: Ulrich Wisser <ulrich=40wisser.se@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1xrVohJY5dnD0G6KP0GRQZd74Zg>
Subject: [DNSOP] signalling mandatory DNSSEC in the parent zone
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2021 14:19:07 -0000


> On 1 Mar 2021, at 13:29, Ulrich Wisser <ulrich=40wisser.se@dmarc.ietf.org> wrote:
> 
> 100% signed would mean unsigned zones do not get delegated, going insecure is no longer an option.
> I would like the protocol to be able to handle that case. 

Ulrich, that seems to be a (registry-specific?) policy matter => probably out of scope for the DNS protocol.

How could a parent signal “everything below this point of the tree is signed”? How could they guarantee that was true, given delegation means there’s a change of control for some part of the name space? How would resolving servers be expected to use this signalling information? If they come across an unsigned but working delegation, should they treat that as a validation failure or continue to resolve the query? That would seem to be a local policy/configuration matter too.

I’m not sure it matters to anyone if some parent zone has this sort of policy or not. Could you explain the use case or problem statement?

v2.23.0 | Report a Bug | By Email