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

Jim Reid <jim@rfc1035.com> Tue, 23 March 2021 16:22 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 974573A083E for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 09:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 w96jToT1Jmbl for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 09:22:43 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1A43A03F6 for <dns-privacy@ietf.org>; Tue, 23 Mar 2021 09:22:34 -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 69EE82421544; Tue, 23 Mar 2021 16:22:32 +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: <1bed6998-49fe-3620-e3a2-b51942c795cc@nohats.ca>
Date: Tue, 23 Mar 2021 16:22:31 +0000
Cc: dns-privacy@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C09A688F-A8BD-4AD0-B02A-7A476D26AFE8@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> <1bed6998-49fe-3620-e3a2-b51942c795cc@nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/XoTN3L-McdlTKgyCXCP7k3ICd4Q>
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 16:22:53 -0000


> On 23 Mar 2021, at 14:56, Paul Wouters <paul@nohats.ca> wrote:
> 
> The point of putting them into a TLD would be to be able to build up a
> secure private connection to the TLD nameserver, before issuing a target
> domain query within the TLD.

These things can be done without needing SVCB records. Though they do make that a little less clunky than trying DoT or DoH to some name in the NS RRset and hoping for the best.

> Your "remarkably bad idea" needs more qualifications that can be
> discussed on technical and societal merit.

Most of the busy TLDs use a mix of DNS providers and so there may not be a uniform provision of DoH and DoT service across all of the TLD’s authoritative servers. [Would busy TLD servers ever do DoT or DoH anyway?] Which I suppose could be argued the other way: for instance don’t send DoT traffic to provider A for $tld because they don’t do DoT.

Using SCVB records to say “send all DoH (say) traffic to $provider” is a vector for all sorts of nasties: DoS, privacy, competition, consolidation/centralisation, robustness, etc. These are things TLDs should try to avoid IMO.

It doesn’t seem right to allow a TLD operator to tell someone what DoH server(s) to use/not use to resolve $tld's names. Would SVCB records let the edge device or end user make informed choices about the privacy (or whatever) policies for those DoH servers? It’s one thing to do that for whatever.com*. IMO it’s something very different for .com as a whole. [*Other TLDs are available.]