Technitium DNS Server
Authoritative and recursive DNS server with DNSSEC signing, DHCP and a real web console
Technitium DNS Server is a full DNS server that hosts your own zones, resolves recursively, blocks domains from lists and runs DHCP, all from one web console. It replaces a hosted DNS control panel plus a separate blocker, or a hand-configured BIND and Unbound pair.
Our verdict on Technitium DNS Server#
Technitium is the only common self-hosted DNS box that is genuinely both halves of DNS. It recurses and blocks from lists like Pi-hole does, and it is also an authoritative server: you can host a real zone, sign it with DNSSEC from the UI, run AXFR/IXFR to a secondary with NOTIFY, and do split-horizon or geo responses through its DNS Apps system. If all you want is "block ads on my LAN", that is more machine than you need and Pi-hole or AdGuard Home is less to think about. You want Technitium when you actually own a domain and are tired of clicking through someone else's DNS console, or when you need conditional forwarding and per-zone policy that a blocker cannot express. v15 (April 2026) moved to the .NET 10 runtime, which is a manual runtime install before a native Linux upgrade, added OIDC single sign-on with group mapping, and started running fresh Linux installs as an unprivileged dns-server user.
Who Technitium DNS Server is for#
Choose it if
- Someone hosting a domain who wants to run the authoritative zone themselves, with DNSSEC signing they can actually see and manage
- Split-horizon setups where internal clients must get private A records for the same names the public internet resolves elsewhere
- A homelab consolidating DHCP, internal DNS and ad blocking into one service instead of three
- Anyone who wants their resolver's admin console behind their existing Keycloak or Authentik, which v15's OIDC support makes possible
Look elsewhere if
- Blocking ads on a home network is the whole requirement; the extra surface buys you nothing and costs you an authoritative server you can misconfigure
- You want a small memory footprint on a constrained board, since the .NET runtime puts the floor well above a Go or C resolver
- You need the vendor's commercial support or an SLA, since this is a single-vendor GPL project with community support
What running it actually looks like#
One container, or a native install on Windows, Linux, macOS and Raspberry Pi through an installer script or tar.gz. The shipped compose file publishes 53/tcp and 53/udp plus 5380 for the web console, with the HTTPS console (53443), DoT (853), DoH (443) and DHCP (67) entries present but commented out for you to enable. One volume at /etc/dns holds config and zone data, with logs optionally split to /var/log/technitium/dns. Default credentials are admin / admin, so set DNS_SERVER_ADMIN_PASSWORD before the first boot or change it immediately. Every DNS_SERVER_* variable is read only when the config file does not yet exist, so after first run they are inert. Native upgrades to v15 need the .NET 10 runtime installed first, and certbot certificates now have to be readable by the dns-server user.
Resource profile#
- Memory
- 130 MB idle, around 280 MB in ordinary use. A .NET runtime is the floor. Above that, memory tracks cache size, in-memory statistics and how large your blocklists and signed zones are.
- CPU and acceleration
- Recursion and cache lookups are cheap. DNSSEC signing and zone re-signing, plus blocklist compilation on refresh, are the visible spikes; a Raspberry Pi handles a household comfortably.
- Storage growth
- Zone data is tiny. Logs and statistics dominate and are capped by DNS_SERVER_LOG_MAX_LOG_FILE_DAYS and the stats retention setting.
- Operational load
- 3 of 5, Moderate. Single service, but you are running real DNS infrastructure: zone data, DNSSEC keys, recursion ACLs and potentially DHCP. Major upgrades have moved the .NET runtime and changed the service user, and a mistake in an authoritative zone takes a domain offline.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Everything lives under the config directory, /etc/dns in the container and in the standard Linux install. It contains dns.config (server settings, local users, SSO configuration, admin password hash), a zones directory with your authoritative zone data and DNSSEC private keys, cached blocklists, installed DNS Apps and the statistics files. There is no database process, so a tar while running is usually fine, but the supported route is the built-in Settings then Backup export, which produces a single zip you restore into a fresh install. Blocklist caches, logs and stats are regenerable and can be excluded. The DNSSEC private keys are the one irreplaceable item: lose them and every signed zone goes bogus until you publish a new DS record at your registrar and wait out the TTL.
Derived backup shape
File copy. Copy the config and data directories. Safe while running for anything that writes atomically.
Traps and surprises#
DNS_SERVER_* variables apply only on first run
The documentation is explicit: these environment variables are read only when the config file does not yet exist. Change DNS_SERVER_FORWARDERS or DNS_SERVER_ADMIN_PASSWORD in an existing compose file, recreate the container, and absolutely nothing happens, because /etc/dns/dns.config already exists and wins. After first boot the UI and the API are the only ways to change settings. To re-apply environment configuration you have to start from an empty config volume.
Default login is admin / admin
A fresh install accepts admin with the password admin on the web console at port 5380. If that port is reachable from anything but your management network, you have handed over the resolver for your entire network, which is a straightforward path to silent traffic redirection. Set DNS_SERVER_ADMIN_PASSWORD (or the _FILE variant) before first boot, and bind the console to a LAN address with DNS_SERVER_WEB_SERVICE_LOCAL_ADDRESSES.
v15 needs the .NET 10 runtime installed before you upgrade
v15 moved from the previous .NET release to .NET 10, and on native Linux installs the runtime is not upgraded for you: install it first or the service will not start after the update. v15 also changed fresh Linux installs to run as an unprivileged dns-server user rather than root. Existing installs stay on root, but if you feed it Let's Encrypt certificates on a new install, those files must be readable by dns-server or TLS silently fails to load.
Recursion is restricted by network ACL by default
Technitium does not answer recursive queries for arbitrary sources, which is correct behaviour for an internet-facing authoritative server but surprising on a LAN. Clients on a different subnet, a VLAN, or a VPN range such as 10.8.0.0/24 get REFUSED until you widen the recursion network ACL in Settings, or set DNS_SERVER_RECURSION and DNS_SERVER_RECURSION_NETWORK_ACL at first boot. The symptom is one subnet resolving fine and another appearing to have no DNS at all.
A local zone shadows the entire public zone
Creating a primary zone for example.com to add one internal record makes this server authoritative for everything under that name. It stops asking upstream, so any public record you did not copy in returns NXDOMAIN for every client using it, including MX and TXT records that break your mail. For a couple of overrides, use conditional forwarding or a stub zone for the specific names instead, and only create the full zone when you intend to hold every record in it.
Specifications#
- Category
- Networking, DNS and remote access
- Licence
- GPL-3.0 (Copyleft)
- Written in
- C# / .NET 10
- First release
- 2017
- Maturity
- Mature
- Datastore
- Flat files under the config directory (zone files, settings, stats); no external database
- Default ports
53,5380,53443,443,853- Ships as
- docker, native installer, install script, portable tar.gz
- arm64 builds
- Yes
- Identity
- Native OIDC. OpenID Connect single sign-on with scope and group-to-role mapping shipped in v15 (April 2026); before that it was local accounts only.
- Replaces
- Windows Server DNS, Amazon Route 53, Cloudflare DNS, NextDNS
- Project site
- technitium.com/dns
- Source
- github.com/TechnitiumSoftware/DnsServer
- Documentation
- github.com/TechnitiumSoftware/DnsServer/blob/master/DockerEnvironmentVariables.md
Alternatives to Technitium DNS Server#
Everything else in networking, dns and remote access, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Headscale | 3, Moderate | 40 MB | BSD-3-Clause |
| Traefik | 3, Moderate | 60 MB | MIT |
| AdGuard Home | 2, Light | 60 MB | GPL-3.0 |
| Nginx Proxy Manager | 2, Light | 100 MB | MIT |
| Pi-hole | 2, Light | 100 MB | EUPL-1.2 |
| wg-easy | 2, Light | 90 MB | AGPL-3.0-only |
Where Technitium DNS Server comes up elsewhere#
Head to head
Research
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.