Skip to main content
← All articles
tooling

Self-hosting your domain's DNS with Technitium — and the single-point-of-failure footgun

Self-hosting your domain's DNS with Technitium — and the single-point-of-failure footgun

Self-hosting reflex says: I run my own server, why not run my own DNS too? Technitium makes it genuinely tempting — one tidy app that's an authoritative nameserver, a recursive resolver, and a Pi-hole-style ad-blocker all at once. I run it, and I recommend it. But I do not let it be the authoritative nameserver for this domain, and the reason is a footgun that turns "my site is down for an hour" into "my domain doesn't exist for an hour."

What Technitium is

Technitium DNS Server is open-source (GPL, cross-platform .NET, actively maintained — v15.4 shipped mid-2026). It wears three hats: authoritative (host your own zone and answer for your domain), recursive (resolve the whole internet for your devices), and ad/malware blocking via blocklists. On a Docker box it's a five-minute job: run technitium/dns-server, expose port 53 (TCP+UDP) for DNS and 5380 for the web console, and configure everything in the browser. As a resolver-plus-adblocker it's excellent.

The footgun: your only box as your only nameserver

Here's the trap. The tempting final step is to point your domain's NS records at your VPS and host the authoritative zone there too. Don't — not on a single box. DNS isn't like your website. If your web server goes down, visitors get an error but the internet still knows your domain exists. If your only authoritative nameserver goes down, your domain effectively vanishes: no website, no email (MX lookups fail), no subdomains, nothing — until the box comes back and caches expire.

This isn't a matter of taste; it's baked into DNS's requirements. IANA's own technical rules for nameservers state there must be at least two NS records in a delegation, resolving to different IPs, and — the part people miss — those servers must be on at least two topologically separate networks (different routing autonomous systems). One Technitium instance on one OVH VPS is one server on one network. It violates both rules, and the whole point of the rule is that your DNS should survive any single failure. A single box can't.

A website on one server is a single point of failure for your site. Authoritative DNS on one server is a single point of failure for your entire domain — a strictly worse blast radius for the same money.

Where the line is

So I split it by role, and I'd suggest you do too:

  • Recursive resolver + ad-blocking + lab/internal zones — self-host on Technitium all day. If it goes down, you switch your laptop's DNS to 1.1.1.1 and you're fine; nobody else is affected. This is where the value is and the risk is near zero.
  • Authoritative DNS for your real public domain — leave it at your registrar or a redundant managed provider that already runs multiple nameservers across multiple networks. Mine stays with the domain's DNS host, and that's a feature, not a compromise.

If you really want to self-host authoritative

There's a correct way, and Technitium supports it: run a hidden primary. Your VPS holds the primary zone but isn't listed in the public delegation; one or more external secondary nameservers pull the zone from it via zone transfer (AXFR/IXFR, with NOTIFY for promptness — Technitium does primary, secondary, stub, and conditional-forwarder zones, plus catalog zones for auto-provisioning). Now you get to author your zone yourself while the public is served by redundant secondaries on diverse infrastructure. That satisfies the two-NS rule properly. It's more moving parts than a solo blog needs, which is exactly why I don't bother — but if authoritative self-hosting is the goal, that's the shape that isn't a footgun.

One security note

Whatever you do, don't expose a recursive resolver open to the whole internet. An open resolver gets abused for DNS amplification attacks — a small spoofed query triggers a big response aimed at a victim, amplification factors of roughly 50x and up. Restrict recursion to your own networks with ACLs, and firewall port 53 so the resolver only answers the clients you trust. Technitium has per-network recursion controls; use them.

Self-hosting is about owning your infrastructure deliberately, not maximally. DNS is the one layer where "run it all yourself on one box" quietly trades a small win for a domain-wide outage waiting to happen. Own your resolver, rent your redundancy.

Links

BM
Blue Moose
The moose behind Blue Moose. Full-stack PHP developer — Drupal by day, Symfony by night, tests always.