[Doh] representation of DNS transport in use?

Erik Kline <ek@google.com> Sat, 10 March 2018 11:20 UTC

Return-Path: <ek@google.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B7F49124217 for <doh@ietfa.amsl.com>; Sat, 10 Mar 2018 03:20:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JG8kq9wzd0rK for <doh@ietfa.amsl.com>; Sat, 10 Mar 2018 03:20:49 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770511271FD for <doh@ietf.org>; Sat, 10 Mar 2018 03:20:49 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id e2so578972ywh.9 for <doh@ietf.org>; Sat, 10 Mar 2018 03:20:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Z7fIcoaKW3uV6jaMwcKOD9Ei8e+uyTHrA3J3cDXZTSA=; b=IxCOA4W+qbMa17GSfWrb4N3Xxo8DzcmYppl8NwNuKUO5wQyHo794lhZ8yUdkbUUe66 bGgs+/tcHqasVRSyMeYrthCZ+JMfkQc0WzE/4BsembkJyH6LYwaZsaJUCdOAKk5UlXtm QzDIdF1CgcT7u84VM9eVqucKajwYtM+cyzsjBNazXcw6tqTd04cANB5r1RIspk8iMLQf q1ofXImgj3mYHAnl4U57/J8tU8hZNuYCva8tBvV749nDYLsdjARFHXObITu0RPyzVeEh fULlwWubaTZl3KcIKfpLrnnI7ZjpcE/MQaLdFkaUHVrlK3Rs2pbunn/dughjp+h0vmgZ 2WkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Z7fIcoaKW3uV6jaMwcKOD9Ei8e+uyTHrA3J3cDXZTSA=; b=WAylbTfuvAxEB3OiXPqjuSrT95gjf5/6RtCA744OBscn+mmduSB3X8qyf5+dI/4H7F REi+iIHkkVxPX9ER5hMVrlBk9DFBFSjPkgYkbp/DuBB6pRP0D+4pq6D77vKKHN/9PQgo vDvDDWMsRpCGW7Y+Xdv+A+rvquVqg19mMY0EckyDAKPXfxsznUN8t2bhoc/eYSyYobUZ vYCoEctgOeXyiy3tpooyvtJ/u//IW2iopfgf2MMjVcbHQK/jknqcYcVGJFdVC32HxHp8 VDt91sF4rh2hlrpHmGnPkNa3GUTGt81sYwlYoIBOP1TRD0afHMwkaBpMsz+vasLaZIix yw1Q==
X-Gm-Message-State: AElRT7H4GHqWm/L7+PmL1XVeFUTEKXDikw0/gZUNHylSFhy4sbg74aoe 3w6Pj3FkOEkaTmEdKOqS8cdd3yg1G+npg0sx9myJeezZ//c=
X-Google-Smtp-Source: AG47ELs/H7FUfhCmZezwcqp+lY6CqsHfuKJdfRTmQha8duVadw/Cyvy/YT6l4BuhYWybxp/MOHL3TBAV//osglIwm6g=
X-Received: by with SMTP id q184mr829400ywq.266.1520680848180; Sat, 10 Mar 2018 03:20:48 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a25:ab51:0:0:0:0:0 with HTTP; Sat, 10 Mar 2018 03:20:27 -0800 (PST)
From: Erik Kline <ek@google.com>
Date: Sat, 10 Mar 2018 20:20:27 +0900
Message-ID: <CAAedzxq7QGB4YduDd-Kkjfyf1okR8f=EjBw7VOPBszwj2YRkgQ@mail.gmail.com>
To: doh@ietf.org, dns-privacy@ietf.org
Cc: Lorenzo Colitti <lorenzo@google.com>, Warren Kumari <wkumari@google.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11429238cede5205670d190f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/vNNmJVBjTZKzz4y0RPo7uSQydWk>
Subject: [Doh] representation of DNS transport in use?
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 10 Mar 2018 11:20:52 -0000

I'm expecting to die a thousand deaths for this question, but...

TL;DR: Should we have some kind of URI schemes for encrypted DNS
protocols (i.e. identifying the transport)?


The motivation for this comes from working on adding DNS-over-TLS
support into Android.

Background: an app can always do its own DNS resolution regardless of
what the system would do on its behalf were it asked.  An app can send
to some random server at port 53 without going through the system
resolver, or it can wrap DNS queries in a Carrier Pigeon VPN.

We have an API to communicate to apps whenever an encrypted DNS
protocol is in use by the system: in order to express the intent of
the user and indicate when at least one nameserver was successfully
found in opportunistic mode (the system is consequently sending all
queries to that/those server(s) inside TLS, and apps should therefore
do likewise).

When thinking about what information might be expressed by this API,
rather than defining something bespoke I figured I'd ask about whether
a standard identification scheme for transports is worth having.
Currently we only support DNS-over-TLS.  If we someday gained
dns-over-https capability we might try to auto-detect the servers'
capabilities and could conceivably convey that status to apps.

RFC 4501 is obviously a thing, but seems to me to be more aimed at
identifying resource records than server access methodology.  To wit,
from section 3:

   Intended usage: Whenever it is useful for DNS resources to be
   referenced by *protocol-independent* identifiers.  Often, this occurs
   when the data is more important than the *access method*.  Since
   software in general has coped without this so far, ...

(emphasis mine)

Add to this discussion the observation that some DNS-over-TLS servers
are also reachable on 443, I think just representing the protocol in
use might not be sufficient.

RFC 7858 didn't seem to request any URI registration. For a server
reachable via dns-over-https, the -03 doc would seem indicate we could
just use https://thing:port.  So maybe this is a matter only for
DNS-over-TLS (dns-tls://thing:port?).

End of rambling.