Re: [Doh] Proposal: DNS configuration string

Mark Nottingham <mnot@mnot.net> Mon, 03 June 2019 22:17 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 EFD7E120120 for <doh@ietfa.amsl.com>; Mon, 3 Jun 2019 15:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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=KSwTOyhU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=t4ykPiEd
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 WAniqJ2r_KoW for <doh@ietfa.amsl.com>; Mon, 3 Jun 2019 15:17:50 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B50120862 for <doh@ietf.org>; Mon, 3 Jun 2019 15:17:50 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 0D24222289; Mon, 3 Jun 2019 18:17:50 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 03 Jun 2019 18:17:50 -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=v ckVMd2oo22ScvLx49ZyAvQ129G38YLl9BzOU2d10Fo=; b=KSwTOyhUdGcZpAacs 4efyD/pLVl21hsECyZ6C0ZPJyL01EJ1GL95eHiA0Z2BhNvcLm0ekq+PWYEnwCCOs W9Ihv148HkMF2hjWJFfxDvO5GIrG2ZdbvuSqVNOOTGuCOELCH0bnsyjP9sONag12 MXcHjBzgUR9wCp8sdVrgBHvl0JikLtl1E5LogA3UbR0FyQNNf006G/p/FChj5t/U xYccgYx6aokeEJcm5DSW7eDeEyJxabuqk+LYSJq2wXYvqErEWZmYi23I3mtvxAbb XZPUaVG8rvs+0CBGHc3pZWnMKa+gKVsojNcfMDf0AeDfekl1hFL6sTE7/nGvII6H jAKgw==
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=vckVMd2oo22ScvLx49ZyAvQ129G38YLl9BzOU2d10 Fo=; b=t4ykPiEdXb9uK7eUjst5nZ+9KhKXd0p+9sgfjJj+fToxXAsgd/AqRdC+w iIPo827lvzKdsyex+PSdBLYvNM5z8Nw8djb3KEE64+ilbiYKxjXQTrCylgQjRELe YsVF7D17RiV8sCF+zzJ5yL1z2l5NB3C4IUqxefcVRel/RT/CrCXlExvrC1ylmyDy yj7Y7gAPQlyeFxarBlKJQez0DTJUe9whAXb1YNLtZJAk6CuDeUKSIhL7djOK+71c S2FOJTpzuLhX1K+TU8DKCpo+6rPXKYG7mMI7HYLHfFs/Jv9zoSvt53OUxGZrSOnZ LklQidHlfi5uop2GVYl8KWjhm5IpA==
X-ME-Sender: <xms:jZz1XLeI9GET9-MEtdowFSBA5YCbEihCuyHwhgYek5KpefbEg-2wtg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefkedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhihshhithgvrdgtohhmpdgvgigrmhhplhgvrdhnvghtpdhivghtfhdrohhrghdpmhhn ohhtrdhnvghtpdgvgigrmhhplhgvrdgtohhmpdguohhrihgrnhhtrgihlhhorhdrtghomh enucfkphepudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhm pehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:jZz1XEeYCPB9_-ktduLOy291CM7NMShJHfaZXAr-TRs9as4vVSP2Hg> <xmx:jZz1XMB8D2RpgcLf_vw7H_dqE__j0WemHAN5XzQyBvA7ezeUkganbw> <xmx:jZz1XKmwwQdmwaQ0LSMRVREEYAzMMmbjLXlb3jIblj5LvH_oLfKtrw> <xmx:jpz1XLGAFIZN1R5kDZLGNlwTEwlvO-oK3FdMplLtLvKTTmWO4TnaKQ>
Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id A81E580059; Mon, 3 Jun 2019 18:17:47 -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: <9b0b1ad8-2be3-5b47-5e2b-b1de1052d1b9@o2.pl>
Date: Tue, 4 Jun 2019 08:17:43 +1000
Cc: DoH WG <doh@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC67A283-1796-400E-B42A-9A1E45FDC2E9@mnot.net>
References: <b38f0ad7-ede0-4eaa-07e8-76dbb8668bd3@o2.pl> <41206ECE-4CD8-41A5-AE4B-2EFE0EC00A6A@mnot.net> <9b0b1ad8-2be3-5b47-5e2b-b1de1052d1b9@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/TBqlUzaZXTebzqyNv96Ar3nDt7Y>
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: Mon, 03 Jun 2019 22:17:54 -0000

On 4 Jun 2019, at 1:47 am, Mateusz Jończyk <mat.jonczyk@o2.pl>; wrote:
> 
> There are many configuration parameters involved in DoH. 
> After encapsulating them in a single string, it is easier for the user 
> to set a custom DoH resolver, among other benefits (which I 
> elaborated on in the original e-mail).

I understand that -- my question was why that configuration needs to be conveyed as part of the URL template's syntax, rather than in a structure (perhaps a string) that contains the URL template. Structuring a URL like that violates BCP190.

For example, instead of:

 dns://1.2.3.4;valid-for=_nodot,.some-company

You could use:

 dns://1.2.3.4 valid-for=_nodot,.some-company

Because a space isn't valid in a URL (or template), it's not making the assumption that the structure you're usurping is "very rare" -- such assumptions don't hold at Internet scale.

(If you don't like space, there are a lot of other characters that are invalid in URLs that could be used as a delimiter, or you could embed the URL template in another structured format, e.g., JSON or XML).

Cheers,

> 
> W dniu 03.06.2019 o 00:53, Mark Nottingham pisze:
> 
>> 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/
>> 
>> 
>> 
>> 
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh

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