DNS Security & Hardening — BIND, DNSdist & Volumetric DDoS Resilience

ITORO does not sell generic “DNS DDoS protection.” What we deliver is concrete: hardening for recursive DNS resolvers using a DNSdist security front-end, integrated with BGP FlowSpec and WanGuard at the network edge. That means blocking malware, phishing, gambling and other unsafe domains, rate-limiting or null-routing abusive resolvers and clients, and dropping volumetric UDP/53 floods — with honesty about which layer stops which attack.

Recursive versus authoritative — know which one you run

The right defence depends on what your servers actually do. A recursive resolver answers queries on behalf of your users and looks answers up across the internet; it is exposed to client-side abuse, cache-poisoning attempts and being used as a reflection amplifier. An authoritative server publishes your own zones to the world and is a target for query floods against the names you host. The two face different threats and take different hardening. ITORO’s DNSdist work focuses on the recursive edge — the resolver your subscribers or internal users point at — and on keeping it fast, filtered and hard to abuse.

DNSdist as the security front-end

DNSdist sits in front of your resolver backends and gives you a control point that raw BIND or Unbound does not expose on its own:

• Response Rate Limiting (RRL) and per-client / per-network query limits, so a single abusive source cannot exhaust the resolver.
• Dynamic blocking of sources that cross behavioural thresholds — the classic signature of NXDOMAIN and random-subdomain “water-torture” floods.
• Protective DNS filtering: blocking known malware, phishing, command-and-control, gambling and other unsafe domains using threat feeds (URLhaus, ThreatFox, CERT.pl and similar), returning a safe answer instead of resolving them.
• Load-balancing and caching across backends to blunt query spikes and keep good traffic served.
• Encrypted DNS — DoT, DoH and DoQ — terminated at the front-end with automated certificates.

The point of RRL and dynamic blocking is precise: they protect the resolver from being overwhelmed and from being abused as an amplifier. They shape and drop queries in software, at the application layer, where the query name is actually visible.

Where WanGuard and BGP FlowSpec fit

DNSdist reasons about DNS. It cannot help you when the problem is raw packet volume. A large amplification or reflection flood on UDP/53 can saturate your uplinks before a single query is ever parsed — and here the tools change. WanGuard detects the volumetric anomaly from NetFlow/sFlow/IPFIX and drops it with BGP FlowSpec or, at the limit, RTBH at the router edge, before the flood reaches the resolver. FlowSpec can rate-limit or discard UDP/53 traffic by source, destination, port and packet length — a blunt but effective L3/L4 filter. This is the volumetric layer; DNSdist is the application layer; you need both.

Anycast for capacity and blast radius

Fronting recursive resolvers with Anycast spreads query load across multiple nodes advertising the same address. Under a flood the attack traffic is distributed rather than concentrated on one box, and a node taken out of service fails over without changing the resolver IP your clients use. Anycast is not mitigation by itself — the packets still arrive somewhere — but it raises the volume you can absorb and shrinks the blast radius of any single event.

Honest scope — what these tools cannot do

• BGP FlowSpec expresses only L3/L4 match criteria. It cannot inspect a DNS query name — it does not know “malware.example” from a legitimate lookup. Name-based filtering happens in DNSdist, not FlowSpec.
• RRL protects your resolver, but the flood still arrives on the wire. It stops your server melting down; it does not un-send the packets. Uplink saturation is a WanGuard/upstream problem.
• Terabit-scale volumetric events exceed any on-net capacity and require upstream scrubbing. We tell you where that line is for your network rather than pretend a single box clears it.

NIS2 alignment

DNS is named critical infrastructure under NIS2. The DNSdist hardening, protective filtering, logging and retention, encrypted transport and monitoring we deploy map directly onto the Article 21(2) technical measures, and we provide a country-specific compliance checklist plus incident-reporting integration to national CSIRTs.

Frequently asked questions

Do you offer “DNS DDoS protection” as a product?

Not as a black box. We harden your recursive resolvers with DNSdist and integrate BGP FlowSpec and WanGuard at the edge. We are specific about what filters where instead of selling a cure-all appliance.

What is the difference between RRL and BGP FlowSpec here?

RRL works inside DNSdist at the application layer and can act on query behaviour and names; BGP FlowSpec works at L3/L4 on the router and drops packets by address, port and protocol. One protects the resolver’s logic, the other protects the uplink.

Can DNSdist block phishing and gambling domains for our users?

Yes. As a protective-DNS front-end it can refuse known malware, phishing, C2, gambling and other unsafe domains from threat feeds, returning a safe response instead of resolving them.

What about the very largest UDP/53 floods?

WanGuard detects and filters them with FlowSpec or RTBH at the edge; beyond your uplink capacity they must be scrubbed upstream. We design the escalation and tell you where the limit is.