When a recursive resolver is driven to chase domains whose authoritative servers answer slowly or never, its finite pool of outstanding-query slots fills with lookups that will never complete. That stalled backlog is a phantom domain attack, one of the quieter DNS failure modes a thorough DDoS test is built to reproduce. The attacker stands up, or simply points at, authoritative name servers that are deliberately unresponsive, then pushes a target resolver to look up the domains those servers own. Every such query opens outbound state and starts a timeout clock against a server that will never answer.
How a phantom domain attack works
A recursive resolver that cannot answer from cache has to walk the delegation chain to an authoritative server and wait for the reply. That is ordinary DNS flood territory, except the pressure here is not query volume but the wait itself.
The attacker registers or points at name servers that either black-hole queries outright or trickle a response back a byte at a time. It then generates lookups for names delegated to those servers. The resolver opens an outstanding-query slot, sends the query, and holds the slot open for the full resolution timeout, often several seconds, before it gives up.
Bandwidth stays trivial. A few hundred bytes per second of queries can tie a resolver in knots, because the resource the attacker is buying is held state and timeout budget, not packets on the wire. In that respect it behaves like a low and slow attack wearing a DNS query as its costume: the goal is to occupy a slot, not to fill a pipe.
Why it matters under attack
The damage lands on infrastructure the attacker never floods directly. A resolver carries a bounded number of concurrent recursions (BIND, for one, caps this explicitly), and once every slot is parked on a phantom, a lookup for a real domain has nowhere to sit and simply fails. Nothing in the traffic graph looks alarming while resolution quietly dies.
It is worth separating this from DNS water torture, the other resolver-exhaustion vector and the one it is most often confused with. Water torture forces cache misses with random subdomains so the load rolls downstream onto the victim's own authoritative tier. A phantom domain attack does the opposite: it keeps the pain on the recursive resolver by arranging for the upstream answer to arrive slowly or not at all. One saturates authoritative capacity; the other saturates resolver state.
What a DDoS test measures
A test characterises how many concurrent unresolved queries a resolver absorbs before real resolution degrades, and whether the hardening specific to this vector actually engages under that load.
Three controls carry the defense, and each is verified rather than assumed. A shorter resolution timeout frees a slot parked on a dead delegation sooner. A per-server and per-zone cap on in-flight queries (BIND exposes this as fetches-per-server and fetches-per-zone) stops one unresponsive domain from consuming the entire recursion budget. And a holddown that stops re-querying a server already proven unresponsive keeps the resolver from re-arming its own trap.
The deliverable is the concurrent-stall ceiling: how many outstanding phantom lookups the resolver tolerates before good queries start failing, and the name of the limit that gave out first. What that ceiling means for the resolver you actually run, and how it is exercised alongside the rest of the name-resolution path, is worked through in DNS infrastructure under DDoS.