/PLAYBOOK · 2026-09-14

DNS Wildcard Attack on Your Domain: Resolution-Layer Defense

Resolution-layer hits are the DDoS form operators miss: the attacker never touches the server, just floods the authoritative DNS until the whole site times out. Eight Q&As cover DNS Flood vs wildcard attacks, how to prove a resolution-layer fault, BIND rate-limit, and managed DNS selection.

Operators hit this often: the box is fine, IP access works, the domain will not open and resolution times out. The server may be healthy. The resolution layer is dead. DNS attacks look small on a traffic graph and still make the whole site vanish. Eight Q&As cover DNS Flood vs wildcard attacks, how to prove the fault is at resolution, and how to harden authoritative DNS and origin separately.

Q: DNS Flood vs wildcard attack — difference?

Both hit the resolution layer. Target and amplification differ.

DNS Flood dumps query volume at your authoritative DNS. Many names are random or nonexistent (NXDOMAIN). The server walks the zone and answers each one. CPU, bandwidth, and concurrent sockets drain. Legitimate queries never get a slot. Result: origin is untouched, the world cannot resolve your name.

A wildcard attack abuses a config hole. If the zone has a wildcard (`*.example.com` all point at one IP), the attacker mints huge numbers of random labels (a1, a2, a3…) and queries them. Nonexistent subdomains still run a full lookup; query load multiplies. Worse: if the wildcard A points at origin, those random names hit the origin too and skip every front-door control.

One line: DNS Flood hits the resolver service itself. Wildcard attack is a config bug plus query amplification, and it can expose origin as a side effect.

Q: Resolution layer or origin — how do I tell?

Three tells:

Resolution layer: domain lookup times out or fails, origin IP access is fine; different public DNS give inconsistent answers; the site looks like “server not found,” not 502/timeout.
Origin: resolution is fine (dig returns an IP), but requests 502/504 or hang; host load and bandwidth are clearly wrong.

Cross-check with two queries — one at your authoritative NS, one at public DNS:

dig @YOUR_NS example.com +short
dig @223.5.5.5 example.com +short

Public DNS answers, your authoritative NS times out → fault is on the authoritative side. Then read the query curve: BIND via rndc stats QUERY counters; managed DNS via console QPS/volume graphs.

Q: Why is wildcard an attack entry? How do I self-check?

Wildcard exists for convenience: new subdomains need no extra records. Cost: every nonexistent subdomain returns a live IP. That is a back door — random-label queries burn resolver CPU, and if they point at origin, origin eats junk traffic and can be used for black-hat SEO wildcard spam sites.

Self-check is one query against a name that should not exist:

dig @8.8.8.8 random9x8z7q.example.com +short
# An IP back = wildcard is on
rndc reload   # reload after you change records

Rule: no business need → delete the `*.example.com` A. Multi-tenant SaaS that must keep it: put a default server block on origin that drops invalid hosts. Do not let them into main-site logic.

Q: Resolution is under fire. First move?

Three steps in order. Availability first, hardening second.

First, map the surface. Cross-dig public resolvers. Decide whether authoritative DNS is hit or the recursive path is sick. Confirm the query curve is actually amplified.

Second, add backup NS or cut to managed DNS. One self-hosted NS set that is already dead has only its own pipe; it will not ride out a sustained query flood. At the registrar, add a capable managed DNS as NS. Fastest path back up.

Third, rate-limit self-hosted BIND immediately. In named.conf options:

options {
    rate-limit {
        responses-per-second 10;
        nxdomains-per-second 5;
        errors-per-second 5;
        window 5;
        slip 2;
        exempt-clients { 10.0.0.0/8; 192.168.0.0/16; };
    };
};

Also cap UDP/53 at the host so packet rate cannot fill the NIC:

iptables -I INPUT -p udp --dport 53 -m limit --limit 200/s --limit-burst 400 -j ACCEPT
iptables -I INPUT -p udp --dport 53 -j DROP

Q: What else must authoritative DNS harden?

Recursion off: self-hosted authoritative DNS must set `recursion no;`. Open recursion becomes DNS amplification against someone else, and you get blacklisted.
Multiple NS, cross-vendor: at least two NS sets. Prefer one self-hosted plus one managed. No single point.
TTL not tiny: 5s/10s TTL multiplies query volume. Static records 600s+. Shorten only for a planned cutover.
Query ACL on internal names: `allow-query` to internal nets so internal records are not scanned from outside.
DNSSEC is a tradeoff: stops hijack, bigger answers, theoretically better for amplification, higher ops cost. Small sites fix availability first, sign later.

Q: How does managed DNS absorb DNS attacks?

Anycast cluster + fat pipes + nearest-node steering. Managed DNS has many nodes nationally/globally. Users in different regions land on different nodes. A single node under fire is local; the rest still answer. Vendor side has scrubbing and auto rate-limit. Abnormal queries trip it without the operator touching anything.

Cutover is simple: point registrar NS at the vendor NS, wait for NS TTL (hours, 48h worst). Then two things: enable volume/QPS alerts so you hear about spikes; enable per-name query rate-limit so one subdomain cannot be hammered.

Reminder: managed DNS only buys availability. Wildcard and leaked subdomains are still your cleanup.

Q: What does origin need to do in parallel?

DNS-layer controls do not stop someone hitting the IP directly. Origin hardening still applies:

Origin whitelist: origin 80/443 only from CDN origin-pull ranges. Drop the rest. Even with a leaked IP, attack traffic never reaches the web ports.
Catch-all server: invalid hosts and raw-IP hits go to 404. They never enter main-site flow.
Keep CDN cache: during a short DNS outage, users with local or CDN cache still work. That is a side benefit of CDN against resolution faults.

# 443 only from CDN origin-pull ranges (example range; replace with vendor ranges)
iptables -A INPUT -p tcp --dport 443 -s 162.62.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

# Nginx catch-all: invalid hosts and raw IP → 404
server {
    listen 80 default_server;
    server_name _;
    return 404;
}

Q: Anything else?

DNS defense is the classic nobody-owns-it-until-the-site-is-gone layer. Fill gaps in this order: strip wildcard records → recursion off on authoritative DNS → rate-limit + UDP cap → at least two cross-vendor NS (one managed) → TTL back to 600s+ → query-volume alerts.

Note the economics: tens of Mbps of queries can kill a self-hosted BIND box. Defense cost is far below volumetric DDoS scrubbing. For most small/mid sites, handing authoritative resolution to managed DNS and occasionally checking wildcard state is the highest-ROI move.