DNS-over-HTTPS (DoH for short) is a standard developed by the IETF (under the RFC 8484 designation) to solve privacy concerns in DNS communication.
DNS Privacy: a primer
As we’ve talked about before, using DNS has been done in cleartext: the queries and responses between both the end user (applications, or stub resolvers, such as a browser) and the (first-hop) DNS resolver and the resolver and the DNS nameserver(s) are unencrypted by default.
While DNSSEC extensions were developed early on, they only added response integrity and not privacy. As IETF states, “either privacy was not considered a requirement for DNS traffic or it was assumed that network traffic was sufficiently private.”
In recent years, however, that changed. Privacy has become a central concern and addressing it has spawned numerous solutions, such as DNS-over-HTTPS (DoH).
DoH conducts DNS operations using secure http urls and mapping DNS queries and responses into http exchanges, using default media formatting types.
While DoH uses existing protocols for communication, the IETF emphasizes that “[The] described approach is more than a tunnel over HTTP.” Aligned with existing http features, DNS servers and clients supporting DoH are called ‘DoH server’ and ‘DoH client’ respectively, as they can be used for more than only DNS.
While DNS-over-HTTPS and DNS-over-TLS are colloquially used as different protocols, because DoH uses https it also includes TLS security. The key difference between DoH and DoT is the manner in which DNS operations are conducted.
DoH in action
DoH clients are configured with a URI template containing the url structure for DNS resolution. The client then uses a GET or POST method to send an encoded DNS query.
DNS-over-HTTPS uses standard https traffic (via port 443) to communicate. Because DNS communication is done through standard https methods and resides within https traffic, overhead for DoH is low.
DNS-over-HTTPS is a newer protocol than DNS-over-TLS. DoH has had less testing and research than DoT, but because it aligns with https as an underlying transport protocol, it is less susceptible to issues other than those associated with https itself.
DoH, though still young, has successfully leveraged the existing ecosystem of native web applications and APIs. It can create more efficient (and private!) communications with DNS.
Arguments against DNS-over-HTTPS (in its current form) stem more from operational considerations. Whereas DoT can be controlled because of its use of a single and unique port, DoH is almost impossible to control or filter.
DNS privacy (DoH, as well as DoT and other solutions) is a good representation of the operational shifts network managers and architects face. DNS-over-HTTPS in particular is a solution born from a public networking mindset. Traditional corporate network operations that are increasingly dependent on cloud services and experience an influx of connected devices through IoT and BYOD, have to re-adjust.
But DNS privacy also means that the opportunity for corporate network managers and architects is more pertinent than ever before. DoH, DoT, and other solutions are young and still forming. Whereas the question before centered around ‘adoption’ of protocols, these new technologies offer a chance to ‘influence’. Ongoing participation in the conversation and debate over the merits and shortcomings of each is necessary.
Additionally, pilot programs, particularly those run in regulated, corporate environments, are invaluable to both the developers of DNS privacy solutions as well as the network managers and architects who will be charged with implementing it.