Why DNS is a prime DDoS target

DNS servers are a high-value target for DDoS attackers because taking them down indirectly disrupts every website and service that depends on them for name resolution. While HTTP flood attacks target websites directly, DNS-based attacks aim to overwhelm the infrastructure that translates hostnames to IP addresses — a successful strike can cause outages across multiple services.

The scale of the problem is significant. In 2023, DNS attacks accounted for 33% of all DDoS attacks, making them the second most common attack type. The infamous 2016 Dyn attack, carried out by the Mirai botnet, remains a reference point: it took down major sites including Airbnb, Netflix, and Amazon, and required an entire day to fully restore services. Mirai-variant botnets are still active, accounting for 3% of all network-layer DDoS attacks in 2023.

Where fingerprinting falls short

Traditional mitigation relies on attack fingerprinting — identifying recurring patterns in query fields and generating rules to filter matching packets. This works well when attackers randomize only a few fields. For example, if an attacker sends floods of queries with a consistent source port and a single queried domain like example.com, a mitigation system can detect that pattern and surgically block the malicious traffic.

Sophisticated attackers break this model by randomizing multiple query fields simultaneously. Without a consistent fingerprint, mitigation systems face two failure modes: they may miss large portions of the attack because only traffic matching a narrow pattern gets filtered, or they may mistakenly catch legitimate queries that happen to resemble the attack traffic. The problem gets worse when the pattern is too generic — for instance, matching on a source port alone would block legitimate clients who were randomly assigned that same port.

The DNS laundering problem

Attackers have also learned to route their traffic through reputable public DNS resolvers, a technique called DNS laundering. In this scenario, the attacker queries randomized subdomains of a real domain managed by the victim's authoritative DNS server. Because each subdomain prefix is unique and never reused, recursive resolvers always miss their cache and must forward each query upstream. The authoritative server ends up receiving a flood of legitimate-looking queries that it cannot filter based on domain name alone — the domain itself is genuine and must remain resolvable.

This creates a dilemma. Authoritative DNS servers cannot block queries from recursive resolvers, because those same resolvers also carry legitimate traffic. And they cannot filter queries for the targeted domain, because that domain is real and needs to stay accessible.

Building a behavioral model instead of relying on fingerprints

To solve this, the new Advanced DNS Protection system takes a different approach. Instead of searching for attack patterns, it builds a data model of each customer's expected DNS query traffic from historical records. This gives the system a way to judge whether an incoming query is likely to be legitimate without needing a consistent attack signature to lock onto.

The system was built on the same stateful mitigation platform, flowtrackd, that powers the existing Advanced TCP Protection. It runs as a distributed system with instances on every Cloudflare server worldwide. Each instance detects and mitigates attacks autonomously with zero-second response time, while also gossiping with other instances in the same data center to share threat intelligence and coordinate a full mitigation.

Under the hood, each server continuously sends DNS-related data — query type and queried domain, without the query source — to core data centers. There, the system periodically computes traffic profiles per customer and distributes those profiles back across the global network. When a query arrives, the local instance consults the profile and decides whether to pass or drop it, adjusting for the customer's tolerance for unexpected queries.

Operational details and analytics

Advanced DNS Protection is currently in beta and is available at no additional cost to all Magic Transit customers. Since Magic Transit uses direct server return (DSR), Cloudflare cannot see DNS origin server responses to infer query legitimacy — that is precisely why the data model approach was necessary.

The system complements existing fingerprinting-based protections, giving customers a layered defense: fingerprinting catches attacks with clear patterns, while stateful analysis handles the randomized ones. It is also configurable, allowing customers to tailor how aggressively unexpected queries are dropped.

New observability features help customers understand their DNS traffic. A "DNS Protection" tab in the Cloudflare Network Analytics dashboard shows which queries are passed and dropped, along with characteristics such as queried domain name and record type. The same data is available programmatically through the Cloudflare GraphQL API and can be exported via Logpush for integration into external monitoring dashboards.

Engineering trade-offs in the Advanced DNS Protection system

Several technical challenges emerged while building the system, particularly around handling the scale of DNS data Cloudflare processes daily and the operational burden of distributing per-customer models across the fleet.

Profiling at scale

The system processes tens of millions of DNS queries per day across the global network for Magic Transit customers alone. Building custom query traffic profiles from this data requires careful pipeline design. The team uses sample-on-write and adaptive bitrate technologies when writing and reading the data, respectively, to capture fine granularity without overloading data infrastructure. Information that could impact end-user privacy is deliberately dropped.

Keeping profiles compact

Some individual customers see tens of millions of DNS queries per day. Storing and distributing that volume in uncompressed form would be prohibitively expensive. Each customer's traffic profile therefore uses a counting Bloom filter, a probabilistic data structure that provides a succinct representation of the query data. It can be stored and distributed efficiently, then queried directly at packet processing time.

Distribution across the edge

Customer DNS profiles must be recomputed and redistributed between data centers and to every server in the fleet on a periodic basis. This is handled with Cloudflare's R2 storage service, using regional hints and custom domains to enable caching across a handful of R2 buckets. When a global update of the customer data models is pushed, 98% of the bits transferred are served from cache.

Allowing for the unknown

When a new domain name is put into service, the data models will not initially know about it because no prior queries exist for that name. Combined with other potential sources of false positives, the system must tolerate queries that deviate from the learned profile. Token bucket algorithms provide that tolerance, with customers controlling bucket size via the sensitivity level of the Advanced DNS Protection system. Lower sensitivity means a larger token bucket—and more tolerance for unexpected or out-of-profile queries—while higher sensitivity tightens enforcement.

The Advanced DNS Protection system combines global infrastructure, data processing capabilities, and intelligent algorithms and data structures to protect customer DNS servers. Existing Cloudflare customers can enable it by contacting their account team or Cloudflare Support; others can reach out through the Advanced DNS Protection landing page.