The Protocol Everyone Depends On and Nobody Secures

DNS resolves nearly every connection on the internet, which makes it both an attractive attack target and a valuable security control. It was designed in an era of trust, and its security has been bolted on in layers ever since. Understanding DNS security means understanding both how it can be attacked and how it can be used to defend.

DNS Cache Poisoning

A resolver caches answers to speed up lookups. In a cache poisoning attack, an attacker injects a forged answer, so the resolver serves a malicious IP to all its users until the record's TTL expires. The classic technique involved racing legitimate responses with spoofed UDP packets. Defenses include randomizing query IDs and source ports, and—critically—DNSSEC.

DNSSEC

DNSSEC adds cryptographic signatures to DNS records. Each zone signs its records, and parent zones sign the public keys of their children, forming a chain of trust from the DNS root down to the target domain. A validating resolver checks the signature before accepting an answer, so a poisoned or forged record is rejected.

DNSSEC's limitations are practical, not conceptual: only a minority of domains deploy it, misconfigured signing causes outages, and it does not encrypt queries—it only authenticates them. Still, it is the only defense against a compromised authoritative server providing false data.

Encrypted DNS: DoH and DoT

Traditional DNS queries travel in plaintext over UDP port 53, visible to ISPs and on-path observers. Two transports encrypt them:

  • DNS over TLS (DoT): DNS over a dedicated TLS connection on port 853. Easy to identify and block by port.
  • DNS over HTTPS (DoH): DNS wrapped in HTTPS on port 443. Indistinguishable from normal web traffic, so it is hard to block and increasingly built into browsers and operating systems.

Encrypted DNS protects query privacy and blocks on-path tampering, but it also moves trust: your queries are now visible to the DoH provider. Choose a provider you trust, and be aware that DoH can bypass local DNS-based controls unless those controls are client-side.

DNS Tunneling and Exfiltration

Because DNS is almost always allowed through firewalls, attackers abuse it for tunneling—encoding arbitrary data in DNS queries and responses to exfiltrate information or maintain command-and-control. Signs include unusually long or high-entropy subdomains, high query volumes to a single domain, and TXT records used as data carriers. Detection relies on monitoring DNS patterns, not just destinations.

DNS as a Security Control

Conversely, DNS is a powerful defense layer:

  • DNS filtering / RPZ: block known-malicious domains before a connection is made.
  • Sinkholing: redirect malicious domains to a controlled server to monitor infected hosts.
  • Analytics: DNS logs reveal which internal hosts contact suspicious infrastructure, often the earliest breach indicator.
  • Client-side protections: browsers and public resolvers increasingly filter malicious domains automatically.

Operational Hardening

  • Deploy DNSSEC validation at your resolvers.
  • Use encrypted DNS (DoH/DoT) to protect query privacy and integrity in transit.
  • Monitor DNS logs for tunneling and anomalous patterns.
  • Diversify resolvers so a single provider outage or compromise does not break or poison your resolution.
  • Keep authoritative servers patched and correctly signed to avoid outages.
  • Beware of using a single third-party resolver for all traffic—concentration creates both privacy and availability risk.

DNS is both a target and a tool. Securing it requires authenticating answers, encrypting queries, and treating DNS logs as the valuable security telemetry they are.