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
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
- [DNSOP] Updating RFC 7344 for cross-NS consistency Peter Thomassen
- Re: [DNSOP] Updating RFC 7344 for cross-NS consis… Paul Wouters
- Re: [DNSOP] Updating RFC 7344 for cross-NS consis… Peter Thomassen
- Re: [DNSOP] Updating RFC 7344 for cross-NS consis… Bob Harold
- Re: [DNSOP] Updating RFC 7344 for cross-NS consis… Peter Thomassen
- Re: [DNSOP] Updating RFC 7344 for cross-NS consis… Bob Harold
- Re: [DNSOP] Updating RFC 7344 for cross-NS consis… Peter Thomassen