DNS Flood Attacks Jumped 519%: What It Means for Your Site

If your site went down and you never touched anything, a DNS flood is now a genuine suspect. Cloudflare's H1 2026 threat report puts hyper-volumetric DDoS attacks up 519% year on year, and a big chunk of that comes from DNS reflection - attackers bouncing traffic off open resolvers to bury a target in junk requests.

Here's the part nobody says out loud: you don't need to be a bank to get hit. Most of these attacks are automated, indiscriminate, and cheap to launch. Your little shop or portfolio can end up as collateral or a random target on a botnet's list.

The good news is that the defences that matter for a small site are not expensive and mostly come down to where your DNS lives and who answers your queries. Let's get into what's actually happening and what you can do this afternoon.

Why DNS flood attacks hit small sites hardest

Small sites get hurt more because DNS is a single choke point that most owners never harden. If your domain's name servers fall over, your site is gone even when your web server is perfectly healthy - visitors can't resolve your address in the first place.

DNS reflection works by abusing the size difference between a request and a response. An attacker sends a tiny query to thousands of open resolvers, spoofing your server's address as the sender. Every resolver dutifully fires a much larger answer back at you. A few bytes out, kilobytes in, multiplied across a botnet - that amplification is why volumes have exploded.

A large provider absorbs that in filtering capacity you'll never see. A small setup on a single budget name server has none of that headroom. The attack doesn't have to be clever; it just has to be bigger than your pipe, and for a hyper-volumetric flood that bar is low.

And there's a twist most guides skip: your own server can be part of the problem. If you run your own resolver and it answers recursive queries for anyone, you're an open reflector - a tool attackers use against other targets, and a magnet for abuse complaints. Check it in ten seconds from an outside network with dig +short test.openresolver.com TXT @your-server-ip. If you get an answer back, your resolver is answering strangers. The fix is to restrict recursion to your own networks (allow-recursion in BIND, or bind the resolver to localhost only) and never expose port 53 to the world unless you're an authoritative name server that has to be.

How to tell a DDoS from a normal traffic spike

A DDoS looks like traffic with no story behind it - sudden, flat, and pointed at the wrong things. A real spike has a source you can trace: a newsletter went out, a post got shared, a product launched. If nothing on your side changed and the graph still jumped a wall, be suspicious.

Dig into your logs and access records. Here's what usually separates an attack from a good day:

• No referrer story. Legitimate spikes come from somewhere - social, search, an email link. Attack traffic often has blank or garbage referrers.
• Requests hammering one endpoint - often /, /wp-login.php, or a search URL - thousands of times a second, ignoring your images and CSS.
• Weird geography and user agents. A sudden flood from countries you don't serve, or a single odd user-agent string repeated endlessly.
• Bounce rate near 100% with near-zero time on page. Real people load more than one file.
• Source concentration in a handful of ASNs. Pull the top client IPs from your access log and look up their networks (whois or a bulk ASN lookup). Real audiences scatter across dozens of consumer ISPs. If most of your "traffic" resolves to two or three hosting/cloud ASNs you've never marketed to, that's a botnet, not a launch day.
• Server resource graphs pinned while actual conversions or logins stay flat.

For a pure DNS flood you may see something different: the web server looks bored, but visitors report the site is unreachable. That's the tell - if your origin is idle and people still can't reach you, the problem is upstream at the DNS layer. Run dig yourdomain.com @your-nameserver from a clean network; if queries time out or come back slow, your DNS is under pressure.

Read the dig response like a doctor's chart. On a healthy day you'll get a status: NOERROR, an ANSWER SECTION with your record, and a Query time under about 50 ms. Under a flood the same command drags to hundreds of milliseconds, throws ;; connection timed out; no servers could be reached on some runs and succeeds on others, or comes back with status: SERVFAIL. That flicker - fine, fine, timeout, fine - is the signature of a name server that's up but drowning. Loop it with while true; do dig +stats yourdomain.com @ns1.yourprovider.com | grep 'Query time'; sleep 2; done and watch the numbers climb.

Keep a screenshot of a normal traffic day somewhere. When something looks wrong at 2am, having a baseline turns a panic into a five-minute comparison.

The protection layers that actually help an SMB

The single most effective move for a small site is putting a network with real filtering capacity in front of your DNS and your origin - and you can do most of it for free. You don't need to buy a mitigation appliance; you need to stop being the thing that answers a flood directly.

Here's the order I'd tackle it in, cheapest and highest-impact first:

Anycast DNS matters most here. Instead of one name server sitting at one address, anycast advertises the same address from dozens of locations, so a flood gets split and swallowed across the whole network rather than crushing a single box. If your registrar or host offers managed anycast DNS, use it and stop running your own single-node resolver.

Then hide your origin. Once a CDN or proxy sits in front, your real server IP shouldn't appear anywhere public - not in old DNS records, not in email headers, not in an SPF record pointing at the same box. Attackers scan for exactly that to route around your protection.

Locking down your origin so the attack can't sneak past

Putting a proxy in front does nothing if attackers can still reach your server directly, so lock the front door once the proxy is up. This is the step people skip, and it's why some "protected" sites still fall over.

Concrete steps once your CDN is live:

• Firewall your origin to the proxy's IP ranges only. With ufw: allow ports 80/443 from your CDN's published ranges and deny the rest. Attackers hitting your raw IP then get nothing.
• Rotate your server IP if it was ever public. Old A records and cached scans linger for months.
• Rate limit at the web server too. In nginx, add limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s; in the http block - a 10 MB zone tracks roughly 160,000 addresses. Then guard the sensitive routes with limit_req zone=login burst=10 nodelay; inside location = /wp-login.php and your search handler. That lets a real person through a short burst while a flood gets 503'd. Keep static assets out of the zone so you don't throttle genuine page loads.
• Cache aggressively. A page served from cache costs almost nothing; a flood against a cached page barely registers. Dynamic pages that hit the database on every request are what fall first.

None of this needs a big budget. It needs an afternoon and the discipline to actually close the ports you opened during testing.

Where TPC Hosting fits

You don't have to figure out DNS resilience alone, and you shouldn't be reading nginx docs at 2am while your site is down. When something looks like an attack, you get real engineers on support 24/7 - people who can read your logs with you, tell a flood from a Reddit hug, and set up rate limiting or firewall rules so you're not doing it solo at the worst possible hour.

Our sites also run in EU data centres and are GDPR-friendly by default, so your DNS and your visitor data stay inside the same legal footprint - no scrambling to work out where your traffic is being handled while you're already putting out a fire.

FAQ