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

Donald Eastlake <d3e3e3@gmail.com> Wed, 03 May 2023 16:23 UTC

Return-Path: <d3e3e3@gmail.com>
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 E356AC1524DB for <dnsop@ietfa.amsl.com>; Wed, 3 May 2023 09:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.844
X-Spam-Level:
X-Spam-Status: No, score=-1.844 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=gmail.com
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 CvfxL0MdyQhK for <dnsop@ietfa.amsl.com>; Wed, 3 May 2023 09:23:43 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 47B73C1524B4 for <dnsop@ietf.org>; Wed, 3 May 2023 09:23:43 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-94eff00bcdaso1034757766b.1 for <dnsop@ietf.org>; Wed, 03 May 2023 09:23:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683131021; x=1685723021; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vzHI3ullvefyVTG0SdBYkfi0vgpH6y5dJTpCTjKEKoU=; b=PCXfq7EVk6KIQKtKwvkDoRzM3/+dt0KLwih4EMJZRN+4eRGkVNaaUEtBu/FasWzgle tAEHfTTaGtcXbcxNm+vBJ9lXx4ZHIQrpxVqs1INp5y1LK4uh+i9vM5jgGpqK4CUUJbEX AFqE86Q09gFLDKxsQgvZ5O7k7zrQiMD29cviAFzzhdUxf64ONmphjRT3mWYBYEBt5WoB esDtEYjFSNhrfWOfk3IDqU89gWA0X5JM9yn/Evjt+tXURkXc/0Uy69ag1y1Oz1F0Cj/p yBppaF4cHRr8bgxMGhOSb76ertbHGPEV9uau5lRyb90Uww9Bj0ZlrsTcjf4E9PE6ZBiB QEuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683131021; x=1685723021; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vzHI3ullvefyVTG0SdBYkfi0vgpH6y5dJTpCTjKEKoU=; b=LGLwGSOv4CVysbq/I7aIPBSmZLfqKL3H4BxgBYlxou9xppl9uNyp++066vtHq8MOGD aHQxnra2eyETM3IQSxZhyu6ZC4a7eulBsXJX6vAvH9cV4kMQoliMqKncvmj/y1tJwOeG Kg8VnY+J592qo8mywRdx/vwYFi6d7RkuV12bqqJXRXXMlPOdkMLdZN3Nrwc8aQHfhRhP PLNZSZvZBx3AQ0BRbnKeNapRc8hSowBNYzsiianOrsW2v6Y8vmH+H/mybvqqnWTYVpE6 rxHcfLMxNvsQVIoKP+W+RHDVRY+z+PPiXj5dSYfMEK8kU8XzcqIH33Bym9/VDoUArKIH F+gw==
X-Gm-Message-State: AC+VfDzOkTZGMvyRC93hCcQM9uwTsMATddYXsMhXt9Z+LV6m8Ix82wsz E4FryohpF/2ETO4UFc9UHlXOmvoSP1oSLtQGozRJFcKO
X-Google-Smtp-Source: ACHHUZ6ptpT+wiKm1qeLuTP3CaWkxnYPEO2XOpLWEbF9hWOg76H1E4hUQyf93CcBlFWyrS9/mJkfaEkzX1ZIgCHXomI=
X-Received: by 2002:a17:907:1c82:b0:94f:2d5f:6949 with SMTP id nb2-20020a1709071c8200b0094f2d5f6949mr4285633ejc.42.1683131020720; Wed, 03 May 2023 09:23:40 -0700 (PDT)
MIME-Version: 1.0
References: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl>
In-Reply-To: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 03 May 2023 12:23:28 -0400
Message-ID: <CAF4+nEF_9BaaYYjtDH=vUwximYvh2w9uECujYw6G_EYzms_uSw@mail.gmail.com>
To: Benno Overeinder <benno@nlnetlabs.nl>
Cc: DNSOP Working Group <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000099be5705facc7a01"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EN5XvNCYrLmIQ5j9G1hLrkkZoX0>
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: Wed, 03 May 2023 16:23:44 -0000

I've been around in DNS for quite a while.

The way I've always heard "lame delegation" used is in the sense of a
useless parent NS record at a delegation point. Note that "delegation" is
singular. The usual case is that the server name in the NS RR is a
non-existent name or has no address associated with it or, if it does have
an address, there is no DNS server there. If an NS RR at the delegation
point has an existing name that resolves to the address of a DNS server,
its lameness is getting pretty mild but if that server can't answer
authoritatively, then I guess it really is still a lame delegation...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com


On Thu, Apr 27, 2023 at 4:05 PM Benno Overeinder <benno@nlnetlabs.nl> wrote:

> Dear WG,
>
> The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion
> on lame delegation did not find consensus, but two specific suggestions
> were put forward.  We would like to include one of them in rfc8499bis if
> we can get consensus to do so.
>
> The chairs are seeking input on the following two suggestions:
>
> * Either we leave the definition of “lame delegation” as it is with the
>    comment that no consensus could be found, or
>
> * alternatively, we include a shorter definition without specific
>    examples.
>
> 1) Leaving the definition of lame delegation as in the current
>     draft-ietf-dnsop-rfc8499bis, and including the addition by the
>     authors that:
>
>     "These early definitions do not match current use of the term "lame
>     delegation", but there is also no consensus on what a lame delegation
>     is."  (Maybe change to ... no consensus what *exactly* a lame
>     delegation is.)
>
> 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".
>
> The chairs ask the WG to discuss these two alternative definitions of
> the term "lame delegation".  We close the consultation period on
> Thursday 4 May.
>
> Regards,
>
> Benno
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>