IETF Logo Mail Archive

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

Peter Thomassen <peter@desec.io> Tue, 02 May 2023 15:07 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 B90B4C151B3C; Tue, 2 May 2023 08:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.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_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 i5VxszFw3cdQ; Tue, 2 May 2023 08:07:44 -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 2D3ADC151B38; Tue, 2 May 2023 08:07:43 -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:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: 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=c7ATjmN+vDwqW5P+HYQX2gytMmII1s2xNFPUuPr2qlc=; b=zFbs/EjpoUJWQceihkJjUODOHS fDDZuS6BHwnruzUPnU+hzXq/HMWKdqUzvt2aJr6qpnmSs9JTdFXkujKyHrCx6yai6AA1SwfT2qubt KEsMDCgSwFHgIvOv8lk0hIXFcSrYCCdOHIlP+WZrAoXAxKVKV45UaGwPYdJtJSaU6xYYLLlklaW7K cKM4pUvaTDqLs5jd/kD/NmuO4FuV7dBdUqCBJHBqo7kBcFEiJVniX6pF5aOoCJFg7kBayNECvmR1Z E0MLRSB0YVeAcsiVqfG5FIJsub7X7Mqi6bzC72IYUSkGfQI6QmxY8kEMnIyKYYmRG+ZEoP9Skl1Fc h5Girg8A==;
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 1ptrbP-00G7jR-A7; Tue, 02 May 2023 17:07:39 +0200
Message-ID: <e9e8515d-83b3-7b14-55d9-8b96d6acf3c1@desec.io>
Date: Tue, 02 May 2023 17:07:38 +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: Paul Wouters <paul@nohats.ca>, Frederico A C Neves <fneves=40registro.br@dmarc.ietf.org>
Cc: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>, Paul Hoffman <paul.hoffman@icann.org>, DNSOP Working Group <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>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <0f956eb3-7d3e-2258-59f0-d0031c506835@nohats.ca>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-PbAXi_QaY_WuOppkc-ferqG9MQ>
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:07:49 -0000


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?

~Peter

-- 
https://desec.io/

v2.23.0 | Report a Bug | By Email