If DNS resolvers and proxy servers are left open to the internet, they can become amplifiers or relay points for attacker traffic. That widens the attack surface and makes it easier for bot operators to distribute requests at scale. Properly restricting these services to internal users and authorized clients removes a major enabler of the attack path.
Why Open DNS Resolvers and Proxy Servers Worsen a DDoS Event
Open resolvers and proxy servers are attractive during a DDoS campaign because they let an attacker turn unrelated infrastructure into traffic infrastructure. The defender is no longer dealing only with the botnet’s source volume, but also with amplification and relay capacity that can multiply request rates and obscure origin. That makes filtering, attribution, and rate limiting materially harder.
When those services are exposed to the internet, they can be abused in two ways. A DNS resolver may answer recursive queries from arbitrary clients and help amplify traffic, while an open proxy can forward attacker traffic through a seemingly legitimate intermediary. In both cases, the service becomes part of the attack path instead of a boundary that constrains it.
What Changes Operationally When Access Is Restricted
Restricting DNS resolvers and proxy servers to internal users and authorized clients removes the open invitation that makes them useful for abuse. The practical effect is narrower reachability, less unauthorised recursion or forwarding, and a smaller pool of infrastructure that can be conscripted into the attack. That usually reduces both the scale of the event and the number of places defenders must filter.
This is not only about shutting the service down. In many environments, the control point is allowlisting, network segmentation, or explicit client authentication so the service can still function for legitimate use while refusing arbitrary internet traffic. The important distinction is whether the service is behaving as a protected dependency or as a public relay.
Why This Matters to Detection, Attribution, and Containment
During DDoS response, open resolvers and proxies blur the picture of where traffic is coming from and what the attacker is using. That can delay mitigation because defenders must first distinguish source traffic from reflected or relayed traffic, then decide which upstream partners, IP ranges, or service endpoints need filtering. When the service is restricted, the attack surface is easier to enumerate and the containment decisions are less ambiguous.
The broader lesson is that any internet-facing component with forwarding or recursion behaviour should be treated as a potential force multiplier. If it is not intended to serve the public, it should not be reachable by the public. If it must remain reachable, it needs tight scope, logging, and a clear approval boundary for who may use it.
Risk and Threat Considerations
Open DNS resolvers and proxy servers can convert ordinary infrastructure into an abuse multiplier, which increases both the scale of the traffic flood and the defender’s response burden. The same exposure can also create collateral risk, because a legitimately running service may become associated with malicious traffic and trigger upstream blocks or reputation damage.
Failure mechanism: The service accepts recursive queries or relays traffic from unauthorised internet clients, letting attackers hide origin, distribute load, and increase request volume without controlling every source directly.
Impact: The organisation faces higher bandwidth pressure, slower mitigation, more difficult attribution, and a greater chance that its own infrastructure is used to harm others.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Restricts who can use exposed services and attack-enabling access paths. |
| PR.PS-01 — Configuration Management | Covers secure service configuration that prevents public recursion or relay abuse. | |
| DE.CM-01 — Networks and Network Services Monitored to Detect Potential Cybersecurity Events | Supports monitoring for anomalous resolver or proxy traffic during DDoS activity. | |
| Recommendation — Restrict resolver and proxy access to approved clients and networks. Harden DNS and proxy settings to block unauthorised public use. Monitor resolver and proxy traffic for abuse patterns and surge anomalies. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Directly addresses restricting exposed network services and related abuse paths. |
| CIS-13 — Network Monitoring and Defense | Supports detection and containment of abnormal relay or amplification traffic. | |
| Recommendation — Limit internet exposure of DNS resolvers and proxies to approved use cases. Watch for reflector, relay, and flood traffic patterns tied to exposed services. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Applies to limiting external access to resolvers and proxies at the network boundary. |
| CM-7 — Least Functionality | Supports disabling recursive or forwarding functions not required for the environment. | |
| AU-6 — Audit Review, Analysis, and Reporting | Relevant for investigating abuse of exposed resolvers or proxies. | |
| Recommendation — Enforce boundary controls that prevent unauthorised internet access. Disable public recursion and relay features unless explicitly required. Review logs to identify misuse of DNS or proxy services during attack periods. | ||
| MITRE ATT&CK | T1090 — Proxy | Covers proxy infrastructure used to relay malicious traffic through intermediaries. |
| T1090.002 — External Proxy | Maps directly to internet-exposed proxy servers used as relay points. | |
| Recommendation — Hunt for proxy abuse when traffic is being relayed through exposed servers. Block and investigate externally reachable proxy relays used in the attack path. | ||
Practitioner Guidance
What to verify: Confirm that recursion, forwarding, and proxying are limited to approved client ranges and that any public exposure is intentional, documented, and monitored. If the service can answer or relay for arbitrary internet hosts, treat that as a DDoS facilitation issue, not just a configuration preference.
Decision rule: If the server is needed only for internal or partner use, make the default posture non-public and require explicit exception approval for any internet-facing access. If public reachability is unavoidable, constrain it with strict allowlists, logging, and response thresholds so abuse is visible early.
Practitioner takeaway: The key question is not whether the resolver or proxy is “working”, but whether it is working only for the clients it was meant to serve. Public reachability turns a support service into an attack multiplier.
