DDoS Protection DNS: A Practical Engineer’s Playbook

A web server can be healthy while customers see SERVFAIL, resolver timeouts, or a site that appears completely offline. During a DNS-layer attack, start by separating the authoritative service from the recursive path, then protect the authoritative servers with upstream filtering, restricted recursion, distribution across independent networks, and tuned BIND 9 Response Rate Limiting.

For BIND 9.18, validate the configuration before reloading it:

named-checkconf -z /etc/bind/named.conf
rndc reconfig

The rest of the investigation depends on identifying whether port 53 is being flooded, recursive lookups are being abused, delegation has failed, or the access link is already saturated. DNS protection works when each failure domain gets the right control. A server firewall alone won't solve a congested transit link.

Table of Contents

• When Your DNS Quietly Fails Under Attack
  • The first response
• How DNS Amplification and Reflection Actually Work
  • The traffic economics
  • What each control protects
• Authoritative vs Recursive DNS Protection
  • Authoritative controls
  • Recursive controls
• Configuring Rate Limiting on BIND 9
  • Tune the slip behavior
  • Validate without restarting
• Why Anycast Is Not a Complete DNS Strategy
  • A smaller organization's redundancy model
• DNSSEC, Water Torture, and the Limits of Network Mitigation
  • Water-torture traffic needs a different response
• Recommended Configuration for Hosted Services
• What Operators Ask After the First Wave

When Your DNS Quietly Fails Under Attack

The symptom usually arrives as a support ticket before it appears in your web-server graphs: "The website is down, but the application server is green." On the monitoring side, you may see resolver timeouts, a rise in NXDOMAIN, UDP packets accumulating on port 53, or customers in one region reporting failures while others still resolve the domain.

That pattern points to a DNS availability problem, not necessarily an origin outage. DNS translates names into IP addresses, so an attacker who disrupts authoritative servers, recursive resolvers, or the network paths between them can make a healthy application unreachable.

The first response

Check resolution from more than one recursive resolver and compare the result with direct queries to each authoritative service. Look for latency, packet loss, inconsistent answers, and whether failures affect all zones or only tenants sharing one nameserver.

Akamai reported that nearly 60% of the DDoS attacks it mitigated in 2023 included a DNS component, an almost 200% increase from the first quarter of 2022. Its global visibility covered more than 11 trillion DNS requests per day, giving the finding a broad measurement base. The same report recorded a nearly 50% increase in high-packets-per-second Layer 3 and Layer 4 attacks between 2021 and 2023. Akamai's 2023 DDoS retrospective explains why DNS belongs in the availability design, not only in the security checklist.

In production, the working fix is layered: move abusive volume upstream, keep authoritative DNS distributed, disable open recursion, apply RRL, and monitor user-facing resolution latency. If you need to identify the attack class before changing controls, use the procedures in ARPHost's DDoS attack detection guide.

How DNS Amplification and Reflection Actually Work

A DNS reflection attack has three participants: the attacker, the reflector, and the victim. The attacker sends a UDP query with the victim's forged source address. The DNS server receives the request and sends its response to the victim, who never asked for it.

Amplification occurs when the response is larger than the request. The reflector doesn't need to compromise the victim, and the attacker doesn't need to send the full response volume directly. The DNS service supplies the outbound traffic, while the victim absorbs it.

The traffic economics

A measurement study covering 129 million domains across nine top-level domains found that attackers could generate roughly 1,799 MB of response traffic while sending 44 MB of queries, an approximate 41:1 ratio. The academic study on DNS amplification also found that DNSSEC can increase response size, so DNSSEC improves authenticity but doesn't automatically reduce DDoS exposure.

For a hosting provider, the risk runs in both directions. Your authoritative servers may be used to reflect traffic toward another network, or your own nameservers may be the target. A firewall on the DNS host can reject some packets, but it can't undo traffic that already consumed an upstream circuit.

What each control protects

Anti-spoofing enforcement makes forged-source reflection harder to launch. Restricted recursion prevents authoritative infrastructure from answering arbitrary recursive requests. Response filtering and RRL reduce what an authoritative server sends, while upstream scrubbing protects the access link and the network around the host.

Practical rule: RRL reduces reflector capacity. It doesn't replace transit-level mitigation.

The distinction matters during an incident. If the victim is a third party, RRL and egress controls limit your participation. If your authoritative service is under attack, distributed capacity and upstream filtering preserve reachability. If a recursive resolver is processing random uncached names, cache and query controls address a different workload entirely.

Authoritative vs Recursive DNS Protection

DNS protection becomes easier to operate after the two roles are separated. An authoritative server answers from zones it publishes. A recursive resolver follows delegations and returns answers for clients. Combining both roles on one exposed host expands the consequences of a mistake, especially when recursion is available to the public internet.

