IETF Logo Mail Archive

Re: [dns-privacy] [Ext] next steps for draft-opportunistic-adotq

Jim Reid <jim@rfc1035.com> Tue, 23 March 2021 14:50 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360723A10B5 for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 07:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 w6VSyv3oo4yc for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 07:50:09 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E6C3A10E4 for <dns-privacy@ietf.org>; Tue, 23 Mar 2021 07:50:03 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id C08BF2420C28; Tue, 23 Mar 2021 14:50:00 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <8363070a-8fc5-2d20-a9aa-45673d1515ac@innovationslab.net>
Date: Tue, 23 Mar 2021 14:50:00 +0000
Cc: dns-privacy@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5861CBBC-4C76-4455-90FF-B127171CF054@rfc1035.com>
References: <2ba5ac12c24eaee4c51de2cd2c1693e9bd1fd8b2.camel@powerdns.com> <4bc96140-454e-0746-83b3-bb1331cf7cce@cs.tcd.ie> <ADB00FD5-A6EA-4D05-84E8-A44A2E40BE7C@icann.org> <8363070a-8fc5-2d20-a9aa-45673d1515ac@innovationslab.net>
To: Brian Haberman <brian@innovationslab.net>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/SvaXAf0MliN7Caz_j8Cm_tPn07w>
Subject: Re: [dns-privacy] [Ext] next steps for draft-opportunistic-adotq
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 14:50:14 -0000


> On 23 Mar 2021, at 14:16, Brian Haberman <brian@innovationslab.net> wrote:
> 
> Is there an issue with putting SVCB info in the TLD zones?

Yes - for gTLDs. Almost all of them have contracts with ICANN. Adding SVCB records to ccTLDs is easier (in principle) since few (any?) of them have contracts with ICANN. Since those gTLD contracts say “no SVCB records”, registries can’t/shouldn’t add them to their zones.

> If I interpret this ICANN document correctly
> (https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#exhibitA.1),
> there are strict limitations on the info that can be put in the TLD zones.

Indeed. It is possible to get these contracts to be amended. But it will take endless rounds of meetings, task forces and consultations before an appropriate board resolution could be passed and implemented. Good luck with that...

What would be the point of putting SVCB records in a TLD (or the root)? It seems like a remarkably bad idea to me.

v2.23.0 | Report a Bug | By Email