Should organisations prioritise resolver hardening or DDoS scrubbing first?

Why resolver hardening belongs before mitigation capacity

Resolver hardening is the upstream control because it reduces the opportunity for abuse at the source. If open recursion, permissive response behavior, or weak source filtering remain in place, the resolver can be turned into a high-volume amplifier regardless of how much scrubbing capacity sits downstream. That makes hardening a prevention problem, not just a cleanup problem.

For this reason, organisations should think in terms of attack surface reduction first and traffic absorption second. A hardened resolver lowers the amount of spoofable or reflexive traffic available to an attacker, which improves the effectiveness of every later control, including mitigation services and network rate limits.

Resolver hardening is also easier to validate than many mitigation claims because it can be tested directly against protocol behavior, recursion policy, response size, and access restrictions. If those fundamentals are weak, DDoS scrubbing will often still be useful, but it will be compensating for a control gap that should not have existed.

How DDoS scrubbing fits as a compensating control

DDoS scrubbing remains valuable when abuse is already under way or when traffic volume exceeds what an organisation can absorb locally. Its job is to detect, absorb, and filter floods before they reach the resolver or the wider service boundary. In practice, it is the second line of defense, not the first decision point.

The most durable posture combines upstream hardening with downstream mitigation. Source filtering, response limits, and tight recursion settings reduce the attacker's leverage, while scrubbing helps preserve availability when an attack still gets traction. CISA Secure by Design is a useful reminder that secure defaults should reduce abuse before compensating controls have to absorb it.

This layered approach matters because scrubbing is not a substitute for protocol hygiene. If the resolver still behaves as an open amplifier, the mitigation team is forced to spend capacity on traffic that could have been prevented upstream.

What practitioners should optimise first

The ordering question is really about where you get the biggest risk reduction per change. Hardening usually delivers the first measurable improvement because it shrinks both the attack surface and the size of the response an attacker can induce. Scrubbing then becomes the resilience layer for overflow, regional spikes, and attacks that bypass the first line of defense.

Useful hardening controls include disabling open recursion where it is not needed, restricting who can query recursively, limiting oversized responses, and removing unnecessary amplification behavior. CIS Benchmarks are relevant here because they translate hardening into concrete configuration baselines, while ENISA Threat Landscape helps place DDoS amplification in the broader pattern of recurring Internet-scale abuse.

Where scrubbing is already contracted, the key question is whether it is being used to cover a known weakness or to handle peak abuse after the resolver has already been made difficult to exploit. The latter is the healthier model. The former usually means the organisation has bought mitigation before it has reduced the thing being mitigated.

Risk and Threat Considerations

Resolvers that are easy to abuse create two forms of exposure: they amplify traffic for an attacker and they consume defensive resources more quickly than expected. The result is not just service degradation for the resolver itself, but broader collateral pressure on upstream bandwidth, logging, and incident response capacity.

Failure mechanism: Open recursion, permissive response handling, or inadequate source controls let hostile traffic be generated from a small trigger set, which makes downstream scrubbing work against a larger and more persistent flood.

Impact: Availability degrades faster, mitigation costs rise, and the organisation may misread the problem as a pure volumetric event when the real issue is a preventable configuration weakness.

Practitioner Guidance

Decision rule: If the resolver can still be abused to generate amplified traffic, harden it before relying on scrubber capacity. Treat scrubbing as the resilience layer for residual risk, not as the primary fix for a weak resolver.

What to verify: Confirm recursion scope, response limits, source restrictions, and default configuration behavior in the exact resolver stack you operate. If you cannot demonstrate those settings under test, do not assume the resolver is hardened enough to deprioritise it.

What good looks like: The resolver should be difficult to abuse, the expected query patterns should be bounded, and mitigation should be sized for exceptional events rather than for everyday design weakness.

Practitioner takeaway: Prioritise the control that reduces the attacker's leverage first, because every byte prevented upstream is cheaper and more reliable than a byte absorbed later.

Related resources from NHI Mgmt Group

• What should organisations prioritise first: takeover response or inbox hardening?
• Should organisations prioritise supplier access review or perimeter hardening first?
• Should organisations prioritise patching or identity hardening first after active exploitation is detected?
• Should organisations prioritise perimeter hardening or mobile controls first?