IETF Logo Mail Archive

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

Bill Woodcock <woody@pch.net> Tue, 23 March 2021 14:55 UTC

Return-Path: <woody@pch.net>
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 223563A10FE for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 07:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 Hhep8pTaRQxR for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 07:55:05 -0700 (PDT)
Received: from mail.pch.net (keriomail.pch.net [206.220.231.84]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF56B3A1103 for <dns-privacy@ietf.org>; Tue, 23 Mar 2021 07:55:05 -0700 (PDT)
X-Footer: cGNoLm5ldA==
Received: from [10.19.48.7] ([69.166.14.2]) by mail.pch.net (Kerio Connect 9.2.7 patch 3) with ESMTPS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 23 Mar 2021 07:55:00 -0700
From: Bill Woodcock <woody@pch.net>
Message-Id: <A340AA39-B80E-47DB-87C1-01D13675550A@pch.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_F667FC1D-EC92-4689-9657-CA44C62E9803"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Tue, 23 Mar 2021 15:54:55 +0100
In-Reply-To: <5861CBBC-4C76-4455-90FF-B127171CF054@rfc1035.com>
Cc: Brian Haberman <brian@innovationslab.net>, dns-privacy@ietf.org
To: Jim Reid <jim@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> <5861CBBC-4C76-4455-90FF-B127171CF054@rfc1035.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/-3cNoSHg10az-7Hd_9ei17CPWHo>
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:55:10 -0000


> On Mar 23, 2021, at 3:50 PM, Jim Reid <jim@rfc1035.com> wrote:
>> Is there an issue with putting SVCB info in the TLD 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...

Yes, I completely agree that the bureaucratic challenge in fixing that idiocy is very, very high.

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

Why?

There are a million clever and useful things that you could do, if it were possible.  Which are particularly valuable for brand TLDs, for instance.

What arguments exist against it?  Was there some justification, back when that language was put in?  I’ve always assumed it was just existing registries trying to gratuitously jerk new ones around.

                                -Bill

v2.23.0 | Report a Bug | By Email