IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Tue, 23 March 2021 14:57 UTC

Return-Path: <paul@nohats.ca>
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 172863A11EB for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 07:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=nohats.ca
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 iR9b_ZzrT2TA for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 07:56:55 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3783A11D7 for <dns-privacy@ietf.org>; Tue, 23 Mar 2021 07:56:51 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4F4ZFr3vz8zFG6 for <dns-privacy@ietf.org>; Tue, 23 Mar 2021 15:56:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1616511408; bh=cKzosp/xJU7i7WNJBPRR2wV4nuY/36kMA5GgsJcRwxY=; h=Date:From:To:Subject:In-Reply-To:References; b=CbdVXG0VIUGIhF2K+Se1WdvXYE1tG1ijyIrCFsb5wkSyS5avFLeJRJZBAkiU7cO1H CiMRmywBPCt8VvQj4wGuLhByffbOW1DcAqYrD68dcrTe1G8+vK1RZUYHXLTLIxnNnE 5o0vwYCKJiwO6pLam6aGTlEraDhpqAxaGwFdhLGY=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 61kweBXntxOw for <dns-privacy@ietf.org>; Tue, 23 Mar 2021 15:56:47 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dns-privacy@ietf.org>; Tue, 23 Mar 2021 15:56:47 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1A0C66029A53; Tue, 23 Mar 2021 10:56:46 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 18C5266B7E for <dns-privacy@ietf.org>; Tue, 23 Mar 2021 10:56:46 -0400 (EDT)
Date: Tue, 23 Mar 2021 10:56:46 -0400
From: Paul Wouters <paul@nohats.ca>
To: dns-privacy@ietf.org
In-Reply-To: <5861CBBC-4C76-4455-90FF-B127171CF054@rfc1035.com>
Message-ID: <1bed6998-49fe-3620-e3a2-b51942c795cc@nohats.ca>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/-3zAfFBxREmZgN_JGzgBN2I6UKY>
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:57:04 -0000

On Tue, 23 Mar 2021, Jim Reid wrote:

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

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.

There is less need of this in the root, provided the resolver uses
query minimalization.

This is based on my assumption that SVCB records will never be served
by the parent of the domain it is for (something not everyone in the WG
seems to have accepted as operational reality).

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

Paul

v2.23.0 | Report a Bug | By Email