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>
- [DNSOP] Verifying TLD operator authorisation Nick Johnson
- Re: [DNSOP] Verifying TLD operator authorisation Joe Abley
- Re: [DNSOP] Verifying TLD operator authorisation Nick Johnson
- Re: [DNSOP] Verifying TLD operator authorisation Rubens Kuhl
- Re: [DNSOP] Verifying TLD operator authorisation Nick Johnson
- Re: [DNSOP] Verifying TLD operator authorisation Rubens Kuhl
- Re: [DNSOP] Verifying TLD operator authorisation Nick Johnson
- Re: [DNSOP] Verifying TLD operator authorisation Shane Kerr
- Re: [DNSOP] Verifying TLD operator authorisation Jim Reid
- Re: [DNSOP] Verifying TLD operator authorisation Dr Eberhard W Lisse
- Re: [DNSOP] Verifying TLD operator authorisation Jim Reid
- Re: [DNSOP] Verifying TLD operator authorisation Vladimír Čunát
- Re: [DNSOP] Verifying TLD operator authorisation Nick Johnson
- Re: [DNSOP] Verifying TLD operator authorisation Bjarni Rúnar Einarsson
- Re: [DNSOP] Verifying TLD operator authorisation Jim Reid
- Re: [DNSOP] Verifying TLD operator authorisation Jim Reid
- Re: [DNSOP] Verifying TLD operator authorisation Shane Kerr
- Re: [DNSOP] Verifying TLD operator authorisation Nick Johnson
- Re: [DNSOP] Verifying TLD operator authorisation Joe Abley
- Re: [DNSOP] Verifying TLD operator authorisation Mark Andrews
- Re: [DNSOP] Verifying TLD operator authorisation Tim Wicinski
- Re: [DNSOP] Verifying TLD operator authorisation Matthew Pounsett
- Re: [DNSOP] PSD records, was Verifying TLD operat… John Levine
- Re: [DNSOP] PSD records, was Verifying TLD operat… Tim Wicinski
- Re: [DNSOP] PSD records, was Verifying TLD operat… John R Levine
- Re: [DNSOP] Verifying TLD operator authorisation Vittorio Bertola