How to Detect Open DNS Resolvers

An open DNS resolver is a DNS server that accepts recursive queries from any IP address on the internet. While public resolvers like Google (8.8.8.8) and Cloudflare (1.1.1.1) are intentionally open, most organizations shouldn't be running one — and many don't realize they are.

Why Open Resolvers Are Dangerous

Open resolvers are commonly exploited for DNS amplification attacks — a type of DDoS attack where:

1. The attacker spoofs the victim's IP address in DNS queries
2. Queries are sent to open resolvers requesting large DNS responses (like ANY or TXT records)
3. The resolvers send those large responses to the victim's IP
4. A 60-byte query can generate a 4,000+ byte response — a 70x amplification factor

Open resolvers also increase your attack surface for DNS cache poisoning, can leak information about internal network queries, and may violate security compliance requirements.

How to Detect Them

The simplest test: can an external IP send a recursive DNS query to your server and get an answer?

You can use the DNS Toolkit Compare Resolvers endpoint to test how different resolvers respond to queries for your domain, which helps identify if any infrastructure is unexpectedly acting as an open resolver:

curl -H "X-API-Key: YOUR_KEY" \
  "https://api.dnstoolkit.io/dns/compare-resolvers?domain=example.com"

This queries your domain across major public resolvers and returns their responses with latency data. If you're running your own DNS infrastructure, compare the behavior of your servers against known-good public resolvers.

Common Culprits

• Misconfigured BIND servers — default configurations sometimes allow recursion for all clients
• Home routers — many consumer routers run a DNS forwarder that's open to the WAN interface
• Forgotten test servers — development or staging DNS servers left running in production
• IoT devices — some devices run embedded DNS services that accept external queries

Fixing Open Resolvers

• Restrict recursion — configure your DNS server to only accept recursive queries from trusted IP ranges (your own network)
• Use ACLs — in BIND, use allow-recursion to whitelist internal subnets
• Rate limit responses — implement DNS Response Rate Limiting (RRL) to mitigate amplification even if recursion is needed
• Firewall rules — block inbound DNS (port 53) from the internet on servers that shouldn't be public resolvers

Ongoing Monitoring

Open resolver detection isn't a one-time fix. New services get deployed, configurations change, and shadow IT creates new exposure. Build regular scanning into your security monitoring pipeline — check your public-facing IP ranges for unexpected DNS services at least monthly.