Re: [Doh] Proposal: DNS configuration string

Mark Nottingham <mnot@mnot.net> Sun, 02 June 2019 22:53 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598B9120127 for <doh@ietfa.amsl.com>; Sun, 2 Jun 2019 15:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZiU9b3+f; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ECnvRSV3
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 o427j7IOd6Mo for <doh@ietfa.amsl.com>; Sun, 2 Jun 2019 15:53:09 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4703D1200F1 for <doh@ietf.org>; Sun, 2 Jun 2019 15:53:09 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7D71321540; Sun, 2 Jun 2019 18:53:08 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 02 Jun 2019 18:53:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=/ JnQJ19Qd96dTvRqYB6Lys/w4/QdSYChraAbs74dY5Y=; b=ZiU9b3+f16qOmUBUL 7jmtEWm4JyUpGKS8ZZfCXfg4Wheqhbi5+uDPy4yL27ILCuJ/onJ9hoXNrqvqUUiX UijLqJodl0eEDeCBTjIU6kShCL6IQSGsAPh6bkrXzSxmWi+mqKNdeHUd8sVs39dB zWKPJE+fSDbQod+2/H2hoU9gbfIPtVSRMBNptZ86X5LrX15t0jJImU+hyD0Ji/GI XpYQFaRJyBoA8Y6wXH7qp5Cpx14cF5Dr2zDYGvi9hwfFqae6x/edc81OD8p57yC+ zehQgFlgGoE4ui0cb23UWG7x5EPmcsZb7Hdc3XqOXg3Nw9fCxJ6lUfsUY6SPrlyK s1bMg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=/JnQJ19Qd96dTvRqYB6Lys/w4/QdSYChraAbs74dY 5Y=; b=ECnvRSV3YejrNlbx2l2ilKUOMOWzzNkL9CueEs9+Y/A6n3xEM6ns39rx1 MHPD+d5r0ChHAx7RVHMbQQN4q3Z2dgs0isWCN5JCrd2i8PU55sM6rqADHpH/ZDjX Ixv9hG741BmRsCnvZDcxcohdc4emhuqxVrhUEBqc63X7Q8qg4CMnchjEDOHjyhhN 1jHZBf8BAg9xzVCG7gVNgHOZxXfPIRwELQx03n5TEMJpdZ3C0HImG04dFpv1ZUyS GUU1VZNcrg3U4iXYWy41KPCmZg702TpdgFXLLPtY8ChnzZV50+/FSmHztKzcdEoT ZgymfH1EXbeD92url6UfLdyoSNDtQ==
X-ME-Sender: <xms:U1P0XMryz-RJz-2qogyzA59AiPBAQKTZ0m8_-eRDtCWn_uuMJzf6bw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefiedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhihshhithgvrdgtohhmpdgvgigrmhhplhgvrdhnvghtpdhmnhhothdrnhgvthdpvgig rghmphhlvgdrtghomhdpughorhhirghnthgrhihlohhrrdgtohhmnecukfhppedurddufe eirdduieejrdduuddunecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohht rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:U1P0XCwrBqJNSgkroxXoGxln1UTBWUhvJ1Ui7zEH1Dq28U6q3hv7KA> <xmx:U1P0XFW2i_08QIEe_jDRWFrLdNMDKxiOfAFy1KCioeVOr519LtnfjQ> <xmx:U1P0XMVI3pXeuR4w3f2Qp1TCKgmLzE1PrZA5T9O1QMTw4tyRHtSl6Q> <xmx:VFP0XDMiMAjSPBj7z3vzpM01dXJ6WOGNBujEFDpPvid-FuCHcTPHgw>
Received: from [172.20.10.3] (unknown [1.136.167.111]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C0EE38008E; Sun, 2 Jun 2019 18:53:05 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <b38f0ad7-ede0-4eaa-07e8-76dbb8668bd3@o2.pl>
Date: Mon, 3 Jun 2019 08:53:00 +1000
Cc: DoH WG <doh@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <41206ECE-4CD8-41A5-AE4B-2EFE0EC00A6A@mnot.net>
References: <b38f0ad7-ede0-4eaa-07e8-76dbb8668bd3@o2.pl>
To: =?utf-8?Q?Mateusz_Jo=C5=84czyk?= <mat.jonczyk@o2.pl>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/VlfIZzRgYrmyYj9UjSwpl_ga-7c>
Subject: Re: [Doh] Proposal: DNS configuration string
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Jun 2019 22:53:13 -0000

Why not just convey this separately -- why does it have to be in the URL?

> On 2 Jun 2019, at 7:44 pm, Mateusz Jończyk <mat.jonczyk@o2.pl>; wrote:
> 
> Signed PGP part
> Hello,
> 
> Currently, there are multiple ways of resolving DNS queries:
> 
> 	• old port-53 DNS,
> 	• DNS over TLS,/
> 	• DNS over HTTPS.
> Some of these accept additional parameters, such as server certificate information (which may be necessary when using local DoH / DoT servers). These parameters are server-specific --- when configuring multiple servers, each of them may need different certificate information.
> 
> I would argue that it would be beneficial to embed all such parameters into a single server specification string. The user would be able to copy-paste them, for example from the website of their chosen DNS resolver, a file provided by their sysadmin or from their router configuration GUI. A DHCP server could advertise the string in a single field. Additionally, an application could pass the whole string to a DNS-handling library. That way the application would not have to implement support for all DNS configuration parameters on its own (with complex GUIs) and new parameters (or even new DNS resolver types) could be supported by the program after a library upgrade. This would also simplify configuration file structure (allowing for a single server per line).
> 
> Some examples [3]:
> 
> 	• doh://dnsserver.example.net/dns-query{?dns};ip=1.2.3.4;root-cert=zdYsea0CQufOmBpLdLfu/q3tOOdxbBCuZNhAa+YuQWo
> 	• dns://1.2.3.4;valid-for=_nodot,.some-company
> I would like to propose to use a semicolon ';' as the separator between a resolver address (or an URI template) and resolver parameters. Theoretically, a DoH URI Template could contain a semicolon, but that should be very rare [1]. In such cases, the semicolon would be percent-encoded as "%3B".
> 
> Parameter explanation:
> 
> 	• ip - IP of the DoH resolver, used for bootstrapping,
> 	• root-cert - fingerprint of the root certificate of the DoH server (specified in a similar way as in HTTP certificate pinning),
> 	• valid-for - which domain names should be resolved by this server: in this example all names that do not contain a dot ("_nodot") [4] as well as all domains that end with ".some-company".
> What do You think?
> Greetings,
> 
> Mateusz
> 
> 
> 
> 
> 
> [1] A URI segment that begins with a semicolon is called a path parameter. An example (taken from [2]) would be:
> 
>         http://www.mysite.com/admin/UpdateUserServlet;jsessionid=OI24B9ASD7BSSD
> 
> The URI template specification (RFC6570) supports expansion of path parameters with a syntax like:
> 
>         http://example.com/{;who}
> 
> [2] https://doriantaylor.com/policy/http-url-path-parameter-syntax
> 
> [3] The DoH specification requires that:
> 
>     "This protocol MUST be used with the https scheme URI [RFC7230]."
> 
> but I assume that using "doh://" does not break this as the statement is really concerned with using encryption and not the "https://" string. 
> 
> [4] The first character is intentionally "_" because it cannot exist in valid domain names.
> 
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/