An open DNS resolver is a recursive DNS server that accepts and processes DNS queries from any source on the internet, not just from its own network. While public resolvers like Google (8.8.8.8) and Cloudflare (1.1.1.1) are intentionally open and built to handle global traffic, an unintentionally open resolver — like your corporate DNS server or a misconfigured nameserver — is a security liability that can be weaponized in massive DDoS attacks.
I find that open resolvers are one of the most common DNS misconfigurations in the wild. Many administrators set up a DNS server for their internal network and do not realize it is also answering queries from the entire internet.
Recursive vs. Authoritative DNS
To understand why open resolvers are dangerous, you need to understand the difference between recursive and authoritative DNS:
Authoritative servers answer questions about domains they host. If you ask ns1.example.com about example.com, it answers from its own zone data. It does not look anything up on your behalf.
Recursive resolvers answer questions about any domain by performing the full DNS resolution process — querying root servers, TLD servers, and authoritative servers on the client's behalf, then caching and returning the result.
An open resolver is a recursive server that performs this work for anyone who asks, regardless of whether they are on the same network or on the other side of the planet.
Why Open Resolvers Are Dangerous
DDoS Amplification
The primary danger is DNS amplification attacks. An attacker sends a small DNS query to your open resolver with a spoofed source IP (the victim's IP). Your resolver processes the query and sends its (much larger) response to the victim, not to the attacker.
Attacker sends: 40-byte query with spoofed source IP
Your resolver: Processes it, sends 3000-byte response
Response goes to: The victim (whose IP was spoofed)
Amplification: ~75x
With thousands of open resolvers, the attacker generates massive traffic volumes directed at the victim. Your server is an unwitting participant in the attack.
The 2013 Spamhaus attack — one of the largest DDoS attacks in history at 300 Gbps — was executed almost entirely through open resolvers.
Cache Poisoning Target
Open resolvers are also targets for DNS cache poisoning. Because they accept queries from anyone, an attacker can trigger resolution of any domain and then race to inject forged responses. A poisoned open resolver affects every user who queries it.
Resource Abuse
An open resolver consumes your server's CPU, memory, and bandwidth processing queries for the entire internet. This can degrade performance for your legitimate internal users and increases your operational costs.
Reputation Damage
If your server is identified as participating in DDoS attacks (even unknowingly), your IP address may be blocklisted. This can affect your email delivery, web traffic, and ability to interact with other services.
How to Check If Your Server Is an Open Resolver
The test is simple. From an external IP address (not your own network), run:
dig @your-server-ip example.com A +recurse
If the server returns an answer: It is an open resolver. It performed recursive resolution for your external query.
If the server returns REFUSED or does not respond: It is correctly restricting recursive queries.
You can also use online open resolver testing tools:
# Query the DNS-OARC open resolver test
dig +short @your-server-ip amiopen.openresolverproject.org TXT
Testing from Your Network vs. Externally
It is critical to test from outside your network. The resolver should work for your internal users but refuse queries from the internet. Testing from your own network will always succeed (as intended) and does not reveal the vulnerability.
How to Fix an Open Resolver
BIND
Restrict recursion to your own network ranges:
options {
// Only allow recursion from these networks
allow-recursion {
127.0.0.0/8; // Localhost
10.0.0.0/8; // Internal
172.16.0.0/12; // Internal
192.168.0.0/16; // Internal
};
// Explicitly disable for everyone else
recursion yes;
};
Unbound
Unbound restricts access through access-control directives:
server:
# Allow recursion for internal networks
access-control: 127.0.0.0/8 allow
access-control: 10.0.0.0/8 allow
access-control: 172.16.0.0/12 allow
access-control: 192.168.0.0/16 allow
# Deny everything else
access-control: 0.0.0.0/0 refuse
PowerDNS Recursor
allow-from=127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Windows DNS Server
In the DNS Manager:
- Right-click the server → Properties
- Go to the Advanced tab
- Check "Disable recursion (also disables forwarders)" if the server should be authoritative only
- Or use firewall rules to restrict port 53 access to internal networks
Firewall-Level Protection
Even if your DNS server configuration is correct, add a firewall rule as defense in depth:
# Block external access to port 53 on the resolver
# Allow only from internal networks
iptables -A INPUT -s 10.0.0.0/8 -p udp --dport 53 -j ACCEPT
iptables -A INPUT -s 10.0.0.0/8 -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP
Authoritative + Recursive on the Same Server
A particularly dangerous configuration is running both authoritative DNS and recursive resolution on the same server. The server must accept queries from the internet for the authoritative zones it hosts, but if recursion is enabled globally, it also acts as an open resolver.
The fix: Configure recursion to only be available for internal networks while allowing authoritative queries from anyone:
# BIND: separate views
view "internal" {
match-clients { 10.0.0.0/8; 192.168.0.0/16; };
recursion yes;
zone "example.com" {
type master;
file "example.com.zone";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "example.com.zone";
};
};
Better yet, separate the functions onto different servers entirely. Run your authoritative DNS on one server (or use a managed DNS provider) and your recursive resolver on a separate internal server.
The Open Resolver Project
The Open Resolver Project tracks open resolvers worldwide and works with network operators to close them. At its peak, the project identified over 25 million open resolvers on the internet. While the number has decreased significantly, millions remain.
If your server appears in open resolver lists, you may receive abuse complaints from your hosting provider or upstream ISP. Taking proactive steps to close your resolver is both a security best practice and a good-neighbor obligation.
Mitigation Checklist
- Recursive resolvers are restricted to internal network ranges only
- Firewall rules block port 53 access from external sources (for resolvers)
- Authoritative and recursive functions are on separate servers (ideal)
- If combined, BIND views or equivalent separate recursive and authoritative access
- External open resolver test confirms the server refuses recursive queries
- Response Rate Limiting is enabled on authoritative servers
- DNS server configuration is audited after any changes
Common Misconfigurations
- Default BIND configuration with recursion enabled — BIND allows recursion by default; you must explicitly restrict it
- Authoritative + recursive on the same IP without view separation — the server answers recursive queries from anyone because it must be publicly accessible for authoritative queries
- Cloud instances with public IPs running DNS for internal use — the public IP means the entire internet can reach port 53
- Firewall rules that allow all DNS traffic — port 53 is allowed inbound for authoritative service, but this also permits recursive queries
- Not testing from outside the network — administrators test from internal IPs and see correct behavior, never discovering the external exposure
Ethical Note
If you discover an open resolver run by someone else, report it to the network operator (use the IP's WHOIS contact or abuse address). Do not use open resolvers for amplification testing or any form of DDoS, even against your own infrastructure — the spoofed traffic passes through third-party networks. Test your own servers only from external vantage points to verify they are not open.
For more on how open resolvers are weaponized, see DNS Amplification Attack. For broader DNS security guidance, see the Complete Guide to DNS Attacks and DNS Security.