What Is DNS Encryption?

Domain Name System (DNS) encryption is a new component of modern internet security and privacy, designed to protect the confidentiality of DNS queries. DNS is often called the “phone book of the internet,” as it translates human-readable domain names into IP addresses that computers use to communicate. 

In the original DNS design, queries were transmitted in plain text. This makes them visible to intermediaries who have access to the network path between client software on devices and DNS resolvers it uses to connect to resources on the internet. With extra effort, plain text queries can also be manipulated by a “machine in the middle” to redirect users to phishing sites or other harmful destinations. 

DNS encryption addresses these problems by setting up secure connections between clients and resolvers, making the data unreadable, and ensuring an intermediary between them can’t manipulate the data.

Encrypting DNS traffic has been a focus of the Internet Engineering Task Force (IETF), the organization responsible for defining open standards for the internet. DNS over HTTPS (DoH) and DNS over TLS (DoT) are two of the most visible standards. These protocols define how DNS transactions are encrypted to enhance overall user privacy and cybersecurity. Details of these protocols and additional work defining how users find and connect with encrypted resolvers will be covered in a subsequent section.

Figure 1: DNS encryption encrypts queries between clients and resolvers. DNSSEC authenticates DNS records so they can’t be altered in transit, from the originator of the record to the resolver that requested it for a client.

For completeness, it’s important to point out what DNS encryption doesn’t do. It doesn’t ensure the integrity of the data in DNS responses, because it can’t detect changes in DNS records that an intermediary has made in the DNS path before the resolvers end users connect to. That’s done by DNSSEC, which creates a chain of trust for DNS responses from the root zone through the DNS hierarchy and out to resolvers. Originators of DNS records digitally sign them so resolvers (or in rare cases, clients) can validate responses. By ensuring DNS responses are unaltered and from a source that’s been authenticated, DNSSEC prevents cache poisoning and spoofing attacks.

As more of our daily business and leisure activities move online, DNS encryption adds another layer of protection against unauthorized access to sensitive information and manipulation of internet transactions. It not only safeguards against eavesdropping, it helps maintain trust in the internet’s infrastructure. 

It’s also important to understand how and where DNS encryption is being used to ensure DNS visibility is available, and policies are enforced for legitimate purposes when they’re needed.

Standards for DNS encryption have existed for several years; browsers support it, and a long list of client implementations are available for major operating systems and device types. There are also public encrypted DNS resolvers, like Google and Quad9 and many others, available globally. With widespread support, anyone can connect to almost anything anytime and anywhere.

Figure 2: Enterprises and service providers have different motivations for adopting DNS encryption. Both have highly secure networks with low-risk DNS traffic that adversaries could compromise. Service providers need to explore deployments because encrypted public DNS services may appeal to their subscribers, causing them to move away from provider resolvers.

It’s important for enterprise IT teams to be aware that end users may be connecting to public encrypted DNS services, especially on their own devices. They may perceive these services are acceptable, even at work, precisely because they’re encrypted. Several problems are introduced with this traffic: 

• Security (like a DNS firewall) and acceptable use policies configured in internal DNS resolvers aren’t applied.
• Their traffic can’t be audited for compliance or operational initiatives. 
• Employees won’t be able to resolve internal domains, which creates support overhead and user frustration until the issue is remediated.
• Although they won’t resolve, internal domain names could inadvertently be leaked to external public resolvers, creating privacy and security concerns.
• In some countries, DNS data is considered personally identifiable information (PII), and queries made to public resolvers outside the boundaries introduce ambiguities around responsibility and compliance. 

IT organizations need to continue to ensure endpoints can’t bypass internal DNS resolvers. Networks need to be configured to prevent endpoint devices and applications from connecting to any third-party DNS providers, whether using new encrypted DNS or traditional DNS. Bring-your-own-device (BYOD) policies also need to be updated to exclude using public DNS resolvers.

Although most enterprise networks are highly secure, and it’s challenging for adversaries to infiltrate them and intercept traffic, some organizations may decide DNS encryption is important for internal use. For most organizations to deploy it, a phased approach will be needed to transition different DNS functions over time:

