DNS Flood DDoS Attack

What is a DNS flood?

A DNS flood DDoS attack attempts to overwhelm DNS infrastructure with more query traffic than it can process reliably. If DNS fails, users may not be able to find the IP addresses for websites, APIs, mail systems, login services, or other internet-facing applications. The protected application can be fully healthy and still appear offline because the name resolution step fails first.

DNS floods differ from DNS amplification attacks. In amplification, a victim receives reflected response traffic. In a DNS flood, the DNS service itself is under pressure from excessive queries or connection attempts. The target may be an authoritative DNS provider for a domain, a recursive resolver used by employees or customers, or DNS infrastructure embedded in a hosting or edge platform.

Why DNS is an availability dependency

Most user journeys begin with DNS. A browser, mobile app, API client, payment system, monitoring probe, or email server must resolve a name before it can connect. This makes DNS a high-leverage target: disruption at the name-resolution layer can make many services unreachable at once, even if web servers, databases, and application code are operating normally.

DNS is also shared. A single zone may support the public website, static assets, API hostnames, identity providers, customer portals, support tools, and mail-related records. A flood against one part of the DNS setup can create confusing symptoms across many teams. Web engineers see traffic drop. Support hears that users cannot load the site. Network teams see query pressure. Security teams investigate a DDoS. Incident command needs to connect those views quickly.

Patterns defenders should watch

Indicators of a DNS flood include sharp increases in query volume, rising DNS response latency, SERVFAIL or timeout rates, authoritative server saturation, resolver CPU pressure, packet loss, and failing external DNS checks. Query distribution matters too. A flood may focus on a small set of names, spread across many valid names, or generate large numbers of non-existent subdomains that bypass normal caching.

Source patterns are useful but incomplete. A flood may come from many networks, from compromised devices, from cloud infrastructure, or through recursive resolvers that hide the original clients. Defenders should look at query names, record types, cache hit rates, response codes, geography, autonomous system concentration, and whether the same sources are affecting application traffic. The goal is to identify pressure without assuming that every unusual DNS client is malicious.

Impact patterns during an incident

DNS floods often create intermittent failures rather than a clean outage. Some users can resolve names from cached answers while others time out. Mobile networks may behave differently from office networks. Regions near a saturated DNS node may fail while other regions work. Monitoring can disagree depending on where probes run and whether they use cached resolver answers.

The impact can also outlast the flood. Low time-to-live values may increase query pressure during recovery. Resolver caches may retain temporary failures. Emergency DNS changes can take time to propagate through recursive resolvers. If responders change records under pressure without a rollback plan, they can create a second availability problem after the attack traffic falls.

Defensive architecture

Resilient DNS starts with separation of roles. Public authoritative DNS should be treated as internet-facing availability infrastructure. Internal recursive DNS should be limited to the networks and users it is meant to serve. Administrative DNS changes should be protected with strong authentication, clear ownership, and change review because an account compromise can look like a DNS outage to users.

Authoritative DNS should have geographic and network diversity. Anycast DNS, multiple authoritative nodes, secondary DNS providers, and provider-level DDoS protection can reduce the chance that one saturated location takes down the domain. For critical services, teams should understand whether all name servers depend on the same provider, same control plane, same registrar, same cloud account, or same upstream network.

Capacity controls must be applied carefully. Rate limiting can protect DNS systems from obvious excess, but overly simple limits can block legitimate recursive resolvers that aggregate traffic from many users. Response policies should consider query name, response type, resolver behavior, and service criticality. DNSSEC, where used, should be monitored for validation failures and response-size side effects, but it is not itself a complete DDoS control.

Operational response

A DNS flood runbook should answer several questions before an incident. Who owns the domain and registrar access? Which provider operates authoritative DNS? Are there secondary DNS arrangements? Which records are critical for the website, APIs, mail, identity, and monitoring? What are normal query volumes by zone and region? How are emergency changes approved and reversed?

During an incident, responders should avoid making blind record changes just because users report that the site is down. First determine whether the failure is authoritative DNS, recursive resolution, connectivity, CDN routing, or application availability. External DNS probes from multiple networks are valuable because they show what users are experiencing outside the organization's own resolvers.

Mitigation may involve enabling provider DDoS controls, shifting authoritative service to a prepared secondary, tightening abusive query handling, increasing caching where safe, or coordinating with upstream networks. The right choice depends on which layer is failing and what protection was prepared in advance.

Misconceptions

One common misconception is that DNS floods are only a DNS-team problem. DNS availability is a business dependency; application, security, network, support, and communications teams need shared visibility. Another misconception is that high TTLs or low TTLs are always better. Long TTLs can reduce query pressure and improve resilience for stable records, but they also slow emergency changes. Short TTLs support agility, but they can increase DNS load and make floods more painful.

It is also easy to confuse a DNS flood with a web DDoS because both produce user-facing unavailability. The distinction matters. If users cannot resolve the name, adding web servers or changing application rate limits will not restore service. DNS flood defense depends on robust authoritative infrastructure, resolver hygiene, external monitoring, and rehearsed coordination with the providers that carry the DNS traffic.