An open resolver is a DNS server that answers queries from arbitrary sources instead of limiting recursion to approved clients. That behaviour makes the server easy to abuse in reflection attacks because it will generate responses for spoofed requests that were never meant for it.
Expanded Definition
An open resolver is a DNS server configured to accept recursive lookups from any source, not just approved clients. In NHI and infrastructure governance, that matters because recursion is a service capability that can be exposed accidentally, turning a routine DNS component into an internet-facing amplification vector.
Definitions are not heavily contested, but usage in the industry can vary between security teams that mean any publicly reachable recursive DNS server and operators who reserve the term for resolvers that will answer unauthenticated requests from arbitrary networks. The practical distinction is whether recursion is intentionally restricted, as recommended in the NIST Cybersecurity Framework 2.0 and related access control guidance. For NHI security, open resolvers are relevant because they often sit alongside service accounts, automation, and cloud control-plane dependencies that assume trusted network boundaries.
The most common misapplication is treating an internal recursive DNS service as safe simply because it was not meant to be internet-facing, which occurs when firewall scope, ACLs, or cloud security groups are left broad during deployment.
Examples and Use Cases
Implementing DNS recursion rigorously often introduces operational friction, requiring organisations to balance ease of resolution for distributed workloads against the risk of abuse and reflection traffic.
- A cloud VPC allows recursive DNS from all subnets, and a misrouted security group makes the resolver reachable from the public internet.
- A legacy branch-office DNS server is left open during migration, creating a reflection target that attackers can abuse with spoofed source addresses.
- A CI/CD environment depends on a shared resolver for package downloads, but no ACLs restrict who can query it, expanding exposure beyond intended build agents.
- An incident review shows that a DNS appliance was functioning as an open resolver because an approved-client list was never updated after a network redesign, a pattern that aligns with the exposure concerns discussed in Ultimate Guide to NHIs.
- Security teams use recursive DNS logs to confirm whether an internal resolver is serving only trusted clients and to verify that automation identities are not bypassing network policy.
Why It Matters in NHI Security
Open resolvers matter because they transform a supporting identity and network service into an externally reachable control point that can be abused for amplification, reconnaissance, and policy evasion. Once exposed, they can generate traffic on behalf of spoofed requests, which means the DNS layer becomes part of the attack surface rather than a passive utility. This is especially relevant in environments where service accounts, workloads, and automation tools depend on DNS to reach secret managers, APIs, and internal platforms.
NHI Mgmt Group notes that Ultimate Guide to NHIs reports that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation. That same zero-trust logic applies here: DNS services should not be trusted by default merely because they are foundational. Proper segmentation, client allowlists, and monitoring for recursive abuse are governance issues, not just DNS tuning tasks. Organisations typically encounter the operational consequences only after abuse traffic, reflection attacks, or ISP complaints force the resolver exposure to be addressed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-3 | Network access should be restricted to approved clients, which directly addresses open resolvers. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires explicit boundary enforcement instead of implicit trust in DNS services. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Exposed supporting services increase NHI attack surface and weaken secret-bearing workloads. |
Treat resolvers as controlled resources and restrict recursion by identity and network policy.
