1. Introduction
Today, nearly all DNS queries [RFC1034] [RFC1035] are sent unencrypted, which makes them vulnerable to eavesdropping by an attacker that has access to the network channel, reducing the privacy of the querier. Recent news reports have elevated these concerns, and recent IETF work has specified privacy considerations for DNS [RFC7626].
Prior work has addressed some aspects of DNS security, but until recently, there has been little work on privacy between a DNS client and server. DNS Security Extensions (DNSSEC) [RFC4033] provide response integrity by defining mechanisms to cryptographically sign zones, allowing end users (or their first-hop resolver) to verify replies are correct. By intention, DNSSEC does not protect request and response privacy. Traditionally, either privacy was not considered a requirement for DNS traffic or it was assumed that network traffic was sufficiently private; however, these perceptions are evolving due to recent events [RFC7258].
Other work that has offered the potential to encrypt between DNS clients and servers includes DNSCurve [DNSCurve], DNSCrypt [DNSCRYPT-WEBSITE], Confidential DNS [CONFIDENTIAL-DNS], and IPSECA [IPSECA]. In addition to the present specification, the DPRIVE Working Group has also adopted a proposal for DNS over Datagram Transport Layer Security (DTLS) [DNSoD].
This document describes using DNS over TLS on a well-known port and also offers advice on performance considerations to minimize overheads from using TCP and TLS with DNS.
Initiation of DNS over TLS is very straightforward. By establishing a connection over a well-known port, clients and servers expect and agree to negotiate a TLS session to secure the channel. Deployment will be gradual. Not all servers will support DNS over TLS and the well-known port might be blocked by some firewalls. Clients will be expected to keep track of servers that support TLS and those that don't. Clients and servers will adhere to the TLS implementation recommendations and security considerations of [BCP195].
The protocol described here works for queries and responses between stub clients and recursive servers. It might work equally between recursive clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter.
This document describes two profiles in Section 4 that provide different levels of assurance of privacy: an opportunistic privacy profile and an out-of-band key-pinned privacy profile. It is expected that a future document based on [TLS-DTLS-PROFILES] will further describe additional privacy profiles for DNS over both TLS and DTLS.
An earlier draft version of this document described a technique for upgrading a DNS-over-TCP connection to a DNS-over-TLS session with, essentially, "STARTTLS for DNS". To simplify the protocol, this document now only uses a well-known port to specify TLS use, omitting the upgrade approach. The upgrade approach no longer appears in this document, which now focuses exclusively on the use of a well-known port for DNS over TLS.