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
Description: S/MIME Cryptographic Signature
_______________________________________________ dns-privacy mailing list email@example.com https://www.ietf.org/mailman/listinfo/dns-privacy