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

Peter Thomassen <> Tue, 02 May 2023 15:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B90B4C151B3C; Tue, 2 May 2023 08:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i5VxszFw3cdQ; Tue, 2 May 2023 08:07:44 -0700 (PDT)
Received: from ( [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 (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;; 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 [] (helo=[]) by with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1ptrbP-00G7jR-A7; Tue, 02 May 2023 17:07:39 +0200
Message-ID: <>
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 <>, Frederico A C Neves <>
Cc: "Wessels, Duane" <>, Paul Hoffman <>, DNSOP Working Group <>
References: <> <> <> <ZFD/> <>
From: Peter Thomassen <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?