Re: [DNSOP] Verifying TLD operator authorisation

Matthew Pounsett <matt@conundrum.com> Fri, 21 June 2019 14:07 UTC

Return-Path: <matt@conundrum.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 F2D06120114 for <dnsop@ietfa.amsl.com>; Fri, 21 Jun 2019 07:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=conundrum-com.20150623.gappssmtp.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 A4bXk6CS4fPI for <dnsop@ietfa.amsl.com>; Fri, 21 Jun 2019 07:07:22 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC91C12026B for <dnsop@ietf.org>; Fri, 21 Jun 2019 07:07:22 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id w25so3267189ioc.8 for <dnsop@ietf.org>; Fri, 21 Jun 2019 07:07:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MhUWhK8KMjwXp/lnzNvWhcvTNY6bIfTMFtba6Pqvv7M=; b=aSixFUis4yhdApHPr3fliRYU58bWduTp36Vua5bxNNBSnjXnfzQCAXav6rj9jVj1dP V+1gM+rqj0e3gXtJXMXmwxUNifOsLc9COrTKKtd/40L5udSxLBHuffHGdo8/T9vm2an/ V03zcHO1AksWR5C3MMhOUrF2JemYWQTAgveQ6NnVHy6SgGJDbOveR9/PpqOxyQyZP186 8KW0X8YoFPl77SXa/NDJ/AjCh87ZCCgfXMlJxSqOEJPxjtgI7Q7JGVkE+/rVuUF0+ilH KyouekDwsHVxw3bUBshIX1vM7p3Amk4RMmz3n5quIqEtdOBJQu7Oie6R9Ci4Ot5q9pWb t6VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MhUWhK8KMjwXp/lnzNvWhcvTNY6bIfTMFtba6Pqvv7M=; b=ix7SHUkwW3JqTukcfX+fHkrZ6Y80r34yl58kOZmxZ1xRHhDdF0vkoCkZNFXn05ekEI en0tzfp5S1Wqp1qRYUtnJfilUuV8YKP7UO3RF/Dzhp1WdkYpUfztv38grcSeYU9hfrD4 VLzVhaxW5eW4o59B0LWC7qrnmH+ys267MNbXJBQrNU1aCyVWO1u18m0UT4gsZbnCA+3D i1GKCZLFGhsFhOt6XA+bfJMrKJmqSm6yXcGz9zO4KdFPO9D/UIy4qXuMewMn1U6LqKeq OeVFWoiRDZFyJIiIHq3giJWeUqXLSLwCK37ZEn5j1UWEOT6SDbMcyDms/ergn12q6yGg ae7A==
X-Gm-Message-State: APjAAAXZ1+IXusA7hCKFrtZ9aV2J73jYM+RcW36DbfbW/hkCBUqIivKw /cXuHwMa+2YWbverMVZtJthy62hyatwvaalOy6SaEujhrUVS9w==
X-Google-Smtp-Source: APXvYqwuybz9hyQdT+Cm2qgDOXHiOA8PjcUhlgJw5HROW7b/O4sIfEzl2ITwLdMSh+RQfsFl/4RItsfB/TSsKmtJ7ik=
X-Received: by 2002:a5e:cb43:: with SMTP id h3mr50208iok.252.1561126041665; Fri, 21 Jun 2019 07:07:21 -0700 (PDT)
MIME-Version: 1.0
References: <CAFz7pMvkQUz78Qow03RsFKHof3nrnGu3BUwUP0zstWgVtP3Msw@mail.gmail.com> <45146059-6b1c-a967-1620-75d3de751e63@time-travellers.org> <CAFz7pMu_QRj-Kdudm6x8=p+gGp9=Eh823Dh+48fGoS4-N3-LxQ@mail.gmail.com>
In-Reply-To: <CAFz7pMu_QRj-Kdudm6x8=p+gGp9=Eh823Dh+48fGoS4-N3-LxQ@mail.gmail.com>
From: Matthew Pounsett <matt@conundrum.com>
Date: Fri, 21 Jun 2019 10:07:10 -0400
Message-ID: <CAAiTEH_X6tcDenqeoe7G-+KLqkGO-_Vyaj37w86z1=mGuBL-hw@mail.gmail.com>
To: Nick Johnson <nick=40ethereum.org@dmarc.ietf.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000029d921058bd5fb8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CbW11tlrEp6w8u7lSLjfwp3Hm9M>
Subject: Re: [DNSOP] Verifying TLD operator authorisation
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: Fri, 21 Jun 2019 14:07:25 -0000

On Sat, 15 Jun 2019 at 19:36, Nick Johnson <nick=
40ethereum.org@dmarc.ietf.org> wrote:

>  On Sat, Jun 15, 2019 at 2:21 AM Stephane Bortzmeyer <bortzmeyer@nic.fr>
> wrote:
>
>> On Fri, Jun 14, 2019 at 02:38:11PM +1200,
>>  Nick Johnson <nick=40ethereum.org@dmarc.ietf.org> wrote
>>  a message of 173 lines which said:
>>
>> > Indeed - it's my understanding that ICANN forbids publishing anything to
>> > the root zone other than necessary records such as SOA, NS and DNSKEY.
>>
>> You mean the TLD zone?
>
>
> Sorry, yes I did.
>
>
The set of allowed RRTYPEs in a gTLD zone can (and does) change, given a
reasonable justification, and enough interest and pressure from the
registries.  For example, the last revision of the Registry Services
contract that ICANN put out[0] added a record for zone versioning
independent of the SOA record.

You can get a new RRTYPE reserved for your purposes quite easily[1].  With
that, you could run a trial with some early-adopting ccTLDs (not
constrained by ICANN's Registry Services contract) to demonstrate the
utility of your scheme.  If it's attractive enough to warrant the internal
process and development costs to deploy, and the ICANN lobbying efforts,
then the gTLD operators could have it added to the contract.

Whatever your deployment method, you will need to demonstrate some benefit
to the registries if you want them to adopt your scheme.  Making changes to
their process isn't cheap, and there is no such thing as a one-off cost;
everything added to their operation needs to be maintained and monitored,
which incurs an ongoing cost.

[0]: Exhibit A, §1.1 <
https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.pdf
>
[1]: <https://tools.ietf.org/html/rfc6895#section-3.1.1>