A recursive DNS resolver looks up DNS records for its clients. If it answers UDP queries sent with forged source addresses, it can send much larger responses to an attack victim. For a resolver intended for a private network, restricting recursion to authorized clients is the first step in preventing this abuse. Rate limits and monitoring help control traffic, but they do not establish who is allowed to use the resolver.

Start by deciding which clients may use recursion and which server addresses should accept their queries. Enforce that decision in the DNS configuration and network rules, then check that approved clients still receive answers and other clients do not.

Identify the Resolver's Exposure

Start with an inventory of every process that can answer DNS on UDP or TCP port 53, including embedded resolvers in routers, container services, virtual appliances, and cloud instances. Record their listening addresses, public and private interfaces, firewall paths, forwarding relationships, and whether each process is intended to be recursive, authoritative, or both.

An open resolver answers recursive queries from clients across the public internet. That access is inappropriate for a resolver meant only for your own users. A private resolver can become exposed through a permissive DNS access list, a broad cloud security rule, port forwarding, an unexpected IPv6 path, or a split-view rule that matches more clients than intended. Checking only IPv4 or only the host firewall leaves gaps.

Disable recursion on servers that do not need it, and separate recursive and authoritative services where practical. A public authoritative server needs to answer for the zones it hosts, but that role does not require offering recursive lookups to arbitrary internet clients. Separate instances or addresses make these different access policies easier to enforce.

Review the configuration, listening sockets, and firewall rules, then make a small number of ordinary DNS queries from test hosts you control inside and outside the allowed networks. Use names outside the server's authoritative zones and check whether the responses show that the requested lookup was allowed or refused. The Recursion Available flag alone does not prove that a particular client is allowed to use recursion. Do not generate high-volume or spoofed traffic for the test.

Limit Recursion to Authorized Clients

Allow only the clients that need your recursive service. The allowed group may include internal address prefixes protected from source spoofing, loopback clients, specific VPN address pools, or authenticated forwarding resolvers. Avoid broad allow rules added solely for convenience, and review dynamic cloud and remote-access ranges when they change.

In BIND 9, allow-recursion identifies clients permitted to use recursion, while allow-query-cache controls access to cached answers. The general allow-query setting can also restrict queries, so check how these settings interact in the active view. To restrict which local server addresses accept recursive requests, use allow-recursion-on; permission for both the client and the local address must allow the request.

For example, the following BIND configuration limits recursion and cache access to two example client networks:

acl "authorized-clients" {
    192.0.2.0/24;
    2001:db8:100::/48;
};

options {
    recursion yes;
    allow-recursion { authorized-clients; };
    allow-query-cache { authorized-clients; };
};

These prefixes are documentation ranges, so replace them with the networks that should actually use your resolver. Validate the configuration against your installed BIND version before loading it. On an authoritative-only view or server, use recursion no; and confirm that the effective configuration also denies client access to the cache.

For a private resolver, also restrict inbound DNS traffic at the network edge, with matching IPv4 and IPv6 rules. If an address also serves public authoritative DNS, make sure the firewall still permits queries for that service; the DNS software must enforce the separate recursion policy. Restrict management, dynamic update, and zone-transfer permissions separately, since permission to query recursively should not grant access to those operations.

Prevent Forged Source Addresses

DNS amplification relies on a server replying to the source address shown in a request. BCP 38 ingress filtering checks whether that source address is valid for the network from which the packet arrived and rejects packets that fail the check. Applying this filtering across networks helps stop forged requests before they reach a resolver.

Apply source-address checks at network boundaries you control, and ask your upstream network provider what anti-spoofing controls are in place. A network with multiple connections may receive legitimate traffic along asymmetric paths, so its filtering policy must account for those routes. A simple check against a single return path can otherwise reject valid traffic.

With DNS Cookies, a supporting client can return a token that the server previously sent to its address. A valid token helps the server identify requests from clients that could receive its earlier response, reducing some abuse by attackers who cannot observe that traffic. Cookies do not replace client authorization or source-address filtering, and clients without valid cookies still need appropriate access and traffic controls.

Apply Rate Controls Carefully

Traffic limits reduce the impact of abusive bursts and help protect resolver capacity after access restrictions are in place. Depending on the resolver, you may be able to limit queries per client, concurrent recursive lookups, upstream requests, response sizes, or open connections. Choose controls that match the resolver software and the clients it serves.

Set thresholds using measurements of normal authorized traffic. Shared NAT addresses, busy forwarding resolvers, mail systems, and application clusters can produce legitimate bursts that appear to come from one busy client. Limits that ignore those patterns can cause intermittent lookup failures. Where supported, start in an observation or log-only mode, and decide how to undo the change if legitimate queries fail.

BIND's rate-limit response rate limiting is mainly intended for authoritative servers. Applying it to a recursive resolver can slow applications that repeatedly request the same domains. If recursion is unintentionally open, close that access instead of relying on an authoritative server's rate-limit settings.

For an authoritative service, response rate limiting can treat repeated answers, errors, empty answers, nonexistent names, and referrals separately. BIND can drop replies or send selected small responses marked as truncated, allowing supporting clients to retry over TCP. Its log-only option records what the limiter would do without actually dropping or truncating responses. Choose values from observed traffic and the options supported by your installed version.

Monitor Authorized Resolver Traffic

Collect query and response rates by interface, transport, client prefix, response code, query type, response size, and recursion outcome. Track cache hit behavior, upstream fetches, concurrent recursion, TCP fallback, denied requests, dropped responses, and server resource use. Preserve privacy by limiting retention and access to query data according to policy.

Watch for requests from networks that should not have access, a sudden rise in large UDP responses, repeated ANY or DNSSEC-related queries, and unusually high outbound response traffic. Frequent nonexistent-name responses or sustained traffic toward a small destination range can also warrant investigation. No single pattern proves abuse, so compare unusual traffic with application releases, authorized security scans, and known client changes.

Alert on policy failures as well as volume. A low-rate open resolver can remain exploitable without crossing a bandwidth threshold. Periodically verify that an unauthorized test client receives no recursive service, while approved clients can resolve required names over UDP and TCP and through encrypted transports where deployed.

Stop Abuse without Disrupting DNS

If an unintended open resolver is found, restrict recursion first. Confirm that authoritative service, if co-located, remains available for the zones it must serve. Review firewall and cloud rules, then check whether stale instances, secondary interfaces, or IPv6 listeners expose the old policy.

During active abuse, coordinate with network and hosting providers for filtering and traffic evidence. Rate limits can reduce immediate load, but the access-control correction should remain the primary resolver change. Preserve timestamps, source and destination aggregates, effective configuration, software version, and before-and-after counters without retaining unnecessary query content.

After changing the policy, test from every authorized client group and from at least one host you control outside the allowed networks. Check that permitted clients can use recursion, cached answers, forwarding, DNSSEC validation, TCP fallback, and any encrypted DNS service you provide, while outside clients cannot use the private recursive service. Watch latency and failure rates for signs of an overly tight limit or a missing client prefix.

Before a production change, save the current configuration and plan how to restore it if necessary. Use the platform's supported validation and reload procedure, then confirm that the running resolver is enforcing the new policy. A corrected file on disk does not protect the service until the active configuration has changed.