The Men & Mice Blog

DNS Privacy: DNS-over-HTTPS

Posted by Men & Mice on 4/16/19 5:24 AM

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

DNS-over-HTTPS

DoH conducts DNS operations using secure http urls and mapping DNS queries and responses into http exchanges, using default media formatting types.doh

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.

DoH challenges

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.

Topics: DNS privacy, DNS-over-HTTPS

DNS privacy: DNS-over-TLS

Posted by Men & Mice on 4/10/19 11:05 AM

DNS-over-TLS (DoT for short) is a standard developed by the IETF (under the RFC 7858 designation) to solve privacy concerns in DNS communication.

DNS Privacy: a primer

As we’ve talked about before, until recently,  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 the 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-TLS.dot

DNS-over-TLS

DoT approaches privacy by encrypting DNS queries and responses between entities (predominantly between the stub resolver and the first hop resolver) using TLS (Transport Layer Security).

DoT uses a standard port (853) to initiate and accept DNS queries. It is possible to use a mutually agreed different port, but it is not the default. Once the connection is made, a TLS handshake is attempted, and after authentication the encrypted DNS communication can commence.

DNS servers supporting DoT are not accepting unencrypted data on the designated port, neither during session initiation, nor after a failed TLS authentication.

DoT overhead

Computers are powerful and efficient, but not without limits. DNS-over-TLS adds latency to DNS operations that needs to be accounted for and minimized.

DNS clients are required to adhere to a certain field length (two octets) and it is recommended to keep established, but idle, connections alive to the server. Another way to minimize latency is to pipeline multiple queries over the same TLS session. In this case, it’s the DNS client’s responsibility to match responses to queries, as they may arrive and be answered out of order.

Keeping established connections alive helps distribute the connection setup costs. Misconfigured handling of idle connections can lead to denial of service issues.

Flavors of DoT

DNS-over-TLS can be used in various ways. The IETF standard identifies opportunistic and Out-of-Band Key-Pinned privacy profiles.

Opportunistic privacy profile means the client recognizes a TLS-enabled DNS resolver and attempts to use it. If it successfully validates it, DNS-over-TLS may be used, but isn’t mandatory and the client can fall back to non-encrypted DNS.

Out-of-Band Key-Pinned privacy profile is usable where the trust between stub and recursive resolvers is already established. Enterprise DNS is one good example. With this profile, DNS clients authenticate servers by a set of (previously distributed) SPKI Fingerprints.

DoT pros and cons

DNS-over-TLS addresses privacy, but not the security of DNS operations. It is important to note that DNSSEC and DoT are not mutually exclusive, but rather compatible protocols that complement each other.

DoT is a straightforward protocol, and fairly easy to implement. TLS authentication is a mature, trusted, and well-maintained technology for encryption. But DNS-over-TLS also presents a number of challenges and concerns.

Attacks against TLS itself, such as protocol downgrade, affect DNS-over-TLS. DNS resolvers offering DoT have to be aware and be patched against TLS vulnerabilities. DNS clients can, in order to defend against person-in-the-middle attacks, discard cached data from a server stored in cleartext.

DoT isn’t fully protected against traffic analysis and SNI leaks. (Although it is in constant development to patch these vulnerabilities.) Split horizon DNS, where the DNS response may be different based on the source of the query, is also known to experience issues when used with DoT.

Network managers for both private networks and public services need to learn more about DNS privacy, DoT (and DoH and other implementations), and the solutions, and challenges, they present for their work. Education about these protocols is also important for end users — both for owning their privacy and to avoid issues resulting from unintentionally harmful configurations brought to a network.

DoT, DoH, and other protocols are in constant development, offering ways to influence their evolution. All network managers and architects, whether they’re running public or private infrastructures, should participate in pilot programs to discover and best voice and address their challenges and requirements.

Topics: DNS-over-TLS, DNS privacy

Why follow Men & Mice?

The Men & Mice blog publishes educational, informational, as well as product-related material for everyone and anyone interested in IP Address Management, DNS, DHCP, IPv6, DNSSEC and more.

Subscribe to Email Updates

Recent Posts