Open Recursion

Expanded Definition

Open recursion is a DNS resolver configuration issue, not a DNS protocol flaw. It appears when a recursive resolver answers queries from any internet source instead of limiting recursion to approved clients, networks, or authenticated users. In practice, that means the resolver can be used by outside parties to perform lookups and, in abuse scenarios, to support amplification and reflection attacks. Within cybersecurity operations, the term describes an exposure that sits at the boundary between service availability, network trust, and configuration governance. NIST guidance on access control and system hardening, including NIST SP 800-53 Rev 5 Security and Privacy Controls, is relevant because the issue is fundamentally about restricting who can use a service and under what conditions.

Definitions are broadly consistent across the industry, but operational detail varies: some teams treat any publicly reachable recursive service as open recursion, while others reserve the term for resolvers that permit recursion without meaningful client restriction. The distinction matters because a resolver can be publicly reachable for authoritative queries and still be safely configured, so reachability alone is not the same as exposure. Open recursion is commonly confused with authoritative DNS exposure, or with DNS forwarding arrangements that are intended and controlled. The most common misapplication is labelling any internet-facing DNS server as open recursion, which occurs when operators fail to verify whether recursion is actually enabled for untrusted clients.

Examples and Use Cases

Implementing recursive DNS safely often introduces administrative friction, requiring organisations to balance resolver convenience for legitimate users against the security cost of accepting queries from the public internet. Authoritative guidance from sources such as IETF RFC 1034 helps separate recursive resolution behaviour from authoritative name service, while operational control expectations are reinforced in CISA DNS security guidance.

• An enterprise resolver serves internal users only, with recursion restricted to corporate subnets or VPN ranges.
• A cloud-hosted DNS service is audited and found to accept recursive queries from any IP address, creating a potential reflection vector.
• A branch office forwards queries to a central recursive resolver, but firewall rules prevent outside clients from reaching the service.
• A managed service provider operates shared resolvers and uses source restrictions plus rate limiting to prevent abuse by unauthorised networks.
• A security team discovers that a legacy resolver was left in a permissive state after migration, making it a candidate for abuse in volumetric attacks.

Why It Matters for Security Teams

Open recursion matters because it turns a routine infrastructure component into an externally reachable resource that can be abused at scale. When teams fail to control recursion, they increase the risk of DNS amplification, create unnecessary service load, and weaken confidence in network boundary enforcement. From a governance perspective, the issue is not just availability but accountability: someone must own the resolver configuration, verify who is allowed to query it, and ensure the setting is reviewed after change events, migrations, or vendor handoffs. In identity and access terms, the concept is analogous to granting network-level privilege without scoping or review. It is also relevant to incident response because DNS abuse often emerges alongside broader reconnaissance or DDoS activity. The operational lesson aligns with the control intent of NIST SP 800-53 Rev 5 Security and Privacy Controls and DNS best-practice guidance from IETF RFC 8482 where limiting unnecessary exposure is part of resilient service design. Organisations typically encounter the consequences only after an abuse complaint, traffic spike, or upstream filtering event, at which point open recursion becomes operationally unavoidable to fix.

Related resources from NHI Mgmt Group

• What breaks when DNS resolvers are open to recursion from any source?
• 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?