DNS Security: DNSSEC, DoH, and DoT Explained

Advanced

The Domain Name System is often called the phone book of the internet. Every time you visit a website, your device issues a DNS query to translate a human-readable domain name into an IP address. Despite this critical role, DNS was designed in 1983 (RFC 882 and RFC 883, later consolidated in RFC 1034 and RFC 1035) without any built-in security mechanisms. Queries travel in plaintext over UDP port 53, with no authentication of responses and no encryption of data in transit. For over two decades, this fundamental insecurity was treated as an acceptable trade-off for speed and simplicity. The Kaminsky attack of 2008 permanently changed that calculus, triggering an industry-wide push toward DNS security technologies that continues today.

This article examines the three pillars of modern DNS security: DNSSEC for response authentication, DNS over HTTPS (DoH) for encrypted resolution via the web, and DNS over TLS (DoT) for encrypted resolution via a dedicated channel. Understanding these technologies is essential for anyone managing CDN infrastructure, configuring CDN DNS resolution, or building a zero-trust security architecture.

Why Is Traditional DNS Insecure?

Traditional DNS suffers from three categories of vulnerability: lack of authentication, lack of encryption, and protocol-level weaknesses that enable cache poisoning. Each of these creates distinct attack surfaces that modern DNS security extensions are designed to close.

No authentication. When a recursive resolver receives a DNS response, it has no way to verify that the response actually came from the authoritative name server. The only validation is matching the 16-bit transaction ID and the source port of the original query. An attacker who can guess or observe these values can inject forged responses that the resolver will accept as legitimate.

No encryption. Every DNS query and response is transmitted in cleartext. Any entity on the network path, whether an ISP, a Wi-Fi hotspot operator, or a man-in-the-middle attacker, can observe the full content of DNS traffic. This reveals the complete browsing history of every user, creating both privacy and security concerns.

Cache poisoning. DNS resolvers cache responses to reduce latency and load on authoritative servers. If an attacker can inject a forged response before the legitimate response arrives, the false record is cached and served to all subsequent clients for the duration of its TTL. Before the Kaminsky disclosure, cache poisoning was considered theoretically possible but practically difficult. Kaminsky proved otherwise.

What Was the Kaminsky DNS Attack and Why Did It Matter?

In early 2008, security researcher Dan Kaminsky discovered a method to poison DNS caches far more efficiently than any previously known technique. Classical cache poisoning attacks required an attacker to wait for a cached record to expire, then race to inject a forged response during the narrow window when the resolver queried the authoritative server. Kaminsky's insight eliminated the waiting period entirely.

The attack worked by querying a resolver for random, non-existent subdomains of the target domain, for example, abc123.example.com. Since these subdomains did not exist in the cache, each query forced the resolver to contact the authoritative server immediately. The attacker simultaneously flooded the resolver with forged responses, each containing a different guessed transaction ID and an authority section that delegated the entire example.com zone to an attacker-controlled name server. With only 65,536 possible transaction IDs (16 bits), and the ability to send thousands of forged responses per attempt, a successful poisoning could be achieved within seconds.

Kaminsky coordinated a secret multi-vendor patch effort before his public disclosure at Black Hat USA on August 6, 2008. The patches added source port randomization, expanding the effective entropy from 16 bits to approximately 32 bits. However, the fundamental architectural weakness remained: DNS responses were still unauthenticated. The Kaminsky attack became the strongest argument for accelerating DNSSEC deployment, which had been under development since the mid-1990s but had seen minimal adoption.

How Does the DNSSEC Chain of Trust Work?

DNSSEC (Domain Name System Security Extensions) adds cryptographic authentication to DNS without changing the underlying protocol. Rather than encrypting DNS traffic, DNSSEC allows resolvers to verify that a DNS response genuinely originated from the authoritative source and was not modified in transit. The core specifications are RFC 4033 (Introduction and Requirements), RFC 4034 (Resource Records), and RFC 4035 (Protocol and Operational Practices), published in March 2005.

DNSSEC introduces four new DNS record types that work together to create a verifiable chain of trust from the DNS root zone down to individual resource records:

The chain of trust begins at the DNS root zone. On July 15, 2010, the root zone was signed for the first time in a ceremony at ICANN's facility in Culpeper, Virginia. The root zone's KSK is the trust anchor: validating resolvers are preconfigured with this key (or its hash). When a resolver queries for example.com, it follows the delegation chain: the root zone's DS record authenticates the .com TLD's DNSKEY, which in turn authenticates example.com's DNSKEY via another DS record, and finally example.com's DNSKEY verifies the RRSIG over the requested A records.

