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

Peter Thomassen <peter@desec.io> Tue, 02 May 2023 15:09 UTC

Return-Path: <peter@desec.io>
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 572F6C151B38 for <dnsop@ietfa.amsl.com>; Tue, 2 May 2023 08:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, 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=a4a.de
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 tdTKNAG2LXnf for <dnsop@ietfa.amsl.com>; Tue, 2 May 2023 08:09:23 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75466C1522D9 for <dnsop@ietf.org>; Tue, 2 May 2023 08:09:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z2zO62xENPJJ0+HGlZGPUiVPhpsZR/X+9YhO3+DCym4=; b=OTpzwKyYvHGvbCJxRIpUMQMjFK LKHlF6CZjUrf41vjOGutQorqkBQEZ/nJSGuV1lAmwwuBrDi0uTMXAcEpAHPbNVIUBq0FlDQ4IomgD JYoPRikfCQPU59qz1waMvkzfL4/Cy0cyUWlYXfM7jGB0CtZChVaxmMbpQ2mZ5NOX1PoX+XHqct8bz qCFCNuwB09zLUrIGi9w5SjHZ+sdOWkU2MEOpaUKoFlLaAfg4tgxiHSGe6s2l1mT/gT+dEsDuy5ZFR lViV9n5mj7qxeaTDHmHOQPjxjVwNJddjhJpO2I+WbhXXzEaWyfhmabUzwXEfM9iAtebtevvn1gnjD u4G0+ZPw==;
Received: from [90.187.67.221] (helo=[192.168.188.94]) by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1ptrd2-00G7qK-8U for dnsop@ietf.org; Tue, 02 May 2023 17:09:20 +0200
Message-ID: <72c4391f-b1c8-3925-2bec-84b057cca577@desec.io>
Date: Tue, 02 May 2023 17:09:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: dnsop@ietf.org
References: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl> <40C193AF-938C-418F-924E-94F4DD358164@icann.org> <B93A0E80-08F8-4FDB-81C2-47C465D8DDB4@verisign.com> <ZFD/zr7Qse5WzIQZ@registro.br> <0f956eb3-7d3e-2258-59f0-d0031c506835@nohats.ca> <e9e8515d-83b3-7b14-55d9-8b96d6acf3c1@desec.io>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <e9e8515d-83b3-7b14-55d9-8b96d6acf3c1@desec.io>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GDyF5MVCXxgAAuzmajO0XXxyZVw>
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 15:09:27 -0000


On 5/2/23 17:07, Peter Thomassen wrote:
> 
> 
> On 5/2/23 17:04, Paul Wouters 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.
>>
>> To me this would not be lame if the NS RRsets are identical. You might
>> have still have a broken server, but if parent and child agrees, I
>> would not call it "lame".
> 
> It's possible I got this completely wrong, but if one of the NS answer authoritatively, then it doesn't serve a proper NS RRset, so it's not possible for that server's response to agree / be identical with that on the parent side. As a result, the delegation (to that server) is lame, no?

Excuse me, there was a fatal typo; I meant:

If one of the NS answers non-authoritatively, then it doesn't serve a proper NS RRset, so it's not possible for that server's response to agree / be identical with that on the parent side. As a result, the delegation (to that server) is lame, isn't it?

Best,
Peter