[Doh] representation of DNS transport in use?

[Erik Kline <[e-mail]>]

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