An open DNS resolver is a public name server that answers recursive DNS requests from anyone on the internet. Technically, it performs full DNS lookups for unrestricted clients, which can enable cache abuse, traffic amplification in DNS reflection attacks, and exposure of internal resolution behavior if misconfigured.
What an open DNS resolver is
An open dns resolver is not just a convenience setting, it is a recursive name service exposed to arbitrary internet clients. That means it will accept and process lookups from outside its intended trust boundary, which is why the term is usually discussed as a misconfiguration rather than a normal public service design.
The core issue is scope: a resolver is expected to answer recursive queries for a controlled population, such as internal users, a customer base, or a defined network segment. Once recursion is available to anyone, the server can become a shared resource for abuse rather than a bounded part of your naming infrastructure.
Why open resolvers are risky
open resolver are attractive because they can be used to amplify DNS traffic, hide the source of queries, and consume resolver capacity at scale. They are also risky because they may reveal internal naming patterns, forwarding behavior, or other resolution details that were never meant to be observable from the public internet.
In practice, the danger is not limited to the resolver itself. Abuse of open recursion can make your infrastructure part of a broader reflection attack, while the resolver’s cache and response behavior can become a signal for reconnaissance. DNS is an internet-wide control plane, so exposure here can have consequences beyond a single host.
For protocol and registry context around DNS infrastructure, the IANA registries are the canonical reference point for internet protocol parameters and related identifier assignments.
How organisations identify exposure
Exposure usually starts with inventory: know which resolvers exist, which networks they serve, and whether recursion is enabled for unauthorised sources. Organisations should also check whether a resolver is reachable from the public internet, whether cloud security groups or firewall rules permit broad access, and whether vendor or ISP-managed DNS equipment has inherited an unsafe default.
External reachability testing matters because open resolvers are often discovered through simple query attempts from outside the organisation. Reviewing configuration, asset ownership, and authoritative DNS logs can help distinguish an intentionally public service from an accidentally exposed internal resolver.
A practical DNS reference for hardening, logging, DNSSEC, and resolver-related controls is NHIMG’s DNS Security Guide, which covers resolver security alongside related DNS abuse patterns.
Hardening, detection, and recovery
The safest posture is to restrict recursion to approved clients and networks, then add compensating controls such as rate limiting, response policy zones, sinkholing where appropriate, and DNS logging. If recursion must remain broadly reachable for a business reason, the operational burden rises sharply and the resolver must be treated as an externally exposed service with tight monitoring.
Detection should focus on abnormal query volume, unusual client diversity, large bursts of identical lookups, and signs that the resolver is being used as an amplification node. After a change, review logs for misuse that occurred before the fix, because a patched configuration does not erase prior abuse or the possibility of follow-on reconnaissance.
Security operations teams can map this kind of network-exposed abuse to adversary technique tracking through the MITRE ATT&CK Enterprise Matrix, especially where DNS infrastructure is being used for reconnaissance, abuse, or traffic-driven attack paths.
Practitioner guidance for DNS owners
Governance implication: treat recursive DNS as a controlled service, not a default utility. Ownership should be explicit, because the question is less “does it work?” and more “who is allowed to use it, from where, and under what logging and response rules?”
What to watch for: public reachability, overly permissive recursion, and resolver behavior that differs between internal and external clients. Those are usually the signs that a configuration drifted from internal service to exposed infrastructure.
Practitioner takeaway: if a resolver is meant to support only a defined population, verify that the network boundary, access policy, and logging model all enforce that assumption consistently.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1583 — Acquire Infrastructure: Domains | Open resolvers are internet-facing DNS infrastructure used in abuse and reconnaissance patterns. |
| Recommendation — Map observed DNS abuse to infrastructure-related ATT&CK techniques and hunt for unusual query volume or staging. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | Resolver exposure is primarily a configuration and boundary-control problem. |
| DE.CM-01 — Networks and Systems Are Monitored | Detection depends on monitoring resolver traffic for abuse, amplification, and anomalous clients. | |
| Recommendation — Restrict recursive DNS to approved clients and verify exposed services are not publicly reachable. Monitor DNS logs and traffic for abnormal recursion volume, broad client diversity, and amplification patterns. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Open resolvers violate the intended trust boundary around recursive DNS access. |
| AU-2 — Audit Events | Resolver logging is needed to investigate misuse and review post-patch compromise activity. | |
| Recommendation — Enforce boundary controls so recursion is only available to authorised network sources. Log recursive DNS activity so you can review abuse, recon activity, and configuration drift. | ||