The Need for DNS Encryption: Beyond Plaintext Queries

The Domain Name System (DNS) is a foundational protocol that translates human-readable domain names into IP addresses. Despite its critical role, traditional DNS traffic has historically been sent in plaintext over UDP or TCP, leaving it vulnerable to eavesdropping, manipulation, and cache poisoning. Attackers on the same network or within the path of a query can intercept DNS responses to redirect users to malicious sites or to collect browsing metadata. As internet privacy concerns have escalated, two complementary encryption protocols have emerged to protect DNS traffic: DNS over HTTPS (DoH) and DNS over TLS (DoT).

Both protocols encrypt the query and response data, shielding it from observation and tampering. However, they differ in implementation, port usage, and how they integrate with existing network stacks. Understanding these differences is essential for choosing the right approach for individual users, network administrators, and application developers.

DNS over HTTPS (DoH): Embedding Lookups in Web Traffic

DNS over HTTPS wraps traditional DNS queries and responses inside standard HTTPS requests and responses, using the same port 443 used for regular web traffic. This design makes DoH traffic indistinguishable from other HTTPS traffic to network observers, unless they perform deep packet inspection or analyze server IP addresses. DoH was standardized in RFC 8484 and has been adopted by major browsers like Mozilla Firefox and Google Chrome

How DoH Works

When a client (browser or application) wants to resolve a domain, it sends an HTTP POST or GET request to a DoH-compatible resolver (such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8). The DNS query is encoded in the request body or query string, and the resolver responds with a DNS response encoded in the HTTP response body. Because the entire transaction occurs over HTTPS, all encryption, authentication, and certificate validation provided by TLS are inherited.

Key Advantages of DoH

  • Covert integration: By using port 443 and HTTPS framing, DoH traffic blends with normal web traffic, making it harder for network filtering or blocking to target DNS queries without causing collateral damage to web browsing.
  • Easy deployment in applications: Browsers and apps can implement DoH without requiring changes to the operating system's DNS configuration. Users can simply enable a setting or install an extension.
  • Leverages existing HTTPS infrastructure: DoH can reuse the same HTTP/2 or HTTP/3 connections and leverage mature load balancing, caching, and content delivery networks (CDNs) that power the modern web.

Considerations and Criticisms

Despite its privacy benefits, DoH has sparked debate. Network administrators often lose visibility into DNS traffic because individual applications can bypass system-level DNS settings. This can hinder content filtering, parental controls, and enterprise security policies. Moreover, DoH introduces a slight performance overhead due to HTTP framing and the need for separate TLS handshakes (though HTTP/2 multiplexing mitigates this). Some critics argue that DoH centralizes DNS resolution to a few large providers, potentially creating new points of surveillance or control.

DNS over TLS (DoT): System-Level Security on a Dedicated Port

DNS over TLS (DoT) uses the TLS protocol but communicates over a dedicated port (853) rather than piggybacking on HTTP. This approach was defined in RFC 7858 and is typically configured at the operating system level or on routers, ensuring that all DNS traffic from every application is encrypted.

How DoT Works

A DoT client establishes a TCP connection to a resolver on port 853 and performs a TLS handshake. After successful authentication of the resolver's certificate, the DNS messages are exchanged directly over the TLS session, using the same wire format as traditional DNS but within an encrypted tunnel. Because DoT uses a unique port, it can be easily identified and managed by network firewalls and routing policies.

Key Advantages of DoT

  • System-wide enforcement: Once DoT is configured at the OS or router level, all applications benefit from encryption without needing individual support. This is particularly valuable for mobile devices, IoT gadgets, and enterprise networks.
  • Simple to monitor and filter: Administrators can allow or block DoT traffic based on the dedicated port and known resolver IPs, making it easier to maintain policies compared to the hidden nature of DoH.
  • Efficient wire format: DoT does not add HTTP headers or multiplexing overhead, resulting in lower per-query latency in many scenarios. The binary DNS protocol is preserved, reducing processing requirements.

