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

Mark Andrews <marka@isc.org> Thu, 04 May 2023 23:49 UTC

Return-Path: <marka@isc.org>
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 35B66C152D87 for <dnsop@ietfa.amsl.com>; Thu, 4 May 2023 16:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (1024-bit key) header.d=isc.org header.b="jaLrBsg7"; dkim=pass (1024-bit key) header.d=isc.org header.b="AgLPeaAb"
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 Hhbh4q7VFSIR for <dnsop@ietfa.amsl.com>; Thu, 4 May 2023 16:49:41 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 AB53DC151B05 for <dnsop@ietf.org>; Thu, 4 May 2023 16:49:41 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 0EE783AB20E; Thu, 4 May 2023 23:49:40 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 0EE783AB20E
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.1.12
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1683244180; cv=none; b=o09+8pYDu7Dd9xNHXxAtxc4agLu7onr/FHmwkYPfmXiyHbM6SZfRv4nT3+ydCgIETZYHCJshY2GG30hbgf5BHxqzx1LjItgvlDBjK7X7Fb/9ibJp8MYGgUSNsYqUkW6GW88bXy/HwVl07VrKRGIND60+IFUEBtSF1vFULLxA2HQ=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1683244180; c=relaxed/relaxed; bh=Qnzx01k4UfArz4LfO/z3eDuvTnkdhl8QSD1RlMT/5iQ=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=P2BZ8Nh3nRQvOcaGn+THa9ppQtpqDxgq9ke+lL0aZy/ZA59jd58pJ4GhQWvaMVIkFZH3CL0dGfplPek7X5Xfzw1PwXIfoYU3hNaefvSlZy9DFQPnU9XOT3fzEDkTLV1qqBsMXLBKAkRuA9i+/8rqhHMcryPyuGHEzmEdsqT7u2Q=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 0EE783AB20E
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1683244180; bh=4QFnSsKqgttnuXqFKXHSgrCwx+XDbpVZQS1flhD2uII=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=jaLrBsg7OiiteIKZqmXLcDR+6m/YXXcVoGqer6fyDQQF0sFivyb+A9Nu2Fk7INo/I YtVgiWPJ6NPLCkzX9CGD40prETBLBa+woz6i0rjEvdmwrqBvDCsiQN132pkhXa2SZv CYmI75H2e/cKHpQ4pGjmZaa9gPQbAbBzNvCH3TVw=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 04051B868DB; Thu, 4 May 2023 23:49:40 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id CE3F1B868DC; Thu, 4 May 2023 23:49:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org CE3F1B868DC
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1683244179; bh=Qnzx01k4UfArz4LfO/z3eDuvTnkdhl8QSD1RlMT/5iQ=; h=Mime-Version:From:Date:Message-Id:To; b=AgLPeaAbjZ+jvC+XUOhgrb+iVrEEpfiMfFP73/LLNWxJXAJtmyrTzQDrGPIoSYtIx OLdxyd4V46ibxCjwovZXJVBSXyiVG00S2eNJx9xgeOLAx99p82nlaxsNJmLT06RjvG 0XGDzLgnJ+U+jl6OtEECPh3flaIc6pSn+z0sIY+c=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id blcRSCAEo6Px; Thu, 4 May 2023 23:49:39 +0000 (UTC)
Received: from smtpclient.apple (n49-187-27-239.bla1.nsw.optusnet.com.au [49.187.27.239]) by zimbrang.isc.org (Postfix) with ESMTPSA id B35BCB868DB; Thu, 4 May 2023 23:49:38 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAHw9_iLyz4dhjmXm=eeqiVqQWOjYOgs45NbCtRtvrYpTFQHz=w@mail.gmail.com>
Date: Fri, 05 May 2023 09:49:27 +1000
Cc: Mark Delany <m9p@india.emu.st>, DNSOP Working Group <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0645EF4E-21C4-4D16-AFE7-D57054F7992C@isc.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> <1C10367C-B890-426F-A4F8-2D68E903ED39@icann.org> <0.2.0-final-1683191254.797-0xa08e34@qmda.emu.st> <CAHw9_iLyz4dhjmXm=eeqiVqQWOjYOgs45NbCtRtvrYpTFQHz=w@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4oln4El0XMrFeo8mVbYCd9ctWi4>
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: Thu, 04 May 2023 23:49:47 -0000


> On 5 May 2023, at 03:01, Warren Kumari <warren@kumari.net> wrote:
> 
> 
> 
> 
> 
> On Thu, May 04, 2023 at 5:07 AM, Mark Delany <m9p@india.emu.st> wrote:
> On 03May23, Edward Lewis apparently wrote: 
> Was any "lame" situation defined which wasn't the result of a bad configuration? 
> The difference between observing a symptom and diagnosing a cause is great. I say this to caution against tying the "why it is" with 
> "what it is."
> This is a good point. 
> I confess my perspective is that of the DNS admin/serving side focussed on "why it is" whereas lameness is most often observed as a "what it is" from the resolution/client-side perspective. To use your useful terms. 
> I have one last question. Regardless of whether we agree precisely on what "lame" means, what is the call to action when a zone or its name servers are declared lame?
> 
> There doesn't need to be a call to action — I can say "my car squeals when going round a corner" - "squeals" is a way to describe the noise, and it's just an observation, just like "a-random-test-domain.net is a lame delegation". I own both "a-random-test-domain.net" and "my car" - unless the squealing / lameness impacts you, I don't think that there (or needs to be) is a call to action on either. 
> 
> And how is that different from any other form of miscreant auth behaviour such as inconsistency?
> 
> Well, for one thing, it's not always "miscreant auth behavior" (by which I'm assuming you mean misbehavior by the auth server / auth server operator).
> 
> As an example, it's quite common for people to register a domain and point the DNS at some nameservers which they don't control, and have no relationship with. This is not "miscreant auth behaviour" by the auth operator - they were not involved, and also have no realistic way to deal with the issue. 
> 
> If we did want to have a call to action" we could publish something saying that pointing a domain at a name server that isn't "yours" is uncool, but I don't really know how effective this would be… 

Pointing a NS record at a nameserver that doesn’t serve the zone with the intention of causing DoS traffic at it is a criminal act in most jurisdictions (intentional financial harm or some such).  Aiding and a abetting a criminal act is also a criminal act.  Not having a process to remove NS records pointing at servers that don’t serve the zone could be seen as aiding and abetting.  This is not to say that all cases of NS records that point at servers that don’t serve a zone are criminal acts but just treating it as “uncool” is uncool.

> W
> 
> 
> 
> I mean if "lame" is a precious historical term that warrants considered clarification, surely it has a very specific value that we can all act on, right? So what is that very specific value? 
> Mark. 
> _______________________________________________ 
> DNSOP mailing list 
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org