A Wide-Open DNS Forwarder ACL Lets Any Client Recurse Through Your Resolver

Symptom

The resolver answers recursive queries correctly for every internal client, and no error appears in the logs. The trap is that the same resolver also answers recursive queries from clients outside the intended trust boundary, including addresses that should never have been granted recursion. Operators only notice this when an external scan or a security audit reports that the resolver is ‘open’ to arbitrary recursive lookups, or when unusual query volume for unrelated domains appears in query logs.

False Assumption

The operator assumes that because the resolver was deployed inside a private subnet with a security group or firewall permitting only expected ports, the DNS service itself must also be restricting who can issue recursive queries. In practice, the allow-recursion (or equivalent) directive controls this independently of network-layer filtering, and many default configurations set this directive to any or leave it unset, which falls back to an open default. Network reachability and query-processing authorisation are two separate controls, and only one of them being correct creates a false sense of safety.

Root Cause

The root cause is a configuration default that treats recursion as globally permitted unless explicitly narrowed. In BIND-family resolvers this is the allow-recursion statement inside the options block; in other resolver implementations it is an equivalent recursion-scope ACL. When this directive is absent, commented out, or explicitly set to any, the resolver will perform recursive resolution on behalf of any client that can reach it on UDP/TCP 53, regardless of any perimeter firewall. Because the resolver still answers internal clients exactly as expected, the misconfiguration produces no functional symptom for the team that depends on it, which is why it persists silently until an external party notices.

Impact

An open recursive resolver becomes a reflection and amplification vector for DNS-based denial-of-service attacks against third parties, and it exposes internal query patterns, subdomains and infrastructure naming conventions to anyone able to query it. It also increases the resolver’s exposure to cache poisoning attempts, since a wider set of untrusted clients can trigger recursive lookups that populate the cache. The organisation may be listed by open-resolver scanning services, which can trigger abuse complaints from upstream providers, and in regulated environments this misconfiguration can represent a failed control against network segmentation and least-privilege expectations described in general cloud security benchmark guidance covering identity, networking and governance controls.

Diagnosis

Confirm the exposure using read-only checks before making any change. First inspect the live configuration for the recursion-control directive and its current scope; do not assume the file on disk matches the running configuration if the service has not been reloaded since the last edit. Second, test recursion behaviour by querying the resolver from a network location outside the intended trust boundary, using a domain not already cached, and observing whether an authoritative recursive answer is returned or refused. Third, review query logs, if logging is enabled, for source addresses outside the expected internal ranges. These three checks together establish whether the exposure is configuration-only, already actively exploited, or already appropriately restricted.

• Check the running configuration’s recursion-control directive and compare it against the file on disk.
• Query the resolver from outside the intended trust boundary for an uncached name and observe whether recursion occurs.
• Review available query logs for source addresses outside expected internal ranges.

Correction

The correction is to explicitly scope the recursion-control directive to only the address ranges that should be permitted to recurse through this resolver, rather than relying on an implicit or wildcard default. This must be a deliberate, reviewed change to a named ACL, applied and reloaded in a controlled maintenance window, with the change validated immediately afterwards against both permitted and denied source ranges. The correction should be applied first in an isolated or non-production instance with an equivalent configuration, confirmed there, and only then promoted to the production resolver under change control.

Validation

Validation confirms that permitted internal clients retain recursive resolution while all other sources are refused. After applying the scoped ACL and reloading the service, repeat the outside-boundary recursive query test from diagnosis and confirm the resolver now returns a refused or non-recursive response rather than resolving the query. Simultaneously confirm from a permitted internal client that ordinary recursive resolution for external and internal names continues to function without delay or failure. Both checks must pass together; a configuration that blocks external recursion but also blocks legitimate internal recursion is not a successful correction and requires immediate rollback.

Rollback

Rollback restores the resolver’s prior configuration file and service state if the scoped ACL breaks legitimate internal resolution or if the reload fails. Because the change is a targeted edit to a single directive, keep a verified backup copy of the configuration file taken immediately before the edit, and restore that exact file, then reload the service, if any permitted internal client loses expected resolution. Rollback should be exercised as a rehearsed step in the isolated validation environment before the change is ever applied to production, so the rollback path is proven rather than assumed.

Prevention

Prevent recurrence by treating the recursion-control ACL as a reviewed, version-controlled configuration item rather than a default left to inherit from installation, and by adding it to routine configuration audits alongside network-layer firewall rules, since the two controls address different layers and neither substitutes for the other. Periodically re-run the outside-boundary recursive query test as a scheduled, non-destructive check, and treat any unexpected recursive response from an unscoped source as an immediate finding requiring the same corrective workflow described above.