IETF Logo Mail Archive

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

Ralf Weber <dns@fl1ger.de> Tue, 02 May 2023 04:52 UTC

Return-Path: <dns@fl1ger.de>
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 85C95C151B03 for <dnsop@ietfa.amsl.com>; Mon, 1 May 2023 21:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 aGSejA27zQdE for <dnsop@ietfa.amsl.com>; Mon, 1 May 2023 21:52:32 -0700 (PDT)
Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 175D7C151B00 for <dnsop@ietf.org>; Mon, 1 May 2023 21:52:30 -0700 (PDT)
Received: from [100.64.0.1] (p4ff53c54.dip0.t-ipconnect.de [79.245.60.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 6CAD65F4041D; Tue, 2 May 2023 04:52:27 +0000 (UTC)
From: Ralf Weber <dns@fl1ger.de>
To: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>
Cc: Paul Hoffman <paul.hoffman@icann.org>, DNSOP Working Group <dnsop@ietf.org>
Date: Tue, 02 May 2023 06:52:15 +0200
X-Mailer: MailMate (1.14r5964)
Message-ID: <625B202C-E57D-4590-AEC3-8EC33A9DE662@fl1ger.de>
In-Reply-To: <B93A0E80-08F8-4FDB-81C2-47C465D8DDB4@verisign.com>
References: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl> <40C193AF-938C-418F-924E-94F4DD358164@icann.org> <B93A0E80-08F8-4FDB-81C2-47C465D8DDB4@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3lAu9dndoRcqlOwg-fJTjhG3gAk>
Subject: Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
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, 02 May 2023 04:52:33 -0000

Moin!

On 1 May 2023, at 18:43, Wessels, Duane wrote:

> My preferred definition is the one originally given by Paul Vixie, amended by myself, and further amended by Peter Thomassen:
>
> A lame delegation is said to exist when one or more authoritative
> servers designated by the delegating NS rrset or by the child's apex NS
> rrset answers non-authoritatively for a zone.
>
> I don’t think it is perfect, but it is an improvement.  I don’t think perfection will be achievable.
>
> IMO “[or not at all]” does not belong in the definition.  I don’t think we should allow timeouts to be confused for or considered as lame delegation.
>
> If something like the above definition is adopted then the document can note there is some historical lack of agreement or consistency in use of the term.

Fully agree. After all DNS still runs over UDP and packets are getting dropped anywhere in the network for different reasons, so confusing this with a clearly visible configuration error would be wrong.

So long
-Ralf
——-
Ralf Weber

v2.23.0 | Report a Bug | By Email