Re: [DNSOP] New draft on delegation revalidation

John R Levine <johnl@taugh.com> Tue, 14 April 2020 01:48 UTC

Return-Path: <johnl@taugh.com>
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 0C31D3A2302 for <dnsop@ietfa.amsl.com>; Mon, 13 Apr 2020 18:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=mkRH7hVx; dkim=pass (1536-bit key) header.d=taugh.com header.b=M+5iknFx
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZpN0ZA4TTIZ for <dnsop@ietfa.amsl.com>; Mon, 13 Apr 2020 18:48:04 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 0CF893A2301 for <dnsop@ietf.org>; Mon, 13 Apr 2020 18:48:03 -0700 (PDT)
Received: (qmail 93372 invoked from network); 14 Apr 2020 01:48:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16cba.5e951653.k2004; i=johnl-iecc.com@submit.iecc.com; bh=HFwyl8YT0uESYQfUGPiqHB20Zgy8WiB9da4QmQUDVmY=; b=mkRH7hVxIOrWBQ1EeZReD0uDMFh1PANNxZe/HZdRWT8uKuYOtO4B5tHA+hrpnDVVFMuzbQ6mmdq89D9sr50wn4z9lEwC2IT8K1Io4woLV/UnBdBGae8Zwx1bB3ofc+jZl3leX5t4gsIMgQylYmZj4dcBDtXEdOvh1IoA3mvFaOcq+v0mY/9tUxJqj2vrkjW/7LvGg+ljr9LRP55eCck6oOEfv9/ZnGn4PEhUh5Zpqba8kRRqaHgeA5TQznJmOzoA
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16cba.5e951653.k2004; olt=johnl-iecc.com@submit.iecc.com; bh=HFwyl8YT0uESYQfUGPiqHB20Zgy8WiB9da4QmQUDVmY=; b=M+5iknFxl+wGJ7ZEfy4RP/CRFdiLyaghrNDhUNpZQyWYXVoAVpQqiZoSTPoxv4Rz2acvi3fxfMZSdNNSqU4eMRPstYMfaJl1rrLzJApESdrAxLWbYqfzSegpBa5C7t3ItCSOIy4EzNI4d1NVQFQZ7mbk/lCGWkZ68br4uMgreX7ahzewXZTUMpqOr3jG1WgHaXs1kqCkYvx+yQyqi5zxjbHNVNm8lSfnHRXcku+klyTUQ/3brWopAOp6MFPZwdo5
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 14 Apr 2020 01:48:02 -0000
Date: Mon, 13 Apr 2020 21:48:02 -0400
Message-ID: <alpine.OSX.2.22.407.2004132141560.7454@ary.qy>
From: John R Levine <johnl@taugh.com>
To: Mark Andrews <marka@isc.org>
Cc: dnsop@ietf.org
In-Reply-To: <CB12A179-1ED4-49D3-A7C0-785FED697805@isc.org>
References: <20200411175736.A4EBC1774BAF@ary.qy> <CB12A179-1ED4-49D3-A7C0-785FED697805@isc.org>
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-2144956452-1586828882=:7454"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xaIiDjZjWCrOCFG2jvsaqzpd4dU>
Subject: Re: [DNSOP] New draft on delegation revalidation
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 14 Apr 2020 01:48:06 -0000

>> Remember that in ICANN contracted TLDs and in some ccTLDs, a registry
>> can only contact registrants by going through the registrars.
>
> So they sent the notices via the registrar.  There is nothing preventing
> that.

Actually there is -- there's no mechanism to do so.  Registries and 
registrars communicate with EPP, and it doesn't have a "hey your customer 
is lame" feature.  You can propose an EPP extension in the regext WG but I 
wouldn't get my hopes up.

Also, as I said, some registrars would ignore them, the ones that care can 
check lame NS as easily as the registry can, so what's the point?

> "As the last installation step, the delegation NS RRs and glue RRs
> necessary to make the delegation effective should be added to the parent
> zone.  The administrators of both zones should insure that the NS and
> glue RRs which mark both sides of the cut are consistent and remain so.”

This sort of stuff is not helpful.  We have decades of experience that 
tell us what registries and registrars will and won't do, mostly won't.

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