Re: [DNSOP] Updating RFC 7344 for cross-NS consistency

Paul Wouters <paul@nohats.ca> Tue, 28 June 2022 00:56 UTC

Return-Path: <paul@nohats.ca>
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 D673FC15A730 for <dnsop@ietfa.amsl.com>; Mon, 27 Jun 2022 17:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H7I_18EVtEe for <dnsop@ietfa.amsl.com>; Mon, 27 Jun 2022 17:56:16 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EDFC157B47 for <dnsop@ietf.org>; Mon, 27 Jun 2022 17:56:16 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4LX5kk2WKyzKJk; Tue, 28 Jun 2022 02:56:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1656377774; bh=/Tjg9WTRzUKagEScK5GDuEwDnVyrnVnn7cgL5PYCz8o=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=E9mlpsKBy+aMYhP/OQMNLomqH5URisPL7HrC/s0NyJOF3Qojmq/BHUbtuO67TZ5Sy SLbhW8+TfakW2g1lVXBtG0nH067cGgSw4YPN9QdrisALoA+R+z4LPwUkQGyOEwdnS2 ScIMaf82mcdNR5rwzLpFDbuzMQli5vzoz9m87TKM=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 3SKdLRPPN2uV; Tue, 28 Jun 2022 02:56:13 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 28 Jun 2022 02:56:13 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8E89F39AC19; Mon, 27 Jun 2022 20:56:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8A6CC39AC18; Mon, 27 Jun 2022 20:56:12 -0400 (EDT)
Date: Mon, 27 Jun 2022 20:56:12 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Peter Thomassen <peter@desec.io>
cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
In-Reply-To: <f945a354-77d7-55b8-a2c1-11c8794ae653@desec.io>
Message-ID: <9cc0c19f-da83-72ae-a940-16f1662bf29@nohats.ca>
References: <f945a354-77d7-55b8-a2c1-11c8794ae653@desec.io>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VwiTn4jM34sWpz1oQorrnpx17mQ>
Subject: Re: [DNSOP] Updating RFC 7344 for cross-NS consistency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 28 Jun 2022 00:56:20 -0000

On Mon, 27 Jun 2022, Peter Thomassen wrote:

> In a multi-signer setup, this means that a single provider can (accidentally 
> or maliciously) roll the DS record at the parent.

That's a good point.

> I thus propose to update RFC 7344 along the lines of (2), such that it is 
> REQUIRED to retrieve CDS/CDNSKEY records using queries to all authoritative 
> nameservers.

The question is now how to phrase this exactly. Do we want the parent to use
its "external" knowledge of NS records of the child - eg from its WHOIS data?
That would be clean and simple.

Or are we okay that it queries for the NS records to get the list ?
If so, it would need to require DNSSEC for the NS RRset, but there might
be more than one validly signed NS RRset if these nameservers are out
of sync. In that case, which of these is the intended one?

> Such a change would also prevent CDS/CDNSKEY loops, where one secondary has a 
> replication issue and keeps announcing an old C* RRset (and the parent 
> happens to retrieve alternating information during daily scans, for example).

Also a good point.

> Does the WG think this is a reasonable thing to pursue?

I think this could be an excellent super short RFC that Updates: 7344.

Paul