Subject: [dns-privacy] representation of DNS transport in use?

From: Erik Kline <[email-masked]>
Date: Sat, 10 Mar 2018 20:20:27 +0900

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.
-ek

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Mar 2018 11:40:33 +0100

On Sat, Mar 10, 2018 at 08:20:27PM +0900,
 Erik Kline <[email-masked]> wrote 

> protocols (i.e. identifying the transport)?

dns+tls: ? (To follow the COAP example of RFC 8323, section 8.)

May be this is a question for [email-masked]?

---

From: Brian Haberman <[email-masked]>
Date: Tue, 20 Mar 2018 05:39:14 -0400

Hi Erik,

> protocols (i.e. identifying the transport)?

I had a chat with a couple of URI experts about this. Their question is
whether you actually want to expose the security mechanism to the
application. Their view was that there *may* be a benefit to having a
dnss: URI, to go along with the dns: URI, but not one that indicates the
actual mechanism (e.g., dns-tls:).

I will try and get more details from them as the week goes along.

Regards,
Brian

---

From: Erik Kline <[email-masked]>
Date: Tue, 20 Mar 2018 13:03:40 -0700

> I will try and get more details from them as the week goes along.

Brian,

Thanks for looking into this.

I think dnss: might be useful.  The security mechanism negotiated by
the resolver layer may not be the only (nor even the best) one, but it
can serve as a suitable hint.

I think something like dnss://dns.quad9.net:853 is sufficiently
descriptive for an app to try DNS-over-TLS first with a reasonable
expectation that it should work.

I think dnss://example.com:443 is still helpful, but less so.  An app
will have to chose from the protocols it supports and figure out how
to try/negotiate DNS-over-TLS, DNS-over-HTTPS, or even JSON DNS over
HTTPS.

Of course, one of the problems here is that I'm reusing the familiar
https: style authority syntax.  The dnss: URI space need not follow
that convention.  Basically, I need to take rfc3986#section-1.2.2 to
heart.  =)