This seemed straightforward. BIND9 on a Debian box, forward to roots, cache locally, save on upstream queries. I had run Windows Server DNS for internal zones before and it was fine. Three months in, my upstream notified me: my box was participating in UDP amplification attacks against gaming targets. I had missed the recursion lockdown in one config stanza. The traffic was 70 Gbps peak, all from my single €40 OVHcloud VPS. Mitigation took 48 hours: null-routed, rebuilt with allow-recursion ACLs, rate limiting, response policy zones. Then I found the real problem: even "fixed," anycast is basically mandatory for resilience, and anycast from one provider is just... single-homed with extra steps. Migrated everything to Vultr managed DNS. Not proud, but my sleep schedule recovered.
I ran my own recursive resolver and learned why I shouldn't
Your null-route suggests your provider uses static blackholing rather than RTBH. In my experience, that indicates they lack proper BGP communities for traffic scrubbing.
A few corrections: anycast is not "single-homed with extra steps." True anycast requires:
- Multiple POPs with independent transit
- Consistent zone state across all nodes
- RPKI ROAs for each origin ASN
- IRR route objects maintained
The $2K/month figure you will hear shortly is actually reasonable for small anycast. Transit alone at three sites runs $400-600 each if you want diverse paths. Add colo, hardware or VM costs, monitoring, and suddenly managed DNS at $20/month is the rational choice.
One detail: your amplification factor was likely 50-70x for DNS. TCP-only would have prevented this entirely.
(I ran bind for fifteen years) never had this problem. The secret is reading the documentation (which hasnt improved since 2009)
Semicolons are important. Bind knows this. Its config syntax is basically semicolons as therapy
To be fair to wendy, the default debian package used to allow recursion from localhost only. Someone changed that in a recent release (security theater, probably). I checked my own box and found the same hole. Patched it before breakfast (coffee, black, too hot)
The real lesson: running infrastructure is a job. If its not your job, dont. Simple as that
Same here but with Unbound. Three days of "why is my upstream billing me for 12TB" before I found the open resolver check. The lesson cost me €180.
This is why I just use Cloudflare's 1.1.1.1 and call it a day. My time is worth more than the ego boost of running my own.
Self-hosting DNS is the gateway drug. You start with Pi-hole for blocking, then you want local zones, then you want your own recursion, then you're explaining to your ISP why you're on a blacklist.
I should clarify: that was for a three-POP anycast deployment with your own ASN and PI space. If you are using a managed anycast provider like NS1 (now IBM) or AWS Route 53, you are not running anycast. They are. You are just pointing NS records.
The distinction matters because the thread title is about running your own resolver, not about outsourcing the entire authority layer.
At work we run internal resolvers with Unbound. The difference: we have a team, monitoring, and a direct contact at our upstream for RTBH. Wendy did this solo on a €40 VPS. The failure mode was predictable.
OVHcloud's network is actually decent for the price but their DDoS mitigation is... reactive. I've seen them null-route first and ask questions later. If you want to play with anycast from one provider, Hetzner is not better, just cheaper.
From Sydney the root servers are far enough away that local caching actually matters. I ran my own for two years before switching to Quad9. The latency improvement was real but the maintenance burden was realer.