DNS was designed in 1983 with no authentication. A recursive resolver has no way to verify that the answer it receives actually came from the authoritative nameserver. This creates attack surface: an attacker who can inject a forged DNS response can redirect traffic for any domain to any IP. DNSSEC adds cryptographic signatures to DNS responses. Understanding the attacks first explains why DNSSEC exists.

DNS Cache Poisoning#

The Kaminsky attack (2008): DNS queries use UDP, which is connectionless. A resolver sends a query with a 16-bit transaction ID and waits for a response. An attacker can send forged responses with guessed transaction IDs. With 65,536 possible IDs and a fast network, the attacker wins the race before the real authoritative server responds and poisons the resolver’s cache with a malicious IP.

Once the cache is poisoned, all clients using that resolver get the malicious IP for the duration of the TTL. The fix pre-DNSSEC: source port randomization added entropy (combining port and ID gives 32+ bits). Post-fix: DNSSEC.

DNSSEC Signatures#

DNSSEC adds a RRSIG record alongside each DNS record set. The RRSIG is a cryptographic signature of the record, made with the zone’s private key. Resolvers validate the signature using the corresponding public key (DNSKEY record).

The trust chain: the root zone signs the .com zone’s public key. The .com zone signs example.com’s public key. example.com signs its own records. A resolver that trusts the root can validate any record in the chain.

graph TD A[Root zone: signs .com DNSKEY with root private key] --> B[.com zone: signs example.com DNSKEY with .com private key] B --> C[example.com zone: signs A records with example.com private key] C --> D[Resolver: validates chain from root to leaf] D --> E{Signature valid?} E --> |Yes| F[Accept response] E --> |No| G[Reject as forged or tampered] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

DNS Amplification Attacks#

DNS is a DDoS amplification vector. A DNS query is small (50-100 bytes). The response to a query for DNSSEC-enabled domains can be 3,000+ bytes. An attacker spoofs the source IP to the victim’s IP and sends queries to open resolvers. The resolvers send large responses to the victim. Amplification factor: 30-60x.

Mitigations: rate limiting DNS responses per source IP, requiring TCP fallback for large responses (TCP requires a handshake, preventing spoofing), and Response Rate Limiting (RRL) in DNS server software.

DNS over HTTPS#

Traditional DNS is unencrypted and visible to network intermediaries. DNS over HTTPS (DoH) sends DNS queries as HTTPS requests to a DoH resolver (1.1.1.1, 8.8.8.8). The queries are encrypted and indistinguishable from normal HTTPS traffic. This prevents ISP-level DNS snooping but shifts trust to the DoH provider.

At Oracle#

Oracle’s enterprise customers required DNSSEC for their domains hosted on Oracle Cloud DNS. The operational challenge: key rotation. DNSSEC keys must be rotated periodically (every 90-365 days for zone signing keys). Key rollover without a service interruption requires a specific ceremony: publish the new key, wait for TTL to expire so all resolvers know both keys, then switch signing to the new key. Automated key rollover was critical — manual rollover on 10,000+ customer zones was infeasible.

What I’m Learning#

DNSSEC solves authentication but adds operational complexity (key rotation, larger response sizes, validation failures when misconfigured). DoH solves privacy but not authenticity at the protocol level. Most production systems use neither end-to-end but rely on network controls and monitoring to detect cache poisoning attempts.

Have you operated DNSSEC-signed zones, and what was the hardest part of key management in practice?