• In-place vendors need to be assessed and resolver alternatives identified if they don’t support the requisite protocols (covered in the next section).
• If not already deployed, implementing DNS firewall capabilities deserves serious consideration. DNS firewalls can be instrumental in stopping malicious activity; they’re efficient and effective, and offer multiple opportunities to detect intrusions in attack lifecycles. 
• Devices that connect outside secure corporate boundaries need to be prioritized, which in a world where work can be conducted from almost anywhere, means most end-user devices will need some client configuration.
• Applications and services in the cloud need to be set up to point to resolvers or services that support DNS encryption.
• On-premises resolvers need to be upgraded to support DNS encryption (deployment considerations are covered in a subsequent section). 

And of course, throughout the whole process, IT teams need to maintain vigilance preventing access to unauthorized “over the top” DNS providers.

Service provider networks are also built with layers of security to deter intruders, but for ISPs and MNOs, the DNS encryption picture is a little different. Service providers have strong motivations to understand and‌ adopt these new protocols because they may fundamentally change the way subscribers perceive DNS.

Public DNS services heavily communicate privacy and security benefits, and make it easy for subscribers to bypass the DNS resolvers that are a central part of provider networks. They also increasingly promote performance and user experience. If subscribers choose to bypass provider resolvers, it opens up a wide range of issues:

• Support and customer satisfaction challenges when users don’t realize their ISP doesn’t deliver the entire internet experience, and call when network issues arise, even if the problem is their external DNS service
• Further commoditization of internet service (what’s left besides bandwidth?) and future opportunities to leverage DNS for value added services are diminished
• Suboptimal user experience and‌ higher costs, especially for CDN traffic, when public DNS resolver locations are substantially different from provider resolvers 
• In-place value-add DNS services for security, parental controls, acceptable use policies, etc., can be bypassed 
• Reduced visibility into DNS traffic, which may be evaluated for user experience, network and user security, traffic management, load balancing, and capacity planning 

ISPs and MNOs have the option to deploy resolvers that support DNS encryption to retain users who perceive there are privacy and security benefits (a subsequent section discusses deployment considerations). On the positive side, providers can also create value-added services with resolvers that support DNS encryption. For instance, services that keep business and consumer subscribers connected to encrypted DNS resolvers with built-in DNS firewall capabilities when they’re visiting a Wi-Fi hotspot and their traffic transits untrusted networks. 

Whether a decision is made to support DNS encryption, ISPs and MNOs need to ensure their DNS resolution infrastructure is the best it can be: 

• Invest in resolution infrastructure with demonstrable high performance and low latency, especially for recursive queries that are more complex and can introduce more delay. Evaluate how stability, high availability, and resilience are maintained under extreme loads so massive bursts of legitimate or malicious traffic can be accommodated without impacting user experience. 
• Implement best practices for DNS infrastructure; right-size subscriber density, properly situate resolvers to optimize proximity, gain network insights with monitoring; embed robust security posture. 
• Publicize your DNS service to shape user perceptions. If not already deployed, consider value-added DNS-based security and personalization services to cement the subscriber bond and differentiate core internet access offers. DNS firewall capabilities can be instrumental in stopping malicious activity. They’re efficient and effective, and offer multiple opportunities to detect intrusions in attack lifecycles, with only an incremental change in DNS infrastructure.
• Prepare for future deployment of DNS encryption by contributing to relevant standards to ensure DNS encryption standards implementations deliver the same “just works” experience users have today, and are compatible with operational systems.

Today, two approaches are used to encrypt DNS traffic: DNS over HTTPS (DoH) and DNS over TLS (DoT). 

• The DNS over HTTPS protocol (DoH) is specified in IETF RFC 8484. DoH uses the same port, 443, as HTTPS. As with DoT, user devices can connect to “over the top” public DNS services and in enterprise environments need to be managed accordingly. Because it uses the same port as HTTPS, it’s impossible to identify DoH in standard web traffic, which raises obvious security and operational concerns. 
• DoT uses the Transport Layer Security (TLS) protocol to encrypt DNS traffic. It operates on a dedicated port (port 853) and is designed to provide a more straightforward and efficient method of securing DNS communications. Because it uses a dedicated port, it is easy to detect DoT in network traffic, a useful characteristic for network operators and security teams.

Another emerging technology in this space is DNS over QUIC (DoQ), which builds on the QUIC protocol to provide even faster and more secure DNS resolution. QUIC is a modern transport protocol that minimizes latency and enhances security, making DoQ a promising option for future DNS encryption needs.

All these transport solutions offer robust protection against machine-in-the-middle attacks and DNS spoofing (although as stated earlier, they don’t detect changes in DNS records that an intermediary has made in the DNS path before the resolver the user connects to).