If any link in this chain is broken, a missing DS record, an expired RRSIG, or a mismatched key, the validating resolver returns a SERVFAIL error rather than delivering potentially tampered data. This strict validation is DNSSEC's greatest strength and its greatest operational challenge: a misconfigured zone can make an entire domain unreachable for users behind validating resolvers.

What Are the Deployment Challenges of DNSSEC?

Despite being standardized in 2005 and having the root zone signed in 2010, DNSSEC adoption has been gradual. As of 2025, approximately 30% of the Alexa top million domains are signed, and roughly 25-30% of DNS resolvers worldwide perform DNSSEC validation. Several factors contribute to this slow adoption:

Key management complexity. DNSSEC requires regular key rotation. The KSK typically rotates every one to two years, and the ZSK rotates every one to three months. Each rotation requires coordinating changes across the domain's authoritative servers and the parent zone's DS records. A failed rotation can cause a complete domain outage.

Response size amplification. DNSSEC signatures significantly increase DNS response sizes. A typical unsigned A record response is 60-80 bytes; with DNSSEC, it can exceed 1,500 bytes. This often requires TCP fallback (since UDP datagrams are limited to 512 bytes without EDNS0, or 4,096 bytes with it), increasing latency and server load.

NSEC zone walking. The original NSEC record type allows attackers to enumerate every record in a zone by following the chain of NSEC records. NSEC3 (RFC 5155, published March 2008) mitigates this by using hashed owner names, though sophisticated dictionary attacks can still reveal common record names.

How Does DNS over TLS (DoT) Encrypt DNS Queries?

DNS over TLS, specified in RFC 7858 (published May 2016), wraps standard DNS messages inside a TLS connection on dedicated port 853. The resolver and the client establish a TLS handshake, authenticating the server and negotiating encryption parameters, before any DNS queries are exchanged. All subsequent queries and responses are encrypted and integrity-protected by the TLS session.

DoT provides confidentiality (preventing eavesdroppers from reading DNS queries), integrity (detecting any modification of DNS data in transit), and server authentication (verifying the identity of the DNS resolver). The use of a dedicated port makes DoT straightforward for network administrators to identify, monitor, and manage. Enterprise networks can allow DoT traffic while blocking unencrypted DNS on port 53, ensuring all DNS traffic is encrypted.

However, the dedicated port is also DoT's limitation: network operators or censors who want to block encrypted DNS can simply block port 853. This is trivial compared to blocking DoH, which shares port 443 with all HTTPS traffic. In countries with internet censorship, DoT is frequently blocked at national firewalls.

Major public resolvers support DoT, including Google Public DNS (dns.google on port 853), Cloudflare (1.1.1.1 on port 853), and Quad9 (dns.quad9.net on port 853). Android 9 and later natively support DoT through the "Private DNS" setting, making it the most widely deployed encrypted DNS protocol on mobile devices.

How Does DNS over HTTPS (DoH) Differ from DoT?

DNS over HTTPS, specified in RFC 8484 (published October 2018), sends DNS queries as HTTP requests over a standard HTTPS connection on port 443. The DNS message is encoded either as a binary DNS wireformat payload (with content type application/dns-message) or as a JSON object (as defined in RFC 8427), and transmitted via HTTP/2 or HTTP/3.

The critical distinction is that DoH traffic is indistinguishable from regular HTTPS traffic at the network level. A network observer sees an HTTPS connection to a known resolver's IP address but cannot distinguish DNS queries from regular web requests. This makes DoH extremely resistant to censorship: blocking it requires blocking all HTTPS traffic to the resolver, which typically also hosts other services.

DoH has been embraced by browser vendors. Mozilla Firefox has supported DoH since version 62 (September 2018) and enables it by default for US users using Cloudflare's resolver. Google Chrome has supported DoH since version 83 (May 2020), automatically upgrading to DoH when the user's configured DNS provider supports it. Apple added DoH support to iOS 14 and macOS 11 in 2020.

The deep integration of DoH with TLS-encrypted web traffic provides strong privacy guarantees but has generated controversy. Enterprise network administrators and ISPs argue that DoH bypasses network-level security policies, parental controls, and split-horizon DNS configurations. The tension between user privacy and network operator visibility remains an active area of debate within the IETF and the broader internet governance community.

How Do DoH, DoT, and DNSSEC Compare?

A common misconception is that DNSSEC, DoH, and DoT are competing technologies. In reality, they address different threat vectors and are complementary. The following table summarizes their distinct roles:

The most robust DNS security posture combines DNSSEC with either DoH or DoT. DNSSEC ensures that the DNS data itself is authentic from its authoritative source, while DoH or DoT ensures that the query and response are protected from eavesdropping and manipulation on the path between the client and the resolver. Neither technology alone provides complete protection.

How Do CDNs Integrate DNS Security?

