What Is a DDoS Attack? Types, Impact, and DNS Protection
Learn what DDoS attacks are, how volumetric, protocol, and application-layer attacks work, and how anycast DNS networks protect your infrastructure.
What Is a DDoS Attack? Types, Impact, and DNS Protection
What You Will Learn
- The three main categories of DDoS attacks and how each one disrupts services
- How DDoS attacks work at a technical level, from botnets to traffic floods
- Why DNS infrastructure is a high-value target and which DNS-specific attacks exist
- Practical protection strategies including anycast, rate limiting, caching, and filtering
What Is a DDoS Attack?
A Distributed Denial of Service (DDoS) attack uses thousands or millions of sources to flood a target with more traffic than it can handle. The goal is simple: make a service unavailable to legitimate users.
Unlike a single-source DoS attack, a DDoS attack is distributed across a botnet -- a network of compromised devices (servers, IoT cameras, routers, even smart appliances) controlled by an attacker. Because traffic comes from many different IPs simultaneously, it is far harder to filter than a single malicious source.
DDoS attacks target every layer of the network stack, but DNS infrastructure is one of the most common targets because taking down DNS takes down everything that depends on it: websites, APIs, email, VPNs, and any service that begins with a domain name lookup.
The Three Categories of DDoS Attacks
1. Volumetric Attacks
Volumetric attacks flood the target's network link with raw bandwidth. The attacker generates so much traffic that the pipe between the target and the internet becomes saturated.
Common techniques:
- UDP floods -- sending massive volumes of UDP packets to random ports
- DNS amplification -- abusing open resolvers to generate large DNS responses aimed at the victim (covered in detail in the DNS Amplification Attacks guide)
- NTP amplification -- similar to DNS amplification but using NTP monlist commands
- ICMP floods -- overwhelming the target with ping packets
Volumetric attacks are measured in bits per second (bps). Modern attacks regularly exceed 100 Gbps, with the largest recorded attacks surpassing 1 Tbps.
You can observe the size of DNS responses that could be used in amplification by querying a domain with dig:
# Check the response size for a typical A record query
dig example.com A
# Look at the ";; MSG SIZE rcvd:" line in the output
# A simple A record response is usually 50-80 bytes
;; MSG SIZE rcvd: 56
# Compare with a query that returns many records
dig example.com ANY
# Responses with many record types can be 2000+ bytes
# This amplification ratio is what attackers exploit
;; MSG SIZE rcvd: 28472. Protocol Attacks
Protocol attacks exploit weaknesses in network protocols (layers 3 and 4) to exhaust server resources or intermediate infrastructure like firewalls and load balancers.
Common techniques:
- SYN floods -- sending a barrage of TCP SYN packets without completing the handshake, filling the server's connection table
- Fragmented packet attacks -- sending malformed or fragmented IP packets that consume processing power during reassembly
- Ping of Death -- sending oversized ICMP packets that crash the target
Protocol attacks are measured in packets per second (pps). They do not need to saturate bandwidth; instead, they exhaust compute resources on the target or on inline devices.
3. Application-Layer Attacks
Application-layer attacks target specific services (layer 7) with requests that look legitimate but are designed to consume server resources.
Common techniques:
- HTTP floods -- sending large volumes of GET or POST requests to resource-intensive endpoints
- Slowloris -- opening many connections and sending partial HTTP headers, keeping connections open indefinitely
- DNS query floods -- sending valid-looking DNS queries at high volume to overwhelm authoritative nameservers
Application-layer attacks are measured in requests per second (rps). They are the hardest to mitigate because each individual request looks like normal traffic.
| Category | Target Layer | Measured In | Example |
|---|---|---|---|
| Volumetric | Network (L3) | Gbps | UDP flood, DNS amplification |
| Protocol | Transport (L3/L4) | Packets/sec | SYN flood, fragmentation |
| Application | Application (L7) | Requests/sec | HTTP flood, DNS query flood |
DNS-Specific DDoS Attacks
DNS is a particularly attractive DDoS target for two reasons: it is critical infrastructure (no DNS means no access to anything), and the DNS protocol has properties that attackers exploit. Here are the most common DNS-specific attacks.
DNS Amplification and Reflection
An attacker sends DNS queries with a spoofed source IP (the victim's IP) to open recursive resolvers. The resolvers send their responses -- which are much larger than the queries -- to the victim. A 60-byte query can generate a 3,000-byte response, amplifying the attack by 50x.
This attack exploits two properties: the amplification factor of DNS responses and the ability to spoof UDP source addresses. For a deep dive into how amplification works and how to prevent it, see DNS Amplification Attacks Explained.
NXDOMAIN Floods
The attacker sends a flood of queries for random non-existent subdomains under a target zone:
asd8f7a.example.com
k3jh5g2.example.com
p9x2m4n.example.comEach query generates a unique cache miss, forcing the authoritative server to process every single request. Unlike queries for real records, NXDOMAIN queries cannot be served from cache, which makes them especially effective at exhausting server resources.
You can see the difference between a cached and uncached query using dig:
# First query - must reach the authoritative server
dig @8.8.8.8 example.com A
;; Query time: 23 msec
# Second query - served from cache
dig @8.8.8.8 example.com A
;; Query time: 1 msec
# Random subdomain - always a cache miss
dig @8.8.8.8 r4nd0m7x9.example.com A
;; Query time: 45 msec
# Every random subdomain forces a fresh lookupWater Torture (Random Subdomain Attack)
A refinement of the NXDOMAIN flood, the water torture attack spreads queries across many recursive resolvers. Instead of hitting the authoritative server directly, the attacker sends random subdomain queries through thousands of different resolvers. Each resolver forwards its unique query upstream to the authoritative server.
This is harder to block because:
- The queries come from legitimate recursive resolvers, not from botnet IPs
- Each resolver sends only a few queries, appearing normal
- The authoritative server sees a flood from many different sources
- Rate limiting per source IP is ineffective because each resolver sends minimal traffic
DNS Query Floods
A straightforward approach: the attacker sends a massive volume of legitimate-looking queries directly to the authoritative nameservers. Unlike amplification attacks, the goal is not to redirect traffic but to overwhelm the nameserver itself.
Query floods target the processing capacity of the DNS server. Even though each response is small, generating millions of responses per second consumes CPU, memory, and network resources.
Real-World Impact of DDoS Attacks
Downtime and Revenue Loss
When DNS goes down, every service that relies on domain resolution fails simultaneously. For an e-commerce site, every minute of DNS downtime translates directly to lost sales. For a SaaS platform, it means customers cannot reach the application, API integrations break, and support tickets spike.
Industry estimates put the cost of downtime for mid-size companies at $5,600 per minute. For DNS specifically, the blast radius is larger than a web server outage because DNS affects every service on the domain -- not just the website.
Reputational Damage
Repeated outages erode customer trust. If your domain fails to resolve intermittently, users switch to competitors. Search engines may also deprioritize domains with reliability issues, compounding the damage over time.
Collateral Damage
DNS DDoS attacks often affect more than the intended target. Shared DNS infrastructure means an attack on one customer can degrade service for others on the same platform. This is one reason why DNS architecture matters -- providers that use anycast networks can isolate attack traffic better than single-location deployments.
Protection Layers Against DDoS
Effective DDoS protection is not a single tool but a layered defense. Each layer handles a different aspect of the problem.
Layer 1: Anycast Network Distribution
Anycast DNS is the single most important architectural defense against DDoS. When your nameservers use anycast, the same IP address is announced from multiple points of presence (POPs) worldwide. An attack targeting that IP is automatically split across every POP.
If an attacker generates 100 Gbps of traffic against an anycast IP served by 10 POPs, each POP absorbs roughly 10 Gbps -- a fraction of the total. No single location takes the full force.
# You can verify anycast distribution by querying from different locations
# and observing different response sources
dig @ns1.dnscale.com example.com A +nsid
# The NSID (Name Server Identifier) option shows which POP answered
# Different geographic locations will see different POP identifiersAnycast transforms a DDoS problem from "absorb all traffic at one point" into "distribute it globally." This is why every major DNS provider uses anycast. Learn more about how Global DNS Resolution Balancing works in practice.
Layer 2: Rate Limiting at the Edge
Rate limiting caps the number of queries a single source IP can send within a time window. This is applied at each POP independently, so legitimate traffic from around the world flows normally while abusive sources are throttled.
Effective rate limiting for DNS considers:
- Per-IP query rate -- dropping queries from IPs that exceed a threshold
- Per-subnet rate -- catching distributed attacks from within the same network
- Response Rate Limiting (RRL) -- limiting identical responses to the same destination, which specifically counters amplification attacks
Layer 3: Caching and Packet Cache
DNS responses are cacheable by design. A well-configured authoritative server with an aggressive packet cache can serve repeated queries for the same record types from memory without touching the backend database or zone file.
During a DDoS attack, the packet cache absorbs the majority of query volume. If attackers query example.com A millions of times, the server generates the answer once and serves it from cache for the duration of the TTL.
This is why NXDOMAIN and random subdomain attacks are more dangerous -- they bypass the cache by making every query unique.
Layer 4: Filtering and Blocking
The final layer applies intelligent filtering rules:
- Dynamic NXDOMAIN blocking -- detecting and blocking sources that generate abnormally high rates of NXDOMAIN queries
- GeoIP filtering -- temporarily blocking traffic from regions where you have no legitimate users during an attack
- DNS firewall rules -- dropping queries for specific patterns (e.g., random subdomain patterns) or query types that are not needed
How DNScale Protects Against DDoS
DNScale applies all four protection layers through its anycast infrastructure and edge processing pipeline.
Anycast Across Two Networks
DNScale operates two independent anycast networks -- AS44794 for the EU footprint and AS62406 for global coverage. Attack traffic is absorbed across every POP in the network. Even if one POP experiences heavier load due to routing proximity to the attacker, the remaining POPs continue serving clean traffic normally.
Per-IP Rate Limiting
Every edge POP applies per-IP and per-subnet rate limiting independently. Queries from a single source exceeding the threshold are dropped before they reach the authoritative backend. This stops simple query floods while allowing legitimate resolver traffic through.
Dynamic NXDOMAIN Blocking
DNScale monitors NXDOMAIN rates in real time. When a source generates an abnormally high rate of queries for non-existent domains -- a hallmark of NXDOMAIN floods and water torture attacks -- the source is temporarily blocked at the edge. Legitimate resolvers rarely generate sustained NXDOMAIN traffic, so false positives are minimal.
Packet Cache
Every POP runs a high-performance packet cache that serves repeated queries from memory. During a volumetric query flood, the cache absorbs the bulk of the traffic. The authoritative backend only processes genuinely unique queries, keeping CPU and memory usage stable.
DNScale's multi-layered approach means that even during an active DDoS attack, legitimate queries continue to resolve normally from healthy POPs. The combination of anycast distribution and edge-level filtering ensures that attack traffic never reaches the authoritative backend in volume.
What to Do During a DDoS Attack
If your DNS infrastructure is under attack, follow these steps:
1. Confirm the Attack
Check whether you are experiencing a genuine DDoS or simply a traffic spike. Look for:
- Sudden increase in query volume with no corresponding business event
- High ratio of NXDOMAIN responses
- Queries for random or nonsensical subdomains
- Traffic concentrated from specific subnets or regions
# Check if your domain is resolving normally
dig example.com A +short
# If you get a timeout or SERVFAIL, your DNS may be under attack
# Test from a different resolver to rule out local issues
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
# Check response times -- elevated times suggest load
dig example.com A | grep "Query time"
;; Query time: 450 msec # Normal is under 50ms2. Engage Your DNS Provider
If you are on managed DNS, contact your provider immediately. Providers with anycast infrastructure can apply filtering rules across all POPs within minutes.
3. Lower Your TTLs Before an Attack
If you anticipate risk, proactively lower your TTLs on critical records. This gives you faster recovery options -- if you need to migrate to a backup provider, shorter TTLs mean resolvers pick up changes faster.
# Check your current TTL
dig example.com A
;; example.com. 3600 IN A 198.51.100.1
# A TTL of 3600 (1 hour) means resolvers cache for up to an hour
# Consider lowering to 300 (5 minutes) before expected high-risk periods4. Consider Multi-Provider DNS
For critical domains, running DNS with two independent providers eliminates the single point of failure. If one provider is overwhelmed, the other continues answering queries. NS records from both providers are published at the registrar, and resolvers automatically fail over.
5. Enable DNSSEC
While DNSSEC does not prevent DDoS directly, it prevents attackers from spoofing DNS responses during an attack. Without DNSSEC, an attacker could poison resolver caches while the authoritative server is under load and responding slowly.
DDoS Attack Trends
DDoS attacks continue to grow in size and sophistication:
- Attack volumes are increasing -- multi-terabit attacks are now documented
- IoT botnets have expanded the pool of available attack sources
- Application-layer attacks are growing because they bypass traditional volumetric defenses
- DNS-specific attacks remain popular because DNS is a single point of failure for entire organizations
- Multi-vector attacks combine volumetric, protocol, and application-layer techniques simultaneously
The trend reinforces the importance of architectural defenses like anycast rather than relying solely on traffic scrubbing.
Key Takeaways
- DDoS attacks overwhelm targets with distributed traffic across three categories: volumetric, protocol, and application-layer
- DNS infrastructure is a primary DDoS target because DNS downtime affects every service on a domain
- DNS-specific attacks include amplification, NXDOMAIN floods, water torture, and query floods
- Effective defense is layered: anycast distribution, rate limiting, caching, and intelligent filtering
- Anycast DNS is the foundational defense -- it distributes attack traffic across multiple POPs so no single location is overwhelmed
- DNScale protects against DDoS through dual anycast networks, per-IP rate limiting, dynamic NXDOMAIN blocking, and high-performance packet caching
Further Reading
- DNS Amplification Attacks Explained -- how amplification works and how to prevent it
- What Is DNS? -- fundamentals of the Domain Name System
- Anycast DNS vs Unicast DNS -- why anycast matters for resilience
- Global DNS Resolution Balancing -- how DNScale distributes queries globally
- DNS Record Types -- understanding the records attackers target
- DNS Attacks and Threats -- broader overview of DNS security threats
- What Is a TXT Record? -- TXT records and their role in DNS security
- Managed DNS vs Self-Hosted DNS -- why managed DNS provides better DDoS protection
Ready to manage your DNS with confidence?
DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.
Start free