IETF Logo Mail Archive

Re: [dnsext] Asking for review on this errata by DNSSEC experts Re: [Errata Verified] RFC4035 (5226)

Rob Austein <sra@hactrn.net> Sun, 06 August 2023 02:03 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E126C151097; Sat, 5 Aug 2023 19:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
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 QiWJraH3BxTm; Sat, 5 Aug 2023 19:03:32 -0700 (PDT)
Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20FCC14CF1C; Sat, 5 Aug 2023 19:03:26 -0700 (PDT)
Received: from minas-ithil.hactrn.net (unknown [IPv6:2601:19c:4f80:ae5::707]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) (Authenticated sender: minas-ithil.hactrn.net@hactrn.net) by adrilankha.hactrn.net (Postfix) with ESMTPSA id 66F293985A; Sun, 6 Aug 2023 02:03:25 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id CA98A2EA0117; Sat, 5 Aug 2023 22:03:22 -0400 (EDT)
Date: Sat, 05 Aug 2023 22:03:22 -0400
From: Rob Austein <sra@hactrn.net>
To: Eric Vyncke <evyncke@cisco.com>
Cc: Mark Andrews <marka@isc.org>, RFC Errata System <rfc-editor@rfc-editor.org>, dnsdir@ietf.org, peter.van.dijk@powerdns.com, roy.arends@telin.nl, mlarson@verisign.com, massey@cs.colostate.edu, scott.rose@nist.gov, dnsext@ietf.org
In-Reply-To: <1B5D0B11-9930-4D7B-ABC5-0AEDA3A4553F@cisco.com>
References: <1B5D0B11-9930-4D7B-ABC5-0AEDA3A4553F@cisco.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20230806020322.CA98A2EA0117@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsext/RTvgmzS7xzXlttUChNViraJpCzI>
X-Mailman-Approved-At: Mon, 07 Aug 2023 11:03:16 -0700
Subject: Re: [dnsext] Asking for review on this errata by DNSSEC experts Re: [Errata Verified] RFC4035 (5226)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Aug 2023 02:03:34 -0000

The reported erratum makes my head hurt, but I think Mark is right:
the original text is correct and the purported ambiguity doesn't
exist.  In essence, each zone cut needs to be (and already should be)
handled separately, so the criterion that matters here is just whether
the name server is authoritative for the parent zone or not; whether
the name server is authoritative for the grandparent zone has nothing
to do with the zone cut under consideration.

If Peter still believes that the original text is in error, I (at
least) will require a more detailed worked example of the failure,
showing the exact behavior for both DNSSEC-aware and DNSSEC-oblivious
resolvers, because I don't see the purported problem.

v2.23.0 | Report a Bug | By Email