As part of a larger effort to make the internet more private, the IETF defined two protocols to encrypt DNS queries between clients (stub resolvers) and resolvers: DNS over TLS in RFC 7858 (DoT) and DNS over HTTPS in RFC 8484 (DoH). As with all new internet protocols, DoT and DoH will continue to evolve as deployment experience is gained, and they’re applied to more use cases. To understand more about the motivation for developing these protocols, and how they might be used, an excellent post: “Architectural paths for evolving the DNS” can be found on Akamai’s corporate blog.

Because it runs over HTTPS, the advent of DoH introduced the possibility of tighter integration with applications, and an implementation of DoH has been released in the Firefox browser. DoH is also supported in several public or “over the top” DNS resolution services. The combination of these two developments has important implications for ISPs (and other network operators) and the people who use their networks.

Migrating DNS resolution to applications is a significant change. In the past, applications running on devices relied on a stub resolver (implemented as part of the devices operating system) which typically query resolvers provisioned by the operator of the network a device is connected to.^[1] Fragmentation of DNS resolution among applications raises a number of concerns. One of the most obvious is the risk of substantially complicating troubleshooting when connectivity problems arise. Many other considerations that arise from how a browser or application selects a resolver are discussed below.

For the time being, developers of DoH client implementations control which resolver they’ll use. RFC 8484 does not specify any mechanisms to discover a DoH resolver and connect to it. Yet operation of DoH at provider scale will require automated methods for operating systems and applications to discover and connect to DoH resolvers that “just work,” just like today when ISPs provision resolvers as part of their internet access services. Some of the methods that have been proposed, and in some cases implemented, are discussed below.

Application uses resolver configured by the local network

Most applications today use the resolver configured in the operating system by the local network operator, usually with DHCP. Applications that use DoH can also be adapted to choose resolvers configured in this way. Enlightened application developers may also create approaches that preserve filtering capabilities devices users have chosen to protect them from malware or enable parental controls.

Building around existing provisioning mechanisms is a pragmatic solution as the community learns more about how new encryption protocols are deployed and how they behave at mass scale. However concerns have been expressed about the security of DHCP. There’s risk associated with active network attackers compromising configuration channels to force resolvers to use cleartext DNS on port 53. Furthermore, while users may have a trusted contractually defined relationship with their ISPs, a user can’t easily tell when their device is getting network configuration from their ISP versus an untrusted entity like a compromised coffee shop wifi network.

These and other provisioning risks that may be uncovered can be addressed with new standards.

Application ships with a configured resolver

A browser or other application overriding the resolver configured by a local network represents a significant change from today. Even if the configured resolver is exposed to the user, any “consent” is likely to be poorly informed. Uninformed consent can subvert security or parental controls a user may have consciously chosen to implement in their home or elsewhere. It can also introduce other issues like suboptimal content mapping, which directly impacts the quality of experience. Users also may not realize encrypting the transport for their DNS queries doesn’t prevent attacks on resolvers that can reveal their data, and operators of the resolvers see all of their traffic in the clear. Finally, when subscribers move away from their service providers’ DNS resolvers, they may not realize it can escalate troubleshooting challenges. These and more issues are explored in the Informational Internet Draft “Centralized DNS over HTTPS (DoH) Implementation Issues and Risks.”^[2]

Application displays a menu of resolver choices

Offering a menu of resolver choices empowers users, but doesn’t account for the overwhelming majority who are unfamiliar with DNS. It’s unrealistic to expect they can make informed decisions; instead, they may reflexively check the option at the top of a menu, or choose one that “sounds fast” or “looks secure.” All of the issues described above apply if a user chooses a resolver that’s unaware of their local network.

Application presents a dialog for manual configuration of a resolver

Manual configuration preserves choice but requires users to find and assess DNS resolution services. Expert users may be able to evaluate the merits of alternative resolution services and understand the implications of the wrong choice, but most users cannot, and off-network choices introduce the issues above.

* * *

Recognizing the need to accommodate provider requirements, work in the IETF is progressing to define how operating systems and applications can discover and connect with a DoH or DoT compatible resolver. As is typical, Internet-Drafts are being proposed and debated in a rapidly evolving effort, although none of the specifications are yet adequate for implementation or deployment.

Akamai and many other companies and members of the internet community are contributing resources to formulate standards for provisioning DoH resolvers that are compatible with ISP operational systems and processes. The goal is to define client implementations for discovery and configuration workflows that will allow subscribers to automatically connect to encrypted resolvers offered by ISPs and other entities that provide resolution services. There are lots of technical details to resolve, but whatever provisioning methods are chosen, they must preserve choice and eliminate the configuration burden, just like in today’s networks.

[1] Most operating systems give users a choice to manually configure a DNS resolver, if they prefer an alternative to a locally configured resolver, this configuration overrides resolvers provisioned by network operators
[2] https://www.ietf.org/id/draft-livingood-doh-implementation-risks-issues-03.txt