IETF Logo Mail Archive

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

Edward Lewis <edward.lewis@icann.org> Wed, 03 May 2023 15:53 UTC

Return-Path: <edward.lewis@icann.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 B39D9C151B3D for <dnsop@ietfa.amsl.com>; Wed, 3 May 2023 08:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 k1QQpuf6oeSt for <dnsop@ietfa.amsl.com>; Wed, 3 May 2023 08:53:46 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C591C151B33 for <dnsop@ietf.org>; Wed, 3 May 2023 08:53:46 -0700 (PDT)
Received: from MBX112-E2-VA-2.pexch112.icann.org (out.mail.icann.org [64.78.48.206]) by ppa3.lax.icann.org (8.17.1.19/8.17.1.19) with ESMTPS id 343Fri0E021921 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 May 2023 15:53:45 GMT
Received: from MBX112-E2-VA-1.pexch112.icann.org (10.217.41.128) by MBX112-W2-VA-1.pexch112.icann.org (10.217.41.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Wed, 3 May 2023 11:53:43 -0400
Received: from MBX112-E2-VA-1.pexch112.icann.org ([10.217.41.128]) by MBX112-E2-VA-1.pexch112.icann.org ([10.217.41.128]) with mapi id 15.02.1118.026; Wed, 3 May 2023 11:53:43 -0400
From: Edward Lewis <edward.lewis@icann.org>
To: John Kristoff <jtk@dataplane.org>, Paul Hoffman <paul.hoffman@icann.org>
CC: DNSOP Working Group <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
Thread-Index: AQHZfEdVMSj5aSgVMk6ohA6CQQJHHa9F5rGAgALPmIA=
Date: Wed, 03 May 2023 15:53:43 +0000
Message-ID: <4EAA6C18-C47C-4628-85E9-08BB3A4F47FE@icann.org>
References: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl> <40C193AF-938C-418F-924E-94F4DD358164@icann.org> <20230501115805.5b4e5115@dataplane.org>
In-Reply-To: <20230501115805.5b4e5115@dataplane.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.65.22091101
x-originating-ip: [192.0.47.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <2ADAEE3E3DD2FE4599EEFCDDA0E83564@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-05-03_10,2023-05-03_01,2023-02-09_01
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fRi5qstRIFCMknIYzguLpXRMt00>
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: Wed, 03 May 2023 15:53:50 -0000

On 5/1/23, 12:58 PM, "DNSOP on behalf of John Kristoff" <dnsop-bounces@ietf.org on behalf of jtk@dataplane.org> wrote:

    On Mon, 1 May 2023 16:09:23 +0000
    Paul Hoffman <paul.hoffman@icann.org> wrote:

    > It would be grand if a bunch more people would speak up on this
    > thread.

    I'm not particularly satisfied with the requirement that there must be
    a response to meet the definition, but that seems to be the consensus
    even if most seem to agree it is imperfect.  I won't derail.  Until
    someone comes up with better terminology, I'm likely still going to
    refer to all those many cases we see in operation (usually due to a bad
    configuration) as a form of lame delegation when a delegation is
    effectively broken. :-)

When there is a timeout situation, there can be no conclusion about the remote end's status.

It could be that the remote end is properly set up to answer for a zone, but queries to the server are dropped on the way there.  Or responses dropped on the way back.  Or that the timeout is simple too quick.  The timeout may have nothing at all to do with the remote end.

v2.23.0 | Report a Bug | By Email