Defending DNS services with Radware DefensePro

DNS amplification is a volumetric denial-of-service technique in which a small query triggers a much larger response toward a spoofed destination. Attackers send UDP requests to public recursive resolvers, which return much larger DNS replies to the victim’s IP address.

Using Radware DefensePro to mitigate DNS amplification attacks requires more than a block rule: the appliance can combine traffic inspection, behavioural detection, rate controls, and mitigation policies. The correct design depends on whether the asset is an exposed resolver, an authoritative nameserver, or the downstream target receiving reflected traffic.

For Australian operators, the problem crosses jurisdictions and providers. A .au zone can be attacked from overseas, while a Sydney office may depend on the same recursive service used by Melbourne and Brisbane users.

Effective mitigation therefore combines appliance policy with hardened resolver configuration, upstream coordination, and rehearsed operations. Feature names and thresholds vary across DefensePro releases and licensing, so validation in a lab remains essential.

Understand how reflection reaches the victim

During a reflection attack, the source address in the triggering UDP datagram is forged. The recursive resolver receives a normal-looking question, queries an authoritative server, then sends the amplified response to the forged address. Attackers often request records that generate sizeable replies, while anycast DNS can broaden the pool of usable open resolvers.

The response arrives with the resolver’s real source IP, making simple source blocking indiscriminate. Operators must distinguish valid answers from unsolicited DNS responses while accounting for TCP fallback, truncated UDP replies, DNSSEC records, and clients that legitimately need high-volume lookups.

Map exposure across Australian networks

Australian exposure mapping should begin with owned domains, especially .au namespaces, and every recursive resolver available to staff, partners, or customers. Include hosted authoritative servers, cloud resolvers, branch DNS appliances, and third-party providers; the auDA registry does not remove the risk of global reflection traffic.

Next, map paths through Telstra, Optus, TPG, and regional internet providers, noting primary and secondary links in Sydney, Melbourne, and Brisbane. Because reflection sources are usually international, local filtering alone is insufficient: upstream peers and hosting providers must be able to filter or rate-limit traffic quickly.

Establish a DNS traffic baseline

Create a protected asset for each DNS service IP or prefix and attach it to the correct DefensePro policy rather than applying a global rule. Record peak queries per second, response bandwidth, amplification ratios, concurrent clients, popular zones, and the UDP-to-TCP fallback rate. Baselines should separate interactive users from batch, backup, and security-scanner workloads.

Use passive packet capture and resolver logs to establish normal response sizes and unusual query types. Monitor NXDOMAIN surges, malformed labels, EDNS options, and requests for uncommon record types, but treat each as a signal rather than proof. Resolver operators should limit unnecessary open resolution; hosting networks can apply ingress anti-spoofing, while edge ACLs can suppress traffic toward confirmed victim prefixes during an incident.

Apply DefensePro policies at the edge

Enable the network behavioural protection and DoSShield capabilities available in the licensed release, then apply them specifically to DNS traffic on UDP and TCP port 53. Start with a narrow scope and thresholds above measured peaks, then stage escalation. Analyse events in the DefensePro reporting interface before tightening packet-rate ceilings, drop actions, or source-based policies.

Rate limits can combine source address, subnet, ASN, geography, zone, and response characteristics, but dynamic residential clients in Australia can trigger false positives. Preserve TCP/53 for oversized answers and allow known monitoring and backup clients where necessary. Where the hosting provider can validate client addresses, ingress anti-spoofing blocks requests with forged sources. Nameservers under direct control should also use response rate limiting.

For prefixes announced upstream, a pre-approved BGP filtering action can provide rapid containment, with a narrower policy used during restoration.

Automate repeatable mitigation workflows

Changes should be reproducible and reviewable. Teams already combining application delivery with infrastructure as code can adapt the Grails Terraform workflow to manage approved DNS assets, policy objects, and audit metadata, while keeping appliance-specific credentials outside source control.

Treat mitigation changes as controlled automation: fetch a signed configuration, update only named objects, validate appliance health, and retain a rollback snapshot. API calls should be rate-limited and auditable, and automated escalation must stop when legitimate DNS error rates rise.

Test the protection without disrupting service

Validate in an isolated lab using authorised traffic and reserved address space, never by directing test traffic at third-party resolvers. Compare normal A and AAAA lookups with high-volume UDP requests, malformed packets, DNSSEC validation, and TCP fallback. Record whether DefensePro identifies amplification and whether mitigation completes without blocking legitimate answers.

A resilience test should include failover for supporting infrastructure and operator access. For organisations using AWS across regions, the cross-region AWS replication guide can inform the design of those components in a staged test; DNS authority and resolver routing must still be designed globally. Exercise manual override, restoration, and representative paths from Sydney to Melbourne.

Run, measure, and coordinate the response

Monitor mitigation state, packets dropped by policy, response volume, resolver CPU, cache-hit rate, false positives, and time to recover. Keep the baseline under change control and revisit thresholds after major migrations, new .au services, or traffic-pattern changes. Logs should map cleanly to the relevant asset, rule, and change ticket.

When an incident affects an Australian organisation, coordinate with the internet service provider and relevant upstream network, then use ACSC reporting channels and the Joint Cyber Security Centre for significant incidents. Maintain contacts across Australian Eastern and Central Time zones, because reflected traffic can continue while business activity moves across the country.