DNS Security
DNS was designed for functionality, not security. Understanding the attack surface and available defenses is essential for every infrastructure professional.
Common DNS Attacks
Know the attack vectors before you can defend against them
DNS Cache Poisoning
CriticalAn attacker injects forged DNS responses into a resolver's cache, redirecting users to malicious servers without their knowledge. The resolver serves the bogus answer to all subsequent queries until TTL expires.
DNS Hijacking
CriticalUnauthorized modification of DNS records — either through registrar account compromise, BGP hijacking, or malicious DNS resolver modification. Attackers redirect entire domains or TLDs.
DNS Amplification (DDoS)
HighAttackers send small queries with a spoofed victim IP to open DNS resolvers. Resolvers send large responses (amplification factor up to 100x) to the victim — overwhelming their bandwidth.
DNS Tunneling
HighData exfiltration or C2 communication encoded in DNS queries and responses. Used to bypass firewalls and proxies that allow DNS traffic. TXT and NULL records are common carriers.
NXDOMAIN Attacks
HighFlooding recursive resolvers with queries for nonexistent domains, consuming CPU and memory as the resolver processes negative responses. Can degrade service for legitimate queries.
BGP Hijacking of DNS
CriticalRouting infrastructure attacks that divert traffic destined for DNS servers to attacker-controlled infrastructure. Can affect root servers, TLD nameservers, or authoritative nameservers.
DNS Security Extensions
Cryptographic authentication for DNS records — the primary defense against cache poisoning
Zone Signing
The zone administrator generates a key pair. Records are signed with the Zone Signing Key (ZSK), creating RRSIG records alongside each RRset.
Key Hierarchy
The Key Signing Key (KSK) signs the DNSKEY records. The KSK's hash (DS record) is published in the parent zone, creating a chain of trust.
Chain of Trust
From the root zone (trust anchor) down through TLD, domain, and subdomains — each level validates the one below via DS and DNSKEY records.
Validation
DNSSEC-validating resolvers verify signatures. If validation fails, the resolver returns SERVFAIL — preventing poisoned/tampered responses from being used.
DNSSEC Record Types
Encrypted DNS Protocols
Protecting DNS queries from interception and surveillance
DNS-over-HTTPS (DoH)
RFC 8484DNS queries are sent over HTTPS (port 443), indistinguishable from regular web traffic. Prevents ISP snooping and blocks DNS interception.
DNS-over-TLS (DoT)
RFC 7858DNS queries encrypted with TLS on a dedicated port (853). Easier to filter/monitor than DoH, but provides strong encryption and authentication.
DNS-over-QUIC (DoQ)
RFC 9250DNS over the QUIC transport protocol. Combines DoT-like security with faster connection establishment and better performance on lossy networks.
EDNS Client Subnet (ECS)
The DNS extension that trades user privacy for CDN performance — and what you can do about it
EDNS Client Subnet (RFC 7871) is an extension to the DNS protocol that allows recursive resolvers to forward a portion of the client's IP address to authoritative nameservers. It was designed to help CDNs and geo-DNS providers return the topographically closest server — but it comes with meaningful privacy trade-offs.
Without ECS, the authoritative server only sees the resolver's IP (e.g., 8.8.8.8) and geo-routes based on that. With ECS, it sees a truncated version of the client's IP — typically the first 24 bits for IPv4 (e.g., 203.0.113.0/24) — giving it enough to make a more accurate routing decision while theoretically limiting re-identification risk.
In practice, a /24 prefix is often enough to narrow a user's location to a city or ISP — and this information is passed to every authoritative nameserver queried, including those run by advertisers, CDNs, and third-party DNS providers. ECS data can persist in DNS logs well beyond the TTL of the record itself.
ECS at a Glance
What ECS Exposes
- Client IP prefix forwarded to every authoritative nameserver in the resolution chain
- Geolocation data derivable from the /24 prefix — city and ISP level accuracy
- Browsing patterns can be inferred from ECS-tagged DNS logs at authoritative servers
- Third-party CDN and analytics providers receive client location on every CDN-hosted domain lookup
- ECS data can be retained in authoritative server logs indefinitely
How to Limit ECS Exposure
- Use a privacy-respecting resolver: Cloudflare 1.1.1.1 and Quad9 disable ECS by default
- Configure your own Unbound or Knot Resolver with
send-client-subnet: 0.0.0.0/0to suppress ECS - Use DNS-over-HTTPS or DNS-over-TLS to prevent your ISP from seeing queries at all
- For authoritative servers: discard ECS data from logs if geo-routing accuracy is not needed
- Operators using PowerDNS or BIND can strip or ignore incoming ECS options
DNS Security Monitoring Tools
Essential tools for auditing and troubleshooting DNS configurations
dignslookupdnsvizzonemasterdnstracer