Concept
DNS infrastructure isn't just a target — misconfigured infrastructure you control can become a weapon used against a third party. An "open resolver" (a nameserver that answers recursive queries from anyone, not just its intended clients) can be abused in reflection/amplification DDoS attacks: an attacker sends a small, spoofed-source query to your open resolver, and your server sends a much larger response to the spoofed (victim's) address — you become an unwitting amplifier. A zone that returns very large responses to ANY-type queries is a more attractive amplification target for exactly this reason.
Common Misconception
"My nameserver is authoritative, not a public resolver, so I don't need to worry about open-resolver abuse." Authoritative-only servers absolutely still need recursion explicitly disabled — many DNS server software defaults ship with recursion enabled unless turned off, meaning an "authoritative-only" intention can still leave the door open in practice. The label you intend for a server and the behavior it actually exhibits are two different things until verified.
Hands-On Exercise
No lab environment needed for the check itself:
- noda.marinadns.io — the Open Recursor and AXFR / Zone Transfer checks (CAT-SEC) test exactly this against your domain's actual infrastructure.
- marinadns.io/bl — a blacklist check; useful context here since infrastructure that's been abused for reflection attacks often shows up on DNSBLs as a side effect.
For testing your OWN nameserver's recursion behavior from an external vantage point (a false positive risk if tested only from localhost) and the ANY-query amplification-factor check, see Lesson 7 in the DNS Admin Course Lab Environment page.
Commands to Run
# Test whether YOUR nameserver answers recursive queries from arbitrary requesters (it should NOT, for an authoritative-only server)
dig @your-lab-box-ip google.com A # from a machine OTHER than the server itself
# Confirm recursion is disabled on an authoritative-only server (BIND example)
grep -i recursion /etc/bind/named.conf.options # should show "recursion no;"
# Check your domain isn't itself vulnerable to being used as a reflection amplifier via ANY queries
dig yourdomain.com ANY @ns1.yourdnsprovider.com +norecurse
# Basic response-size check — larger responses = larger amplification factor if abused
dig yourdomain.com ANY +norecurse | wc -c
If step 1 returns a real answer from a machine that isn't authorized to query your box, recursion is open and needs fixing immediately — this is the exact Open Recursor Check NODA runs under CAT-SEC.
Mastery Checkpoint
You should be able to explain, without looking anything up:
- What a reflection/amplification attack is and specifically what role an open resolver plays in it.
- Why testing recursion from localhost is insufficient to prove a server isn't an open resolver externally.
- Why RFC 5358 (open resolver guidance) is advisory rather than a MUST/SHALL requirement, and what that distinction means practically.
If you can answer all three without re-reading this lesson, move to Lesson 8.
← DNS Admin Course Lab Environment