Considerations for DoT

DoT's reliance on a dedicated port makes it easier to block if a network operator or ISP decides to restrict encrypted DNS. Because DoT is usually configured system-wide, support in consumer devices is still growing. Android and iOS began supporting DoT at the OS level only in recent versions, and many routers lack built-in options for configuring DoT upstreams.

DoH vs. DoT: A Side-by-Side Comparison

Feature DNS over HTTPS (DoH) DNS over TLS (DoT)
Standard RFC 8484 RFC 7858
Transport port 443 (HTTPS) 853 (reserved)
Traffic visibility Hidden among web traffic Distinguishable by port
Typical deployment Application level (browser, app) System level (OS, router)
Authentication HTTPS certificate validation TLS certificate validation
Performance overhead Higher due to HTTP framing Lower; binary wire format
Ease of blocking Difficult without breaking web Easier via port 853
Centralization risk Higher (browser defaults) Lower (admin-controlled)

Neither protocol is inherently superior. The choice depends on the context. For individual privacy-conscious users who control their own devices, DoH provides a convenient way to bypass local DNS snooping without altering system settings. For network administrators who require consistent encryption across all devices, DoT offers a more manageable and auditable solution.

Implementing Encrypted DNS: Practical Considerations

Client-Side Configuration

Most modern browsers have built-in DoH support. Firefox users can enable DoH in the network settings, while Chrome respects the system's DNS-over-HTTPS policy if configured. On Windows 11, users can set DoH or DoT for specific resolvers in the network adapter properties. macOS and Linux users can configure stub resolvers like stubby (DoT) or use tools like dnscrypt-proxy that support both protocols.

Resolver Selection

Reputable public resolvers offering both DoH and DoT include Cloudflare (1.1.1.1), Quad9 (9.9.9.9), and Google (8.8.8.8). Each has different privacy policies: Cloudflare pledges not to log personally identifiable information, Quad9 blocks malicious domains by default, and Google uses anonymization techniques. Users should verify the resolver's trustworthiness and compliance with local laws.

Potential Drawbacks

Encrypted DNS can conflict with network security tools like intrusion detection systems that rely on inspecting DNS queries. It may also break captive portals (public Wi-Fi login pages) that require plaintext DNS to redirect users. Some enterprise environments block all external encrypted DNS to enforce corporate filtering policies. In such cases, administrators must adopt a strategy—either using a dedicated internal encrypted resolver or employing DANE (DNS-Based Authentication of Named Entities) for DoT.

The Future of DNS Encryption

Beyond DoH and DoT, new protocols are pushing the envelope further. DNS over QUIC (DoQ) leverages the QUIC transport protocol to reduce latency and improve resilience over unreliable networks. Oblivious DoH (ODoH) adds a proxy layer to prevent the resolver from linking queries to client IP addresses, providing stronger metadata privacy. Meanwhile, the IETF's DNS over HTTPS Certificate Storage enables CAs to publish certificate transparency logs via DNS, enhancing trust.

As internet standardization organizations continue to refine these protocols, adoption is expected to grow. Major browsers and operating systems are already shipping with encrypted DNS enabled by default in some regions. Network operators and DNS infrastructure providers must prepare for a future where unencrypted DNS becomes the exception rather than the norm.

Conclusion

DNS over HTTPS and DNS over TLS represent a critical evolution in preserving user privacy and security on the internet. Both protocols encrypt the domain resolution process, preventing many common attacks that exploit unencrypted DNS. While DoH offers seamless integration with web applications and better covertness, DoT provides a robust, system-wide solution that is easier to manage in professional networks. Understanding their differences empowers users, developers, and IT professionals to make informed choices that align with their security requirements and operational constraints.

For further reading, refer to the official RFCs: RFC 8484 (DoH), RFC 7858 (DoT), and Cloudflare's DoH documentation. As the internet continues to evolve, encrypted DNS will remain a cornerstone of a safer, more private web.