Open Resolver

What Makes an Open Resolver Dangerous

An open resolver is risky because it will answer recursive DNS queries from the public internet, not just from trusted clients. That broad reach turns an ordinary naming service into an amplification point: attackers can forge source addresses, send small queries, and cause the resolver to send much larger replies to a victim.

The core issue is not the DNS lookup itself, but the trust boundary around recursion. A resolver that accepts requests from anywhere can be co-opted into reflection attacks, where the server becomes an unwilling participant in denial-of-service traffic. The abuse works best when the resolver is reachable from the internet and has no effective client restriction or rate control.

How Open Resolver Abuse Works

Open resolvers are attractive because DNS responses can be materially larger than the triggering query, especially when the attacker selects record types or names that produce expanded answers. That size difference is what makes amplification possible. The resolver does legitimate work, but it does so on behalf of an unauthorised requester.

This matters operationally because the resolver is not the attacker's target in the usual sense, it is the traffic multiplier. If enough open resolvers are available, the attacker can distribute the load across many systems and make the victim absorb a large volume of spoofed DNS responses from diverse sources.

For defenders, the key concept is the recursive resolver itself, which sits at the edge between client queries and upstream DNS infrastructure. NHI Management Group’s DNS Protocol Fundamentals for Defenders Guide is useful background for understanding how resolution, record types, TTLs, and transport choices shape both normal DNS behaviour and abuse detection.

Exposure, Detection, and Hardening

Exposure is usually straightforward to check: inventory recursive DNS servers, confirm which interfaces listen for recursion, and test whether the resolver answers from untrusted networks. Internet-facing recursive service is the main warning sign, especially if the system also answers large or cacheable responses that can be reused for amplification.

Detection is largely about watching for unusual recursion patterns, high query volume from unfamiliar sources, or outbound DNS responses that do not match expected client populations. Organisations should also inspect firewall and ACL policy, because the safest resolver is one that only serves approved networks and rejects recursion for everything else.

Hardening usually means disabling open recursion, constraining which clients can query recursively, and limiting the resolver's exposure to the public internet. Where broad DNS service is genuinely needed, defenders should pair it with rate limiting and careful network segmentation so the resolver cannot be abused as a public multiplier.

Why Open Resolvers Matter to Internet Resilience

Open resolvers are a shared security problem because they convert a basic infrastructure service into a distributed attack substrate. Even when no internal asset is directly compromised, the organisation still contributes to internet-wide abuse if its resolvers can be driven by anyone on the network.

That makes the term important to both defenders and operators: it is a configuration problem with ecosystem impact. A resolver that is open by default can become part of reflection campaigns, contribute to volumetric denial-of-service traffic, and create avoidable noise for incident responders who must distinguish legitimate DNS load from malicious amplification.

Risk and Threat Considerations

Open resolvers are a classic reflection and amplification risk because the attacker can spoof the source address and make the resolver send replies to a third party. The same behaviour that helps public DNS reachability also gives adversaries a low-friction way to multiply traffic without touching the victim directly.

Failure mechanism: The resolver accepts recursive queries from arbitrary sources, then generates outbound responses at scale for spoofed requests that were never meant for it.

Impact: The resolver can be abused in denial-of-service campaigns, consume excess bandwidth and processing, and expose the organisation to abuse complaints or upstream filtering if the service remains reachable from the internet.

Practitioner Guidance

Why practitioners should care: Treat recursion policy as an access-control decision, not just a DNS tuning choice. If a resolver is intended only for internal clients, make that restriction explicit and verify it regularly rather than assuming the default posture is safe.

What to watch for: Publicly reachable recursive service, unexpected recursion from external networks, and query patterns that suggest the resolver is being used as a traffic amplifier are all signs that the configuration needs review.

Practitioner takeaway: The safest open resolver is one that is no longer open, or one whose recursion boundary is tightly constrained and continuously checked.

Related resources from NHI Mgmt Group

• Open DNS Resolver
• Should organisations adopt open standards for authorization now?
• How should security teams govern device-bound payment credentials in open finance?
• How should banks govern third-party access to open banking APIs?