A DNS vulnerability is any weakness in the Domain Name System, the service that translates names like example.com into IP addresses, that lets an attacker forge, intercept, or redirect those lookups. Because nearly every network action starts with a DNS query, a successful attack on DNS can quietly reroute traffic, steal credentials, or exfiltrate data without ever touching the application it targets. That is what makes this class of problem worth understanding in depth.
DNS was designed in the early 1980s for a smaller, more trusting internet, and much of its security has been bolted on since. The result is a protocol that works beautifully and fails dangerously. Here are the vulnerability classes that matter and how you actually defend against them.
Cache Poisoning
DNS resolvers cache answers to avoid asking authoritative servers for every lookup. Cache poisoning is the attack that injects a forged answer into that cache, so the resolver hands out a malicious IP address to every client that asks, until the entry expires.
The classic version exploited the fact that DNS traditionally ran over UDP with a 16-bit transaction ID and a predictable source port. An attacker who could guess the transaction ID and race the legitimate response could get a forgery accepted. Dan Kaminsky's 2008 research showed this was far more practical than assumed, and it drove the widespread adoption of source-port randomization, which turned a 16-bit guessing game into a roughly 32-bit one. That mitigation helped, but it did not close the door, which is part of why DNSSEC exists.
The durable defense is DNSSEC. It adds cryptographic signatures to DNS records so a resolver can verify that an answer genuinely came from the zone's owner and was not tampered with in transit. If you run authoritative zones, signing them is the single highest-value step you can take against forgery.
DNS Hijacking
Hijacking is the broader category of redirecting DNS resolution to a server the attacker controls. It happens at several layers. At the registrar level, an attacker who compromises your domain-registrar account can change your authoritative name servers and take over resolution for the entire domain. At the resolver level, malware can quietly change a device's configured DNS server to a malicious one, so every lookup that device makes is answered by the attacker.
The defenses are mostly operational. Lock your registrar account with strong multi-factor authentication and enable a registry lock if your registrar offers one, which requires an out-of-band confirmation before name-server changes take effect. Monitor your own zones from the outside so you notice if your name-server records or critical A records change unexpectedly.
DNS Tunneling and Data Exfiltration
Because DNS is almost never blocked at the firewall, attackers use it as a covert channel. DNS tunneling encodes data into the subdomain portion of queries to a domain the attacker controls. Each lookup smuggles a chunk of stolen data out, and the authoritative server for that domain decodes it. Malware also uses this pattern for command and control, receiving instructions encoded in DNS responses.
You detect tunneling by watching for the statistical fingerprints it leaves: an unusually high volume of queries to a single domain, abnormally long or high-entropy subdomain labels, and a high ratio of unique queries to a domain that a human would never generate. Logging resolver queries and alerting on those patterns is the practical control, because signature-based blocking alone will not catch a novel tunneling domain.
DNS Amplification
This is a denial-of-service technique rather than a redirection attack. An attacker sends small DNS queries with a spoofed source address, the victim's, to open resolvers, and each resolver replies with a much larger response aimed at the victim. The size difference amplifies the attacker's bandwidth many times over, and thousands of resolvers pointed at one target can saturate its connection.
If you run a resolver, the fix is to not be an open resolver: restrict recursion to your own clients so your infrastructure cannot be conscripted into someone else's attack. At the network edge, source-address validation (the practice described in BCP 38) prevents the spoofed packets that make amplification possible from leaving your network in the first place.
Where DNS Meets the Software Supply Chain
There is a subtler DNS risk that touches software delivery directly: dangling DNS records and the subdomain takeovers they enable. When a team decommissions a cloud service but leaves a CNAME pointing at the now-unclaimed hostname, an attacker can register that hostname on the same cloud provider and serve content from your subdomain. If that subdomain was trusted, for cookies, for content, for a build artifact endpoint, the takeover becomes a supply chain problem.
The same discipline applies to the dependencies your build pulls over DNS. A poisoned resolver during a build could redirect a package fetch to a malicious mirror. Pinning artifacts by hash and verifying signatures means a DNS-level redirect cannot silently swap what you install, which is a good reason to combine network hygiene with artifact-integrity checks in your pipeline. Cataloging your external hostnames and their live status, the way an inventory of your third-party surface does for dependencies, is how dangling records get caught before an attacker finds them.
A Defense Checklist
The controls that matter most, roughly in order: sign your authoritative zones with DNSSEC; lock your registrar account with MFA and, ideally, registry lock; restrict recursion so you never run an open resolver; log and monitor resolver queries for tunneling fingerprints and unexpected record changes; and audit for dangling CNAME records that enable subdomain takeover. Encrypting client resolution with DNS over HTTPS or DNS over TLS additionally protects lookups from on-path eavesdropping and tampering, which is worth enabling for endpoints on untrusted networks.
FAQ
What is the most common DNS vulnerability?
Cache poisoning and DNS hijacking are the two most consequential in practice. Poisoning forges answers in a resolver's cache; hijacking redirects resolution at the registrar or device level. Both send users to attacker-controlled addresses, and both are defended primarily through DNSSEC and strong registrar-account security.
Does DNSSEC fix everything?
No. DNSSEC provides integrity and authenticity, proving an answer came from the real zone owner and was not altered, but it does not provide confidentiality, so it does not hide your lookups. It also does nothing against denial-of-service, tunneling, or a compromised registrar account. It is essential but partial.
How do I know if my DNS is being tunneled through?
Watch resolver logs for the fingerprints of tunneling: a large volume of queries to one domain, unusually long or high-entropy subdomain labels, and many unique queries no human would generate. These statistical patterns are more reliable than trying to blocklist specific domains, since tunneling domains are cheap to rotate.
Is DNS over HTTPS a security improvement?
For client privacy and on-path tampering, yes. DoH encrypts lookups so a network observer cannot see or modify them. It does not replace DNSSEC, which authenticates the answer itself, and it can complicate enterprise monitoring, so many organizations route DoH through a controlled resolver rather than allowing arbitrary public ones.