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

Kim Davies <kim.davies@iana.org> Mon, 08 May 2023 16:30 UTC

Return-Path: <kim.davies@iana.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 87F8FC13AE5D for <dnsop@ietfa.amsl.com>; Mon, 8 May 2023 09:30:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 dRaNERZCxj-f for <dnsop@ietfa.amsl.com>; Mon, 8 May 2023 09:30:36 -0700 (PDT)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (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 28DE3C13AE58 for <dnsop@ietf.org>; Mon, 8 May 2023 09:30:36 -0700 (PDT)
Received: from KIDA-9190.local (unknown [10.32.60.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lax.icann.org (Postfix) with ESMTPS id 49108E54B9; Mon, 8 May 2023 16:30:35 +0000 (UTC)
Date: Mon, 08 May 2023 09:30:33 -0700
From: Kim Davies <kim.davies@iana.org>
To: John Levine <johnl@taugh.com>
Cc: dnsop@ietf.org
Message-ID: <ZFkjqbmf04Is8SJW@KIDA-9190.local>
References: <2abfdd2d-baff-77f6-76b9-b6d0f40739fd@lisse.NA> <20230507045946.9CB9BD017B17@ary.qy>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230507045946.9CB9BD017B17@ary.qy>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SRWKj5RPXAqVw_6CxJRRSNlvmqU>
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: Mon, 08 May 2023 16:30:36 -0000

Quoting John Levine on Saturday May 06, 2023:
> >The IANA Function Operator does so for all ccTLDs (which would imply all TLDs).
> 
> Indeed, but some of them are lame anyway.  Here's today's report:
> ... 
> There are 96 more that timed out but I can't tell whether they really aren't there or it's a temporary network issue.

The IANA tests are only performed in the context of a change request
being processed. The current approach was put in place where there
was sensitivity against IANA monitoring TLDs. A third-party study was
commissioned last year that interviewed TLD operators and recommended
that approach evolve to proactive monitoring, so moving in that
direction is now something we are planning for.

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.

kim