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> Fri, 12 May 2023 02:25 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 90E9AC17DEEA for <dnsop@ietfa.amsl.com>; Thu, 11 May 2023 19:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_BLOCKED=0.001, 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="CYPjDFzp"; dkim=pass (1024-bit key) header.d=isc.org header.b="KoGGJLrm"
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 mlxODigraS6v for <dnsop@ietfa.amsl.com>; Thu, 11 May 2023 19:25:21 -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 70B5FC17B351 for <dnsop@ietf.org>; Thu, 11 May 2023 19:25:21 -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 174373AB01F; Fri, 12 May 2023 02:25:19 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 174373AB01F
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=1683858319; cv=none; b=om9xsHFtXAU5EOoIoHs8kCpW0J8r02IJ/wbeGTkPQnySd80ijUGO/nZ2BKvNxPGxp2AMWUW8mcKVbQQuKqp+dKBjhv6HvvPJmBCw4045aC+Y77NWhw6I9zF6CD0N6egGD6/xB+zaV4o8dXA6nJV+C3CTeoLk9wCbdAEJFgNotbw=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1683858319; c=relaxed/relaxed; bh=TVd2IrV97D8UBGVgwUpou5IjPjMAQSqutc/L0ABW9H4=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=IfWWYppDl9tpJOo+Vmttc3GiRlsIePV0FIzSZ1FMFTDdY1USG3JrwrAQbT9M4Nam4waeJK3pbh4iAO1KtCd9NxxWfVlm4c9JZEeKkfx6GXsdOvaaCwd2/htQHrFNAk0J+JzBauxJSZnDB65eyb8Gz3yi0/reh0Pl/Myjk/xfE68=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 174373AB01F
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1683858319; bh=iG+UZy4oMMK/8UHP+ntP/MTkPEkGPJqISzEOT10i4Ts=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=CYPjDFzptQFxy3guCHOcmOE/yApzRiAbgvjfzo9Vx+HuKkWkGr4Y7XJw4NGEKWBoY +wf+6i9WL7mKTZXAv5yI9kGPFr7aqPnCGytCiXp4K3JvQ4EImjlWJqs3gmQNCJE3ai gTHOMqWQnQGE8GBaO1DYbrFKPZE2zEOpSAv072IE=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 06965FEC710; Fri, 12 May 2023 02:25:19 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id AEA53FEC715; Fri, 12 May 2023 02:25:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org AEA53FEC715
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1683858318; bh=TVd2IrV97D8UBGVgwUpou5IjPjMAQSqutc/L0ABW9H4=; h=Mime-Version:From:Date:Message-Id:To; b=KoGGJLrmSkT96jo621CLPkW5YIafXvS3ZXHoAxvVTP2/+EKl/+pYFaRKWwfkmu44j 0GGVE8LSrVKvG0DSTNl4B5BB6UORKzc+KWejssP6JA9+OJmBqpPyH7YOGnzKRHvlOt txjh3Dqa9sJt2fb62lLmBTiT035oTkNWv6saNHgQ=
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 rE6gu8DPxbK2; Fri, 12 May 2023 02:25:18 +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 03BA8FEC710; Fri, 12 May 2023 02:25:17 +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: <331e7b86-dc5c-5589-9cbb-b3331bc972b8@taugh.com>
Date: Fri, 12 May 2023 12:25:17 +1000
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <54FE973E-0F74-4E6A-A8A6-049DEBB4C264@isc.org>
References: <20230512013510.2ACD2D670AF9@ary.qy> <A7E2E387-559B-4623-8218-887ED583F57E@isc.org> <331e7b86-dc5c-5589-9cbb-b3331bc972b8@taugh.com>
To: John R Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ApE9Ye3riE2Se3NbhRvHp2WLHzw>
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: Fri, 12 May 2023 02:25:26 -0000


> On 12 May 2023, at 12:09, John R Levine <johnl@taugh.com> wrote:
> 
>>> Yeah, that's a better way to put it. But the main point still stands,
>>> that it would be a signficant operational change to insist that all
>>> delegated NS be active when delegated, and even moreso to insist that
>>> they continue to be active.
>> 
>> No, it is not a “significant” change.  It should just be a minor extension
>> of the existing requirement to keep the NS and glue records consistent.
>> 
>> Even if it was you just introduce it with a soft start.  Just start checking
>> the delegations of every TLD like zone then report the broken servers
>> publicly and email the contacts for the delegation.  The tools for checking
>> already exist.
> 
> Well, OK, you do that, half the emails bounce, half of what's delivered is reported as spam, and the third half are ignored.  Now what?

In practice it isn’t quite as bad as that.  Require registrars to refuse
renewals until the issues are addressed.  This is no different to not getting
your car’s registration renewed until it has past its safety inspection.

Mark

> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

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

v2.29.0 | Report a Bug | By Email | System Status