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

Joe Abley <jabley@hopcount.ca> Fri, 28 April 2023 11:54 UTC

Return-Path: <jabley@hopcount.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 F3B7FC14CE29 for <dnsop@ietfa.amsl.com>; Fri, 28 Apr 2023 04:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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 (2048-bit key) header.d=hopcount.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 BKnkmjQsfZ7o for <dnsop@ietfa.amsl.com>; Fri, 28 Apr 2023 04:54:52 -0700 (PDT)
Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) (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 C4362C14CF15 for <dnsop@ietf.org>; Fri, 28 Apr 2023 04:54:52 -0700 (PDT)
Date: Fri, 28 Apr 2023 11:54:34 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=protonmail; t=1682682891; x=1682942091; bh=0LVpmVzI+4kelH8/IkoLdxqYOxyB47gHR0WkClL/45w=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=ZDoOqKZTGlnIRxK3SLGs51i6UiGaNiJg91A6DoRkb+0X2ecnJyJporNFzh50SudFV hlVf8RKiv2Ae8zX5vPd4/7JHF6dJSjGZEQO0cZOyXVjIFQ90dwWniiGx+z1+8Wl09D asevx8SBpspioe0CBATaI6vnKYCHw5GsCt+mckSZI3Duv6BjNbYSft+3TEz+EiV4nW +pNlObSjRErdiRz8k4KXaWcGVwWHkW5nytuhDIiTcoaiNBpfvPDYnBt7/DainCsc4l e7clHO62a+YFu2CBFFAylOwT+aleGPG9+9STO9yrOvSg1di1Htqn4qln9X4vo+3v1O FcmrwohMMFczA==
To: benno@NLnetLabs.nl, dnsop@ietf.org
From: Joe Abley <jabley@hopcount.ca>
Message-ID: <tEQnMNVgrVjJC2YrwitAMGYiInpePSwug0enBAlx6mrPcjLRYsHDSA60Co4X_of9lQvqYWrFjFbYBKnOSp_kcq39gvKqjsJPuZuFyG6QR30=@hopcount.ca>
In-Reply-To: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl>
References: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl>
Feedback-ID: 62430589:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_zoCwXovwRLLDElLDikvzLnkZALoRtitooZcLIXa2WM"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7Veq_duvjTsAZrEct2tfHasqr3M>
Subject: Re: [DNSOP] 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: Fri, 28 Apr 2023 11:54:57 -0000

Hi Benno,

On Thu, Apr 27, 2023 at 16:05, Benno Overeinder <[benno@NLnetLabs.nl](mailto:On Thu, Apr 27, 2023 at 16:05, Benno Overeinder <<a href=)> wrote:

> 2) Update the definition as proposed by Duane and with the agreement of
> some others (see mailing list
> https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/):
>
> "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 [or not at all] for a zone".

This is close to what I understand by the term.

I would eliminate the parenthetical section, since as I have droned on about at some length already I think the lack of a response is not what we understand by "lame" -- lameness involves a response, and without a response there can be no lameness.

I am also unsure about "or by the child's apex NS RRSet" since in my mind "delegation" is something that is configured definitively north of the zone cut. But since some implementations promote the NS set found south after following a referral I suppose the effect is the same if a server exhibits the same characteristics.

Joe

>