A DNS attack is a class of attacks targeting the domain name system with the goal of redirecting traffic, taking a resource offline, or disrupting DNS infrastructure. Depending on the method used, an attacker can spoof a DNS response, flood a server with requests, gain control over a domain's DNS settings, or use DNS as a covert data transmission channel.
It's important to understand that DNS is a critical part of how a website operates: if a domain name stops resolving correctly to an IP address, users won't be able to reach the site even if the web server itself is running perfectly. Below we'll break down the main types of DNS attacks, signs of compromise, and practical defense methods.
Why attackers target DNS
DNS is often called the "phone book of the internet": it maps a human-readable domain name to a server address. If an attacker manages to influence this mechanism, they don't necessarily need to breach the website itself. DNS attacks are attractive to attackers for several reasons. Classic DNS originally had no cryptographic verification of response authenticity, and recursive DNS servers actively cache the data they receive.
DNS can become a single point of failure: issues with domain resolution make a site unreachable for users even if the web server process and the VPS itself keep running fine. Finally, users generally trust the result of DNS resolution. If a domain unexpectedly starts pointing to a different IP address, a visitor may not even notice the switch and end up on a phishing site.
Main types of DNS attacks
DNS attacks differ not only in technique but also in impact. Some aim to spoof DNS responses, others cause denial of service, and others let an attacker gain control over a domain's settings.
DNS spoofing and cache poisoning
DNS spoofing is the act of forging a DNS response so that a client or DNS resolver receives incorrect data. Instead of the site's real IP address, the resolver receives the attacker's server address. One particularly dangerous variant of this attack is DNS cache poisoning. If a forged response is accepted by a recursive resolver, the incorrect record gets stored in its cache. After that, other users querying that same resolver may receive the already-spoofed IP address.
The practical consequence is redirecting users to a phishing site. Visually, it looks identical to the original, making it hard to tell apart. As a result, the visitor trusts the site and enters their credentials — login and password — without suspecting anything is wrong.
DNSSEC is the defense against this scenario. The technology adds digital signatures to DNS data, allowing a validating resolver to verify the origin and integrity of the information received. If the signature fails validation, the data is considered untrustworthy.
DNSSEC doesn't mean DNS becomes completely immune to every attack. DNSSEC isn't designed to protect against DDoS and doesn't encrypt the DNS queries themselves. DNS cache poisoning shouldn't be confused with the ordinary issue of a stale record on a user's device. For more on how client-side DNS caching works and why DNS changes may not take effect immediately, see our separate article.
DDoS attacks on DNS and DNS amplification
A DDoS attack on DNS targets the DNS server or infrastructure handling requests for a domain directly. The attacker generates a huge flood of requests, making it harder for the server to process legitimate queries. The result can be increased DNS response times, domain resolution errors, or complete unavailability of the resource for some users — even while the web server itself keeps working normally.
DNS amplification works differently. In this case, the attacker leverages third-party DNS servers, typically misconfigured open recursive resolvers. They send these resolvers small queries with a spoofed source address pointing to the victim's IP. The resolvers then send their responses to the victim, with the response size being many times larger than the original request.
This mechanism lets an attacker amplify traffic volume by abusing someone else's DNS infrastructure. DNS amplification relies on UDP, which doesn't establish a connection before exchanging data, making this kind of source-address spoofing easier to pull off. The key difference: in a regular DDoS attack, the attacker overloads DNS infrastructure directly, while in an amplification attack they use third-party open resolvers as amplifiers. This means the victim can be a site or server whose owner has nothing to do with the vulnerable DNS resolver at all.
Defense here relies on restricting recursion, filtering unwanted traffic, monitoring DNS activity, and using infrastructure capable of withstanding network-level attacks. If a site is hosted on a VPS, the resilience of the data center's network infrastructure and the availability of DDoS protection from the provider can significantly reduce the chance of downtime during an attack.
The specific parameters of such protection depend on the provider and the chosen location, so they should be checked in the documentation before deploying a mission-critical service.
DNS hijacking
DNS hijacking involves gaining control over where DNS queries are directed or which DNS records are used for a domain. An attacker gains access to the domain owner's account at the registrar and changes the NS records. After that, control over DNS effectively belongs to the attacker: they can point to their own DNS servers and redirect the domain to infrastructure of their choosing.
Another variant is compromising a router or a local DNS server. In this scenario, DNS settings can be altered so that users' devices receive responses from a server controlled by the attacker. This is an important distinction from spoofing: with spoofing, the attacker tries to forge a specific DNS response, while with hijacking they aim to change the resolution mechanism itself or seize control of the DNS settings.
You need to secure the registrar account and any accounts with permission to modify DNS. Use a unique, strong password, two-factor authentication, and, if the registrar offers it, a lock on critical domain operations — for example, a registrar lock. It's also useful to enable notifications for changes to DNS records and domain data.
DNS tunneling
DNS tunneling repurposes DNS for something other than its intended function. Instead of ordinary domain name resolution, DNS queries become a channel for transmitting information. Malware inside a network encodes small chunks of data into subdomains and sends them through a DNS server. In the opposite direction, this same channel carries command-and-control instructions.
This method can be used for data exfiltration and for setting up covert C2 channels. DNS tunneling is especially attractive to attackers on networks where other outbound connection methods are restricted. Defenses include monitoring DNS queries, analyzing unusually long domain names, large numbers of random subdomains, and abnormal query frequency to the same domains.
How to recognize a DNS attack
A DNS attack isn't always easy to distinguish from an ordinary site outage right away. During a DDoS attack, the server itself may be completely healthy, yet users still can't resolve its IP address.
Watch out for the following signs:
The site stops loading even though the web server, application, and network services on the VPS are all running fine.
Users get different IP addresses for the same domain across different networks or regions with no obvious reason.
Redirects to unfamiliar sites start appearing. It's especially suspicious if the domain's DNS record unexpectedly points to an unknown IP.
The number of DNS queries spikes sharply. This can indicate DDoS, an attack on the resolver, or a misconfiguration.
Anomalies show up in DNS logs: unusual query sources, a large number of random subdomains, or atypical query frequency.
DNS records have changed without the administrator's knowledge. This is one of the most serious signs of a possible registrar account takeover.
The site is reachable directly by IP but doesn't load via the domain. The problem is usually at the DNS level rather than the web server.
If you suspect an attack, it helps to compare DNS responses from several independent networks and check the domain's current NS, A, and AAAA records. At the same time, review the change log in the registrar account.
How to protect against DNS attacks
It's impossible to eliminate every threat completely, but proper DNS configuration reduces the likelihood of a successful attack.
Enable DNSSEC for the domain. DNSSEC lets validating resolvers verify the authenticity of DNS data and protects against a number of spoofing and cache-poisoning attacks. For it to work properly, you need not only to sign the DNS zone but also to correctly set up the chain of trust via a DS record at the registrar.
Restrict recursion on the DNS resolver. There's no need to turn your server into an open recursive DNS resolver for the entire internet. Limiting the set of clients allowed to use recursion reduces the risk of your server being abused for DNS amplification.
Use a reliable DNS provider. For a public-facing site, it's important that the DNS infrastructure has redundancy and can handle increased load. Ideally, you should have several authoritative DNS servers located on different networks.
Secure the registrar account. Use a unique password and 2FA. Limit the number of users allowed to change DNS records, and enable notifications for critical changes. If domain lock against unauthorized operations is available, use it.
Monitor changes to DNS records. Periodically check NS, A, AAAA, MX, and other critical records. If the site's IP address changes unexpectedly, find out why before users start reaching the new address.
Monitor DNS traffic. Keep an eye on the number of queries, traffic sources, and the nature of the DNS names involved. A sudden spike in load can be an early sign of an attack or a misconfiguration.
Protect your infrastructure against network-level DDoS. DNS and the web server can sit at different layers of infrastructure, so DNS configuration alone isn't enough.
Don't leave DNS services exposed unnecessarily. Recursive DNS servers, control panels, and administrative interfaces should only be accessible to the clients and administrators who genuinely need them. The specific settings depend on the software you're using — BIND, PowerDNS, Unbound, and others — so there's no one-size-fits-all set of commands to configure them.
Which defense protects against what
It's important to understand that DNSSEC isn't a universal shield against DNS attacks. It solves one specific problem — cryptographically verifying the authenticity of DNS data. Protecting against DDoS, registrar account compromise, or DNS tunneling requires other defense mechanisms.
Conclusion
DNS is an infrastructure layer that often gets less attention than the web application, operating system, or the server itself. A DNS problem can make a site unreachable even with a perfectly healthy VPS, and spoofed DNS data can redirect users to someone else's resource.
That's why defenses should be built across several layers at once: enable DNSSEC to protect against DNS data spoofing, close off unnecessary recursion, secure the registrar account with 2FA and lock features, monitor record changes, and track DNS traffic. For projects where downtime is especially costly, it's also important to choose infrastructure with DNS redundancy and protection mechanisms against network-level DDoS attacks.
This approach doesn't guarantee absolute protection, but it significantly reduces the chance that a DNS attack will result in site downtime or user compromise.
