IETF Logo Mail Archive

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

Mark Andrews <marka@isc.org> Thu, 11 May 2023 23:30 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 1C1EBC19E0FD for <dnsop@ietfa.amsl.com>; Thu, 11 May 2023 16:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.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_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="qK/Qq+pO"; dkim=pass (1024-bit key) header.d=isc.org header.b="hmCvvPm2"
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 yBAq-88Ps2Lb for <dnsop@ietfa.amsl.com>; Thu, 11 May 2023 16:30:15 -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 4CA35C17EE3F for <dnsop@ietf.org>; Thu, 11 May 2023 16:30:14 -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 492763AB01F; Thu, 11 May 2023 23:30:13 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 492763AB01F
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=1683847813; cv=none; b=IpryVQtBQtr44KRIKQyy2fsfUonko6aiCl0WTZ96BpYoAFH0fDCTrSEgRTMWS7aMk7Le5MjWcakTpXB1tQ3fHA41PNsFVR4QLRzX4jtXBN83J3ISyNxZJzv56kk3U6wvpBHwpQzBZMNm1VRjx4sinMylID/pQLBtMbdX8MDakDE=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1683847813; c=relaxed/relaxed; bh=NMBbaYbZFlALoMWl4f3R3PlVCg0AOPZVpqNbNzJGLJc=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=jj+URABLi17UxQRDivOaKWutfs0tWIj2uIs0fxUPsy2aDvOwsulu2Ly3R/BVG2jbSRgpbEzjTHjdEKEyd/6DVC0qFNCFhxOWTHECgdOjY5gbTyUKLZ9zTYBlgxKFe3I3RV1yglIsuikv25s9E8hN+oUFHfgczsmYf6z7ZNvMmtI=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 492763AB01F
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1683847813; bh=a+EeKCO8c4nzu5lPdswqgQg7eKCuxAQwGZHBL2eRYAI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=qK/Qq+pO8gtU/448XWTrtJjzmW8H4CF+oqnh11Ti/uFz6p6AuaZ4orVdf/DwpzH4/ eJnR+WxN6DfyV40Sodmgpwx9HihGhSMJFcr4YcZnVcszsUcOTU1OD7RjeMgiQAY+zt ForcqL1UF9QxjBBO+9E5BEuXz95srBPVNxFoXJNs=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 2AA22FEC59C; Thu, 11 May 2023 23:30:13 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id C31C3FEC676; Thu, 11 May 2023 23:30:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org C31C3FEC676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1683847812; bh=NMBbaYbZFlALoMWl4f3R3PlVCg0AOPZVpqNbNzJGLJc=; h=Mime-Version:From:Date:Message-Id:To; b=hmCvvPm2kjdRAEZjxoN96YJdemFbQFTYIcA9gJQVvedQpKQ1cvaPy7f5/Xqiox8do D6i/zD9zT3GrSQ6dHOWJHTMsIGiWxaGiS/b8AJzvJEYh99jjv2F9UlhNa+ycg3Ywc3 xU16iOk1/b369MSIwWu+OAfB/pL8wlW9TnWo+k90=
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 gJ9B9Wr0vMTa; Thu, 11 May 2023 23:30:12 +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 C10A5FEC59C; Thu, 11 May 2023 23:30:11 +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: <20230508171325.0616DD2FF5B0@ary.qy>
Date: Fri, 12 May 2023 09:30:09 +1000
Cc: DNSOP Working Group <dnsop@ietf.org>, kim.davies@iana.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <728744CF-9FD2-4B0A-8BC2-9CD00F3A619C@isc.org>
References: <20230508171325.0616DD2FF5B0@ary.qy>
To: John Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KkUnzbLkrKT1er18g4AefS3yXVQ>
Subject: Re: [DNSOP] Delegation acceptance checks [was: Re: [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, 11 May 2023 23:30:19 -0000


> On 9 May 2023, at 03:13, John Levine <johnl@taugh.com> wrote:
> 
> It appears that Kim Davies  <kim.davies@iana.org> said:
>> With that said, I think the root zone is probably not an instructive
>> use case for the broader question. Unlike typical zones, at the root it
>> can be said every delegation is to critical Internet infrastructure and
>> therefore the calculus around process complexity and efficiency would be
>> weighted differently.
> 
> Oh, I completely agree.  My point was just that even in the root which is small and you
> would hope would change slowly, it's still a challenge to track what's lame.

It’s not a challenge to track what is lame.  It’s dead simple.  You just have to look.  Getting
it addressed is the challenge.

https://ednscomp.isc.org/compliance/tld-fullreport.txt has been generated daily for the last
5 years and the broken behaviours have stood out like sore thumbs the entire time.  It only takes
a couple of minutes to generate that report and that isn’t trying to go as fast as possible.

> R's,
> John
> 
> _______________________________________________
> 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

v2.23.0 | Report a Bug | By Email