What Is a DDoS Attack? Types, Impact, and DNS Protection

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: 2847

2. 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.

For web and API endpoints, a CAPTCHA challenge-response can be one layer against suspicious browser-like traffic. It does not help with volumetric floods, protocol attacks, or authoritative DNS query floods because those attacks are handled before a web application can present a challenge.

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.com

Each 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 lookup

Water 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 one of the most important architectural defenses against DNS DDoS. When your nameservers use anycast, the same IP address is announced from multiple points of presence (POPs) worldwide. An attack targeting that IP can be distributed across multiple POPs instead of forced through one location.

The distribution is route-dependent rather than equal-split math. A well-peered anycast network gives the provider more places to absorb, filter, or shed traffic so no single location has to take the full force by design.

# 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 identifiers

Anycast can transform a DDoS problem from "absorb all traffic at one point" into "absorb and filter traffic at multiple ingress points." 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 multiple anycast networks spanning Europe, North America, and Asia. Attack traffic can land across multiple POPs in the network. If one POP experiences heavier load due to routing proximity to the attacker, other POPs can continue serving traffic that routes to them while filtering and mitigation take effect.

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 is designed so that during an active DDoS attack, legitimate queries continue to resolve from healthy POPs where capacity and routing remain available. The combination of anycast distribution and edge-level filtering reduces the volume that reaches the authoritative backend.

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 50ms

2. Engage Your DNS Provider

If you are on managed DNS, contact your provider immediately. Providers with anycast infrastructure can apply filtering rules across affected POPs and upstream mitigation layers.

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 periods

4. Consider Multi-Provider DNS

For critical domains, running DNS with two independent providers reduces provider-level single points of failure. If one provider is overwhelmed, the other can continue answering queries as resolvers retry other delegated NS records. Keep record data and DNSSEC state consistent across both providers.

5. Enable DNSSEC

While DNSSEC does not prevent DDoS directly, it helps validating resolvers reject forged DNS answers. Without DNSSEC, an attacker who can win a response race against a vulnerable resolver may be able to poison caches while authoritative service is degraded.

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 CAPTCHA Challenge Response? -- where CAPTCHA fits for application-layer bot traffic
• 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