What a DNS query flood does
A DNS query flood overwhelms a name server with lookups. The most effective variant — the water-torture or pseudo-random subdomain attack — asks for a fresh random label under a real domain every time, for example a1b2c3d4e5f6.example.com. Because no two names repeat, resolver caches never help: each query is forced through to the authoritative server, which spends a real lookup only to answer NXDOMAIN. A modest packet rate can saturate the resolution path while ordinary bandwidth graphs still look calm.
How ddos-sim.com simulates it safely
ddos-sim.com sends standard DNS A queries over UDP to a single verified domain pinned to a public address, within the rate limits for that domain. Every query name is a random subdomain of your own verified domain and each carries a fresh transaction ID — nothing you supply is transmitted, so the flood cannot be steered at another name or turned into an arbitrary-payload primitive.
Every run is bound to one verified domain you have proven you own, and the worker only ever sends to that one assigned address — never a spoofed source and never a third-party resolver, so this is a direct query flood, not reflection or amplification. Running traffic against systems you do not own or are not clearly authorized to test may be unlawful. See the Acceptable Use Policy.
What the test exercises
- Authoritative name-server throughput when cache hits drop to zero
- Resolver behaviour and negative-cache handling under a random-subdomain load
- DNS response-rate limiting and per-client query caps
- UDP ingress filtering and headroom on port 53
- How quickly resolution recovers once the flood stops
How to run a DNS query flood test
- Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
- Point the command at your DNS. Add the
dns_query_floodcommand with the target port set to53, and set the query rate and duration. The queries hit the verified domain's address, so aim it at a host that answers DNS. - Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
- Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
- Read the results. Review the recorded send rate and worker timeline to find where resolution starts to bend.
Availability & limits
The DNS query flood is one of the more aggressive network-layer methods, so it requires extended validation — a manual review — and is priced per engagement. Verify your domain before it runs.
Frequently asked questions
What is a DNS water-torture attack?
It floods a DNS server with queries for random, non-existent subdomains of a real domain. Because every name is unique, resolver caches always miss and each query is driven through to the authoritative server, which burns a fresh NXDOMAIN lookup per request. It is also called a pseudo-random subdomain or NXDOMAIN flood.
Does this spoof addresses or use reflection?
No. Queries are sent from our own load-generation machines with their real source address to your one verified target, and no third-party resolver is involved. It is a direct query flood, never a spoofed reflection or amplification attack.
What if DNS is not hosted on my web server's address?
Each worker only ever sends to the verified domain's pinned address, so the test exercises DNS only when a resolver or authoritative server answers there. If your name servers live elsewhere, this method will not reach them — verify the host that actually serves DNS.
Rehearse a DNS query flood against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.
Build a test plan