Authoritative controls

Authoritative infrastructure should serve only the zones it is responsible for. Recursion must be disabled or tightly restricted, and response types that create large replies need careful handling. Anycast can distribute queries, but each site still needs capacity, health checks, and an operational path for withdrawal or recovery.

Authoritative protection also needs to preserve legitimate TCP retries. A DNS server that drops every response under pressure may suppress reflection effectively while causing resolvers to wait for timeouts.

Recursive controls

Recursive resolvers need a different policy. Permit queries only from known client networks, apply client and query-rate limits, and watch for random names that bypass the cache. DNS-water-torture traffic generates large numbers of uncached lookups, so a resolver may remain technically responsive while CPU, upstream queries, and logging grow rapidly.

An open recursive resolver on the same host as authoritative DNS is a liability because an attacker can consume the resolver's resources, use it for reflection, or force the host to prioritize abusive recursive work over authoritative answers. Keep the roles separate when the service matters.

Configuring Rate Limiting on BIND 9

BIND 9.18 provides authoritative response-rate limiting through a rate-limit clause in the global options statement or a specific view. The control is designed for excessive, nearly identical UDP responses. It doesn't protect a saturated access circuit, so put upstream filtering ahead of the server when volumetric traffic exceeds interface capacity.

Back up the configuration first, then add a deliberately conservative starting policy to the authoritative view:

options {
    directory "/var/cache/bind";

    rate-limit {
        responses-per-second 20;
        errors-per-second 10;
        nxdomains-per-second 10;
        nodata-per-second 10;
        referrals-per-second 10;
        window 5;
        slip 2;
        ipv4-prefix-length 24;
        ipv6-prefix-length 56;
        max-table-size 20000;
    };
};

These values aren't universal. responses-per-second limits repeated successful answers, while the error, NXDOMAIN, NODATA, and referral controls isolate response classes that attackers commonly generate. window defines the tracking period. Prefix lengths determine how BIND groups clients, and table size limits the memory used for rate state.

Tune the slip behavior

The slip value controls what a rate-limited client receives. BIND 9 permits values from 0 through 10. With slip 0, every response is dropped. With slip 1, every response slips through. Values from 2 through 10 allow every nth response through. BIND can send a short BADCOOKIE response or set TC=1, encouraging a legitimate resolver to retry over TCP instead of receiving the full repeated answer. BIND 9.18.41's reference documentation describes the behavior.

slip 0 maximizes suppression but can leave legitimate clients waiting for timeout and retry behavior. A nonzero value preserves a recovery signal, which matters for resolvers behind shared NAT or large enterprise gateways.

Validate without restarting

Run the configuration check, reload the running daemon, and test both normal and TCP resolution:

named-checkconf -z /etc/bind/named.conf
rndc reconfig
dig @192.0.2.53 example.com A +stats
dig @192.0.2.53 example.com A +tcp

A healthy test returns an answer with low, consistent latency over UDP and TCP. During an incident, logs may show RRL slip events. A growing stream of slips combined with normal client failures means the limit is too aggressive, the traffic is concentrated behind shared resolvers, or the upstream path needs mitigation. If the change behaves badly, restore the backup and run named-checkconf -z before reloading the previous configuration.

Why Anycast Is Not a Complete DNS Strategy

Anycast improves distribution by advertising the same service from multiple network locations. It doesn't make those locations independent by itself. If one site is saturated, route withdrawal and health checks may move traffic elsewhere, but convergence, monitoring accuracy, control-plane access, and the attacker's ability to target several sites still matter.

A study covering more than 210 million second-level domains found Anycast adoption of 97% among top-level domains and 62% among second-level domains, while concluding that Anycast doesn't eliminate resilience risks. The academic research on Anycast resilience recommends diversity across autonomous systems, prefixes, IP addresses, and geographic locations. Unicast redundancy can improve recovery, but it adds cost and operational complexity.

A smaller organization's redundancy model

Use Anycast as one layer of the authoritative service, not the entire plan. Add a secondary provider on a different autonomous system, keep administrative access independent from the DNS provider, and maintain a recovery path that doesn't depend on the same hosting network.

For a small organization, the practical question isn't "Does DNS use Anycast?" It's "Which failure domains remain if the DNS provider, hosting network, and control plane are attacked at the same time?" ARPHost's DDoS protection cloud guidance is relevant when application and infrastructure placement need to be considered together, but the DNS design should still preserve provider and network independence.

DNSSEC, Water Torture, and the Limits of Network Mitigation

