Skip to content

Needing the DoH: The Ongoing Encryption and Centralization of DNS

Security researchers examine technical aspects of Needing the DoH: The Ongoing Encryption and Centralization of DNS.

Summary

## Overview

Presented by Eldridge Alexander of Duo Security (Duo Labs), this talk addresses the transition of DNS from a historically cleartext, distributed protocol toward modern encryption and centralization. Created in 1983 by Paul Mockapetris and Jon Postel, DNS was originally designed without encryption to replace cumbersome, universally distributed `hosts` files and to prioritize widespread adoption. While HTTP shifted toward HTTPS over the past few decades—growing from under 50% to over 90% adoption between 2015 and 2020 according to Google's transparency report—DNS remained largely unencrypted for 37 years.

## The Shrinking Visibility of Web Traffic

As web architecture evolved, intermediate network observers ("middleware," whether automated or human) progressively lost visibility into traffic:

- **Protocol Absorption:** Most internet communication protocols (email via SMTP/POP, chat via XMPP, file transfers via FTP) were absorbed into HTTP/HTTPS interfaces, WebSockets, or WebRTC. - **Loss of IP Distinctiveness:** The emergence of cloud hosting (AWS, Google Cloud, Azure, DigitalOcean, Rackspace) and CDNs/reverse proxies (Cloudflare, Fastly) broke the historical 1:1 mapping between IP addresses and unique hosts. Intermediate observers inspecting destination IPs merely see shared CDN or cloud provider IP blocks rather than the underlying web host. - **Encrypted SNI in TLS 1.3:** While Server Name Indication (SNI) exposed destination hostnames in the clear during TLS 1.2 handshakes, TLS 1.3 introduced encrypted SNI mechanisms, blinding middleware to the host header. - **DNS as the Final Plaintext Vector:** With HTTP payloads, hostnames, and IP distinctiveness obscured, plaintext DNS queries became the last remaining data point exposing a user's browsing destinations.

## Benign vs. Malicious Middleware Capabilities

The talk outlines how identical network inspection and alteration capabilities serve contrasting roles depending on intent and network context:

- **Visibility vs. Non-Stakeholder Aggregation:** Enterprise network operators use query visibility to monitor managed devices, whereas ISPs or third parties intercept consumer queries solely for data harvesting that provides no value to the user or content provider. - **Malware Blocking vs. Response Alteration:** Defenders block threats by sinkholing known malicious domains (e.g., returning `0.0.0.0`), while unscrupulous ISPs alter non-resolvable domain queries (NXDOMAIN) to redirect users to ad pages for monetization. - **Defense vs. Reconnaissance:** Organizations use DNS monitoring for data loss prevention (DLP), whereas adversaries analyze captured queries for reconnaissance to stage targeted attacks.

## Emerging Protocols and Industry Concerns

To protect DNS, new standards have emerged: - **DNSCrypt:** Noted as technically sound, but lacking broad cross-vendor and endpoint adoption. - **DNS over TLS (DoT) & DNS over HTTPS (DoH):** The primary protocols gaining industry-wide traction.

However, encrypting DNS introduces key operational and structural challenges: 1. **Centralization:** While not inherent to the protocols themselves, early deployment concentrated massive volumes of encrypted queries into a tiny handful of major upstream providers—specifically Google, Cloudflare, and Quad9. 2. **Reduced Visibility:** Network defenders face diminished capabilities for endpoint monitoring, threat detection, and enterprise data loss prevention. 3. **DNS Operating in Layer 7:** DoH moves name resolution into the application layer (HTTP/HTTPS), creating an unprecedented shift in standard network architectural boundaries.

Related talks