The IETF has defined additional standards that allow clients to find and connect to resolvers that support DNS encryption. RFC9642 (Discovery of Designated Resolvers [DDR]) specifies how clients that have only been configured with the address or hostname of an unencrypted DNS resolver (Do53) can find an encrypted resolver. There are no dependencies on specific versions of DNS or Dynamic Host Configuration Protocol (DHCP) software or use of IPv6. RFC9643 (Discovery of Network Resolvers [DNR]) explains how clients can find encrypted resolvers with DHCPv4, DHCPv6, and IPv6 router advertisement options.

Still more IETF work will guide how traffic between resolvers and authoritative servers is encrypted.

The shift to TCP-based secure transport to support DNS encryption is a major change from almost exclusively UDP-based transport today. To maximize network efficiency, resolvers will have to support today’s TCP and UDP protocols, as well as multiple transport-level authentication and encryption options going forward.

Resolver performance is driven by client implementations. Connection setup overhead must be understood, and resolvers need to be tuned for TCP-based services in addition to UDP-based services. Session reuse (reusing established sessions for multiple queries) must be evaluated as well, since it can have a large impact on performance. Failure conditions and resultant bursts of connection setup requests also need to be factored into dimensioning decisions.

Traffic types will shift as client implementations change. Monitoring and comparing Do53, DoT, and DoH workloads on an ongoing basis will allow operations teams to make educated capacity planning decisions. Insights into these factors can be found in a presentation at the DNS-OARC conference held in 2020: DNS Encryption Operational Experience and Insights.

For most deployments, advancements in modern server hardware accommodate scaling of TLS termination, negating the need for specialized appliance-based solutions. Network teams in highly scaled deployments, where additional equipment needs to be deployed for terminating secure transports, will have to assess impact on costs and operational burden. They’ll also have to understand changes to troubleshooting workflows with separate interfaces for transport layer problems and DNS resolution itself. Different operational teams will also need to be coordinated to resolve issues.

Because it runs over HTTPS, the advent of DoH introduced the possibility of tighter integration with applications, and DoH implementations have been released in browsers. Any app can choose to implement DoH, and it’s also supported in several public or “over the top” DNS resolution services. 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 device’s operating system, which typically queries resolvers provisioned by the operator of the network a device is connected to.

Fragmentation of DNS resolution among applications adds another dimension for network operators (and security teams, as discussed earlier), especially at ISPs where no one is guiding who can and can’t use application extensions like DNS encryption. One of the most obvious risks is substantially complicating troubleshooting when connectivity problems arise. Individual applications could choose different resolvers and have different methods for exposing that choice to the user (or not exposing it at all). They could also have different philosophies about respecting local DNS filtering policies required for regulatory compliance, for instance. 

The threat landscape may also evolve as attackers explore whether encrypted DNS paths offer any advantages. In the past, it was easy to monitor DNS traffic, but encrypting the transport with DoH complicates the picture since DNS queries look no different than massive volumes of HTTPS traffic traversing a network. 

One possible solution is to break the bootstrapping mechanism exploits use. DoH stub resolvers have to query special hostnames to obtain the IP addresses of DNS resolution services before they can establish a connection. The stub has to use the default resolver in the operating system on the device where it resides in order to accomplish this, which is usually configured by the local network (such as a provider network). Security vendors can track hostnames of malicious resolvers so access to them can be blocked.

To summarize, for most enterprises today, DNS encryption may not prove to be a good value. But for ISPs and MNOs, the visible presence of numerous public DNS alternatives means some level of DNS encryption deployment may be necessary to keep privacy-driven subscribers connected to their resolvers.

The presence of public DNS providers also amplifies provider incentives to ensure all of their DNS resolution services are robust and performant. Public DNS resolver providers promote performance too. Resolvers are the glue that connects subscribers to their fixed and mobile broadband services. Their performance and latency has a direct impact on how users perceive their internet access. If operators of public DNS services succeed in persuading subscribers their resolvers are better, they gain control of the user experience and extract the associated value.

Deployment of DNS encryption will continue, with ongoing developments and improvements in the technology. If compliance regulations become more prominent, and more countries and regions implement stricter data privacy laws, encrypted DNS can help organizations meet them — especially those that handle sensitive information and need to maintain high levels of data security. Stay informed about the latest trends and technologies, users, and organizations to ensure you’re properly equipped to act quickly and effectively when it becomes necessary to deploy.