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

Hugo Salgado <hsalgado@nic.cl> Thu, 06 August 2020 17:27 UTC

Return-Path: <hsalgado@nic.cl>
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 D70B53A0D34 for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 10:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 E1T5C73tMKBv for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 10:27:26 -0700 (PDT)
Received: from mail.nic.cl (mail.nic.cl [IPv6:2001:1398:1::6008]) (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 52BCC3A0D2C for <dnsop@ietf.org>; Thu, 6 Aug 2020 10:27:25 -0700 (PDT)
Received: from mail.nic.cl (localhost [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 2A925195D5CDF for <dnsop@ietf.org>; Thu, 6 Aug 2020 13:27:23 -0400 (-04)
Received: from pepino (hsalgado-vpn.intra.nic.cl [172.30.14.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.nic.cl (Postfix) with ESMTPSA id 069A6195D5C9A for <dnsop@ietf.org>; Thu, 6 Aug 2020 13:27:23 -0400 (-04)
Date: Thu, 06 Aug 2020 13:27:21 -0400
From: Hugo Salgado <hsalgado@nic.cl>
To: dnsop@ietf.org
Message-ID: <20200806172721.GF67784@pepino>
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> <c22935a2-397a-754c-8da5-bc30aab18e7d@uniregistry.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="2FkSFaIQeDFoAt0B"
Content-Disposition: inline
In-Reply-To: <c22935a2-397a-754c-8da5-bc30aab18e7d@uniregistry.com>
X-Virus-Scanned: ClamAV using ClamSMTP on Thu Aug 6 13:27:23 2020 -0400 (-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/emFdmYl_hL5QtEJPRrmbpVLhlgY>
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, 06 Aug 2020 17:27:28 -0000

On 16:55 30/07, Patrick Mevzek wrote:
> 
> 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)"
> 

.CL uses "hosts as attributes".

> There are various solutions, all bad in some aspects:
> 
[...]
> - 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).

And this approach. When DomainA is deleted/deactivated, its
nameservers are gone in the .cl zone, together with their
glues. Nameservers ns1.domainA.example and ns2.DomainA.example
are deleted from DomainB's NS set too, because there's no DomainA
anymore... and so we keep .cl consistency.

So we can say .CL is truly delegation-only. But we know there're
only a handful of registries using hosts-as-attributes.

Hugo