Is your DNS resolver an open resolver?

What makes a resolver “open”

A recursive resolver is the DNS server a client actually asks, tracking an answer down through the root, TLD and authoritative servers on the client’s behalf. It becomes an open resolver the moment it answers that same recursive query for any client on the internet, not just the network or users it was built to serve. RFC 5358, published as BCP 140, recommends operators restrict recursive service to intended clients only — through access control lists or authentication — rather than leaving it open by default.

Why it matters: amplification, not just unwanted traffic

An open resolver’s real danger isn’t that strangers can look things up through it — it’s that an attacker can send it a query with a victim’s IP address spoofed as the source, and the reply (often much larger than the request) floods the victim instead of the attacker. The resolver operator typically only sees an unexplained spike in outbound query traffic, not that their server was used as a weapon against someone else. This depends on source-address spoofing working at all, which is the separate problem BCP 38 (RFC 2827) addresses by filtering forged source addresses at the network edge — closing either gap (open recursion or spoofable source addresses) helps prevent the attack.

How to check a resolver you operate

Test from a host outside the network the resolver is meant to serve — querying it from inside that network will always get an answer and tells you nothing about what the rest of the internet sees:

dig @203.0.113.10 example.com +short

A real answer back means the resolver responded to a client it had no business serving — that’s an open resolver. No answer, a REFUSED status, or a timeout is the result you want. If you manage more than one resolver or a resolver with multiple interfaces, repeat this from a couple of distinct external vantage points, since some misconfigurations only expose recursion on one network path rather than globally.

What AdminKit checks today, and what it doesn’t

AdminKit’s DNS resolver test is coming soon via the Check API, and it’s built to answer a related but different question than this guide: which resolver is actually answering your own device’s queries, which helps catch a DNS leak or a hijacked router — see is my router’s DNS hijacked for that use case. It is not designed to audit whether a resolver you operate answers the entire internet’s queries, so the external dig test above remains the practical self-check for that until a dedicated tool exists. AdminKit’s live DNS lookup tool is useful once you’ve locked recursion down, to confirm your own domain’s records resolve the way you expect through a resolver you trust.

How to fix an open resolver

Restrict recursive query answers to your own known client networks using an access control list (most resolver software — BIND’s allow-recursion, Unbound’s access-control, etc. — supports this directly), rather than leaving the default “answer everyone” configuration in place. Separate authoritative and recursive roles onto different servers if a single box is currently doing both, since an authoritative server generally should answer anyone for the zones it hosts, while a recursive resolver generally should not.

Other exposure checks worth running

This same spoofed-source amplification pattern isn’t unique to DNS — how to check if port 123 (NTP) is exposed covers the NTP equivalent. If you’re reviewing mail infrastructure, see how to publish and test MTA-STS, and for a different DNS hygiene risk entirely, see how to find a dangling CNAME. All of these sit in AdminKit’s DNS cluster alongside the live tools and glossary terms that back them.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.