Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Patrick Mevzek <mevzek@uniregistry.com> Thu, 30 July 2020 21:55 UTC

Return-Path: <mevzek@uniregistry.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 93EAE3A0D55 for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 14:55:19 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uniregistry.com
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 Nuk7tsxXru62 for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 14:55:17 -0700 (PDT)
Received: from a-mx.uniregistry.com (a-mx.uniregistry.com [64.96.177.8]) (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 9CF053A0D54 for <dnsop@ietf.org>; Thu, 30 Jul 2020 14:55:17 -0700 (PDT)
Abuse: Forward to abuse@uniregistry.com with full headers
X-Virus-Scanned: Content filter at a-mx.uniregistry.com
Powered-By: https://www.uniregistry.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniregistry.com; s=bravo; t=1596146116; bh=kCI2dbof+fmA89M2wVgOSdbcZ0qNBCuBUtkjScEUv74=; h=Subject:To:References:From:Date:In-Reply-To; b=d3LQvjoIQ7aIqnjxbZfmmIcAaZFiQd7rCAafOljMev0aUBaJ91qRnX7QfGfeZvoFI yDWwBxL6uZYeZP5Iq5tLRytveWyIECwQG6Y0phfwcvQ3fNvPxd8/WNHciVWB625pBG SwaqNfD0iWomPlIV1tcb8mBXRqQ3WlHq1d5WXpcN6SCp5Bh96wAcieL4+e56MA1nZO CUBZFLdDd2yeXo2Ej13R+zOf0sGWh+A8A50g79Sv6TJ7QBvGtUkqn0DM4msioDHhli wx+7smjr7MgO4nU8PN+1uhg06Cv1CCZ6fBqR7E466MSWHClxvJtQ8BZcae3LjdP/IW bE7QMQWNjiBbg==
Received: from [10.8.204.86] (b01.uniregistrar.net [52.204.70.64]) (authenticated bits=0) by a-mx.uniregistry.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 06ULtEmA002819 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 30 Jul 2020 21:55:15 GMT
To: dnsop@ietf.org
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com> <05f9f7ce-1bb7-b195-1be5-4db4c13b3145@nic.cz> <alpine.LRH.2.23.451.2007301253530.416340@bofh.nohats.ca> <F16107A1-669C-41AD-9F59-1794C64B0737@hopcount.ca> <alpine.LRH.2.23.451.2007301446380.418549@bofh.nohats.ca> <31548781-6B30-4198-810F-32245590C7D6@hopcount.ca> <CAH1iCiouWAjSQnmkH5tVXQThyRUX3SSGOi1qOUhFw__AUG75nA@mail.gmail.com>
From: Patrick Mevzek <mevzek@uniregistry.com>
Organization: Uniregistry
Message-ID: <c22935a2-397a-754c-8da5-bc30aab18e7d@uniregistry.com>
Date: Thu, 30 Jul 2020 16:55:14 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAH1iCiouWAjSQnmkH5tVXQThyRUX3SSGOi1qOUhFw__AUG75nA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jyYadPqBePTYi71lZHGPaxZJ3PA>
Subject: Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
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: Thu, 30 Jul 2020 21:55:20 -0000

On 30/07/2020 15:44, Brian Dickson wrote:
> 
> 
> On Thu, Jul 30, 2020 at 1:21 PM Joe Abley <jabley@hopcount.ca 
> <mailto:jabley@hopcount.ca>> wrote:
> 
> 
>     $ORIGIN ORG.
> 
>     BADDOMAIN NS ...
>     BADDOMAIN NS ...
>     NS1.BADDOMAIN A 192.0.2.1
> 
>     GOODDOMAIN NS NS1.BADDOMAIN.ORG <http://NS1.BADDOMAIN.ORG>.
>     GOODDOMAIN NS ...
> 
>     If BADDOMAIN.ORG <http://BADDOMAIN.ORG> is suspended (or if the
>     domain is suppressed for some equivalent reason) then the zone cut
>     betwen ORG and BADDOMAIN.ORG <http://BADDOMAIN.ORG> will be removed
>     (the BADDOMAIN.ORG <http://BADDOMAIN.ORG> NS set will disappear) but
>     the A record above will remain, since it is linked to another
>     domain, GOODDOMAIN.ORG <http://GOODDOMAIN.ORG>, that depends upon
>     it. Without a zone cut, that makes the ORG servers authoritative for
>     the A record.
> 
>     To a certain extent, this behaviour is a consequence of (a) the
>     venerable operaetional need to suspend domains because they have
>     been implicated in abuse and (b) the EPP data model used in the ORG
>     registry, which itself has its origins in the RRP data model used
>     before the re-delegation of ORG to PIR in 2002. As such, it's
>     tempting to assert that the behaviour is a contractual requirement
>     shared with all other gTLDs that are operated subject to the same
>     contract that exists between PIR and ICANN, hence my question about
>     applicability.
> 
> 
> Yes, this does appear to be driven by EPP (the data model and the RFCs 
> for said),

Only if you take the "hosts as objects" case (where any hosts to be used 
as to be provision like a domain but by just providing, in some cases, 
some IP addresses), which is only one of the two, the other being "hosts 
as attributes (of a domain object)"

The problem is similar to the following:

- registrar A is sponsor of domainA.example
- this domain has (not necessarily using them) hosts 
"ns1.domainA.example" and "ns2.domainA.example"
- at some point, registrar B creates domainB.example ...
using ns1.domainA.example and ns2.DomainA.example

Now, registrar A CAN NOT delete domain domainA.example anymore because 
it has "child" nameservers used elsewhere and if he could do that we are 
back to the "orphaned glue records" problem.
It can not for the same reasons delete the nameservers themselves, just 
update their names or IP addresses.

There are various solutions, all bad in some aspects:

- let the registrar A eat the bill (of domainA.example being renewed 
forever) and that is all
- convince registrar B to change the delegations (and no matter what 
amount of garbage you put in the zone server by those nameservers it 
would still not guarantee anything is changed)
- have nameservers be changed in their hostnames, so that after the 
domain can be deleted as not having child nameservers anymore; this 
works only in the "hosts as objects" case above and not always as change 
of hostname is not implemented by all registries or with restrictions 
like not internal->external renaming
(which is also a major arguments by registrars to dislike the hosts as 
attributes case)
- have the registry let the domain be deleted and then have domainB be 
broken (which it is already in a way since the delegations to those 
nameservers can be explicitly made broken; but the difference is between 
registrar A breaking registrar B stuff, or the registry breaking 
registrar B stuff).

> However, is it appropriate to discuss the requirement or request to have 
> the EPP spec (and contracts) changed, as a topic for DNSOP?

The above problems, for me, are only loosely related to EPP.
You could use any other provisioning protocol (if it existed) and have 
the same problem of DNS management.
The problems comes more from having a single space (the registry 
zonefile) be managed by multiple actors (registrars), collaboratively 
but also in competition.

> Or does anyone know if more recent contracts include similar language, 
> and what rough order of magnitude of contracts would be impacted?
> E.g. If the number of contracts is O(12), vs O(1000), the conversation 
> is likely to be very different.

See my other message where I quote ICANN resources where this question 
is part of the application of any 2012-era gTLD operator.


-- 
Patrick Mevzek