CDN providers sit at the intersection of DNS security and content delivery, making their support for these technologies particularly important. CDN edge servers rely on accurate DNS resolution to direct users to the nearest point of presence. If DNS is compromised, users can be redirected to malicious servers, bypassing all other security measures.

Cloudflare operates one of the world's largest DNS resolver networks (1.1.1.1) and supports all three technologies. Their authoritative DNS service offers one-click DNSSEC activation with automatic key management, and their resolver supports both DoH (https://cloudflare-dns.com/dns-query) and DoT (port 853 on 1.1.1.1). Cloudflare's CDN automatically signs zones with DNSSEC using ECDSA P-256 keys, producing smaller signatures than traditional RSA-based DNSSEC.

AWS CloudFront with Route 53 supports DNSSEC signing for public hosted zones, introduced in December 2020. Route 53 manages KSK rotation and automatically generates ZSKs. The integration with CloudFront ensures that CDN-distributed content is served from domains with verifiable DNSSEC chains.

Akamai provides DNSSEC through its Edge DNS service and operates a public DoH resolver for enterprise customers. Akamai's approach emphasizes using DNS security as the first layer of a defense-in-depth strategy, blocking malicious domains at the DNS level before connections are established.

For organizations using CDN infrastructure, enabling DNSSEC on authoritative zones and configuring clients to use DoH or DoT resolvers creates a significant barrier against DNS-based attacks. This is especially critical for CDN DNS resolution where Anycast routing depends on the integrity of DNS responses to direct users to the correct edge servers.

What Is the Future of DNS Security?

Several emerging developments are shaping the next generation of DNS security:

Oblivious DNS over HTTPS (ODoH). Specified in RFC 9230 (published June 2022), ODoH adds a proxy layer between the client and the DoH resolver, ensuring that the proxy knows the client's IP but not the query, and the resolver sees the query but not the client's IP. This eliminates the resolver as a single point of trust for privacy. Cloudflare, Apple, and Fastly collaborated on the initial deployment.

DNS over QUIC (DoQ). RFC 9250 (published May 2022) defines DNS over QUIC, combining the encryption of DoT with the connection-establishment speed of QUIC's 0-RTT handshake. DoQ uses dedicated port 853 (shared with DoT) but runs over UDP with QUIC's built-in encryption and multiplexing. AdGuard DNS was among the first public resolvers to support DoQ.

Multi-signer DNSSEC (RFC 8901). This specification allows multiple DNS providers to independently sign the same zone with their own keys, enabling redundant DNSSEC configurations across multiple CDN or DNS providers without sharing private keys. This is particularly valuable for organizations that use multiple CDN providers for resilience.

Encrypted Client Hello (ECH). While not a DNS technology itself, ECH (formerly ESNI) encrypts the SNI field in the TLS handshake, which previously leaked the destination hostname even when DNS was encrypted. Combined with DoH or DoT, ECH closes the last major metadata leak in the connection establishment process, providing comprehensive privacy from the DNS lookup through the TLS handshake to the encrypted data transfer.

What Best Practices Should Organizations Follow?

Implementing DNS security effectively requires attention to both technical configuration and operational practices. The following recommendations reflect current industry consensus:

Enable DNSSEC on all authoritative zones. Use your DNS provider's managed DNSSEC service when available to minimize the operational burden of key management. Monitor DNSSEC validation rates and set up alerting for signature expiration events. If you manage keys manually, automate the rotation process to prevent accidental zone outages from expired signatures.

Deploy DoH or DoT for recursive resolution. For organizational networks, configure DoT on dedicated internal resolvers and enforce its use via firewall rules that block plaintext DNS on port 53. For user-facing applications, integrate DoH support at the application level. Browser-based DoH provides immediate privacy benefits for end users without requiring any network infrastructure changes.

Monitor DNS traffic for anomalies. Even with encryption, DNS traffic patterns can reveal compromises. Unusual query volumes, unexpected resolver addresses, or queries for known malicious domains should trigger alerts. Network security monitoring tools should be configured to detect both unencrypted DNS traffic (which may indicate bypass attempts) and high volumes of DoH connections to unknown resolvers.

Combine with broader security architecture. DNS security is one component of a comprehensive zero-trust security model. Pair DNSSEC with Certificate Transparency monitoring, HTTPS Strict Transport Security (HSTS), and content security policies to create multiple layers of defense against connection hijacking and content manipulation.

The evolution from plaintext, unauthenticated DNS to the current landscape of DNSSEC, DoH, and DoT represents one of the most significant security upgrades to core internet infrastructure. While adoption continues to grow, the technologies are mature, widely supported by CDN and DNS providers, and essential for any organization taking DNS security seriously. The question is no longer whether to deploy DNS security, but which combination of these complementary technologies best fits your operational requirements and threat model.