DNSSEC authenticates DNS data. It helps resolvers detect forged or altered answers, but it doesn't absorb a volumetric attack or guarantee availability. Protocol-level research found that DNSSEC-related responses can provide roughly 6 to 12 times the amplification of regular domains on average, with ANY and DNSKEY queries especially concerning. The IETF-hosted DNSSEC research recommends multiple controls, including response-rate limiting, response-size limits, DNS cookies, and ingress filtering.

That creates a trade-off. Enabling DNSSEC can improve authenticity while increasing the size of responses that an attacker tries to reflect. The correct operational response isn't to disable DNSSEC automatically. Apply signing carefully, tune response controls, and monitor the delegation path.

Water-torture traffic needs a different response

A DNS-water-torture attack sends queries for random or uncached names. Repeating one popular answer is easy for a cache and an RRL policy to handle. Random names force recursive resolvers to perform work upstream, generate negative responses, and fill operational telemetry with failures.

Monitor more than uptime:

• DS validity: Detect parent-side delegation and signing errors.
• DNSKEY response rates: Identify pressure on DNSSEC-related responses.
• RRL counters: Separate normal throttling from sustained abuse.
• Resolver errors: Track SERVFAIL, timeout, and retry behavior.
• Delegation consistency: Confirm that parent and child data agree.
• Nameserver diversity: Look for single or duplicated service dependencies.

Incorrect DS records, expired signing keys, parent-child zone mismatches, single or duplicated nameservers, and dangling records can all make a domain unreachable while the DNS servers remain online. Treat delegation and signing as production dependencies, not one-time setup tasks.

Operational boundary: A DNS firewall can deflect abusive queries. It can't make a saturated transit link reachable.

A distributed authoritative service can cache and answer on behalf of customer-managed infrastructure, reducing the requests that reach the origin DNS servers. Upstream volumetric scrubbing remains necessary when the traffic exceeds the host's interface or provider's transit capacity.

Recommended Configuration for Hosted Services

For a VPS, bare metal host, or Proxmox cluster serving multiple customer zones, apply controls in this order.

1. Separate roles. Run authoritative DNS independently from public recursion. If recursion is required, restrict it to approved networks and keep it off the authoritative view.

2. Protect the path first. Confirm that the upstream provider can filter UDP and TCP port 53 traffic before it reaches the host. A local firewall is useful, but it can't solve an already congested circuit.

3. Enable BIND RRL. Start with separate thresholds for successful responses, errors, NXDOMAIN, NODATA, and referrals. Test with representative resolver traffic, then tune slip so legitimate clients can recover through TCP.

4. Distribute service. Use Anycast where it fits, then add independent autonomous systems, prefixes, locations, or a secondary provider. Verify that registrar access and DNS control-plane credentials don't share the same failure domain.

5. Monitor both paths. Test authoritative answers directly and recursive resolution from outside the hosting network. Alert on latency and error behavior, not only process status.

In multi-tenant infrastructure, the first sign of a DNS-layer attack is rarely a total outage. More often, p95 resolver latency drifts for five minutes, followed by a surge in NXDOMAIN responses from one source range. That sequence gives an operator time to compare source distribution, RRL counters, and upstream flow data before changing limits blindly.

Keep a tested rollback:

cp /etc/bind/named.conf /etc/bind/named.conf.pre-rrl
named-checkconf -z /etc/bind/named.conf
rndc reconfig

If resolution degrades after the change, restore the saved file, validate it, and reload with rndc reconfig. For teams that don't want to operate this response path alone, ARPHost's DDoS protection solutions describe infrastructure-level options alongside host controls.

What Operators Ask After the First Wave

Why did the recursive resolver fail while authoritative DNS stayed healthy? Recursive resolution performs work on behalf of clients, so random uncached names, upstream timeouts, or an open-resolver policy can exhaust that path without affecting authoritative answers. Separate the roles and inspect cache misses, upstream latency, and client source ranges.

What should a small team monitor? Track external resolution latency, SERVFAIL, timeouts, NXDOMAIN behavior, RRL counters, DS validity, and delegation consistency. Process uptime alone won't show a DNS service that answers too slowly to be useful.

When should DNS move to a managed provider? Use managed authoritative DNS when your team can't maintain independent networks, upstream filtering, continuous testing, and delegated-zone recovery. Self-hosting remains reasonable when you control the routing, capacity, and operational response.

When do you escalate? Escalate as soon as the transit link approaches saturation or route reachability becomes unstable. Application firewalls and BIND tuning can't repair a congested upstream path. For broader infrastructure operations, ARPHost's managed services are an option for teams that need ongoing support.

ARPHost, LLC provides VPS, bare metal, colocation, private cloud, and managed infrastructure with multi-layer DDoS protection and U.S.-based operational support. Visit ARPHost, LLC to discuss a DNS-aware hosting design, upstream mitigation, or hands-on incident support.