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

Peter Thomassen <peter@desec.io> Tue, 02 May 2023 12:24 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 3E7BEC1524BC; Tue, 2 May 2023 05:24:54 -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 j6UhOxM_2uqv; Tue, 2 May 2023 05:24:49 -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 83F15C1522D9; Tue, 2 May 2023 05:24:49 -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:Subject:From :References:Cc:To: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=k8WHmSnQPWZ9hTQAd488SRNMPkwASwXpnYd0VuwUtwU=; b=GsBYeEBObmTYOdfw46OnQKkeQk AzXKpl5wSMgQegZFlzOqAO0098VhGbEXN9qk3A4T1+6oGRUgriaImCi27cMkdlrj2Vbug7E+tF6RV 7Ojg7+TgE8sMk+PHU7nbZ1KTWuLO0307d3vLIFu6j+7VVM3CwZJqUQzLHJ1ZmxBuoWgf9I3Jo3flU 7WqU+C7DOk1lMTWp2lBQqx9SkHR1xkY0D5sZDcwCSiwhekPWl2vQfme5txONS5AK0XJi3jdJVg5h8 FDZ31smoCQgOlhcjcRXkTs4jQ67bfp5S7sm6QLCAbSUGLl8WtaWZ/WhE63v7WlEinUeCfVDhFSfw4 nTcZSTXg==;
Received: from business-90-187-67-221.pool2.vodafone-ip.de ([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 1ptp3j-00Fx4f-F7; Tue, 02 May 2023 14:24:43 +0200
Message-ID: <2011730a-1206-63fb-bc98-019e53a5ea4a@desec.io>
Date: Tue, 02 May 2023 14:24:42 +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 Vixie <paul=40redbarn.org@dmarc.ietf.org>, Joe Abley <jabley@hopcount.ca>
Cc: m9p@india.emu.st, dnsop@ietf.org
References: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl> <40C193AF-938C-418F-924E-94F4DD358164@icann.org> <20230501115805.5b4e5115@dataplane.org> <0.2.0-final-1682972681.287-0xd4930e@qmda.emu.st> <ovdbVoNO3SETnssmcX_ys9g7p1j9CEsl1VUMNYZgwHj1W-hTDQZPTaSfswmU_LmnYB5Yq0F_oHVjwfJB6z8fcNdg6Zp-YiVEQrZyneEp9Pg=@hopcount.ca> <c5cf66ab-716f-6a9f-1572-444e88a12a6c@redbarn.org>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <c5cf66ab-716f-6a9f-1572-444e88a12a6c@redbarn.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Vp1hc7rOewVCF40yF2jmNXAkK9o>
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 12:24:54 -0000


On 5/1/23 23:22, Paul Vixie wrote:
> to be a lame _delegation_ means some error or misconfiguration in the server. normally this means it's supposed to be authoritative but the zone expired or the operator forgot or similar.

This, so far, was my understanding of the definition that was given in the other thread, and which Benno labeled (2) in the original post of this thread:

    "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".

... without the "or not at all" part (so, an answer is required for "lameness").

> or there is no server there any more (it was decomm'd or renumbered). icmp host-unreach or port-unreach would be symptoms of that, if you can hear them.

"Responses" like "unreachable" are not answers in the DNS sense. Are they meant to be included in "answer[ing] non-authoritatively" in the definition above, or is "answers non-authoritatively" restricted to DNS anwers (e.g. REFUSED)?

> if we need more terms let's invent.

Without asking to invent a term if none exists, I'd like to learn how to call a delegation that points to an NS hostname that does not have an address record (verifiably, e.g. denied by a DNSSEC negative response).

Before the discussion, I thought this qualifies as "lame" (because you can tell from the response that there's no DNS service; it's not a timeout), but with the above definition, it can't be called "lame".

Thanks,
Peter

-- 
https://desec.io/