Technitium DNS: A Self-Hosted DNS Server That Does It All

Most self-hosters start with a DNS ad blocker like Pi-hole or AdGuard Home. These work great for filtering ads, but at some point you hit their limits. You want authoritative DNS for a local domain. You want conditional forwarding so your VPN queries go one way and everything else goes another. You want DNS-over-HTTPS without bolting on a separate proxy. You want a real DNS server, not just a filtering proxy with a nice dashboard.

Photo by Eric Mills on Unsplash

Technitium DNS Server is that real DNS server. It is a full-featured authoritative and recursive DNS server with a modern web UI, built-in ad blocking, DHCP, DNS-over-HTTPS/TLS/QUIC support, and zone management. It does what Pi-hole does, what AdGuard Home does, and a whole lot more — all in a single deployment.

Technitium vs Pi-hole vs AdGuard Home vs CoreDNS

Before diving in, here is how Technitium compares with the tools you probably already know.

That is a lot of checkmarks for Technitium. The trade-off is complexity — Technitium gives you more knobs because it is a more capable tool. If all you want is ad blocking, Pi-hole or AdGuard Home is simpler. If you want a full DNS server, Technitium is in a different category entirely.

When to choose Technitium DNS

Pick Technitium if you need any of these:

• Authoritative DNS for local domains — You want server.home.lab and nas.home.lab to resolve to real IPs without editing hosts files on every device
• Split-horizon DNS — Internal clients should resolve app.example.com to a private IP while external clients get the public IP
• A recursive resolver — You want to resolve DNS from the root servers yourself instead of trusting Cloudflare or Google
• Conditional forwarding — VPN traffic queries go to one resolver, IoT traffic to another, and everything else to a third
• Zone transfers and clustering — You run multiple DNS servers and need them to stay in sync
• DNS-over-HTTPS/TLS/QUIC as a server — You want to serve encrypted DNS to your clients, not just use it for upstream queries
• All of the above plus ad blocking — One server handles everything

When to choose Pi-hole or AdGuard Home

Stick with Pi-hole or AdGuard Home if:

• Ad blocking is your primary (or only) goal
• You want the simplest possible setup and do not care about zone management
• You are running on extremely constrained hardware (Raspberry Pi Zero)
• You want the largest community and the most third-party guides (Pi-hole wins here)

When to choose CoreDNS

CoreDNS makes sense if:

• You are running Kubernetes and need a DNS server that integrates natively with cluster service discovery
• You prefer configuration-as-code over a web UI
• You need a lightweight, embeddable DNS server for a specific application

Installation via Docker Compose

Docker is the cleanest way to run Technitium. The official image works well and the project maintains it actively.

services:
  technitium:
    image: technitium/dns-server:latest
    container_name: technitium-dns
    hostname: technitium
    ports:
      - "5380:5380/tcp"   # Web UI
      - "53:53/tcp"       # DNS (TCP)
      - "53:53/udp"       # DNS (UDP)
      - "853:853/tcp"     # DNS-over-TLS
      - "853:853/udp"     # DNS-over-QUIC
      - "443:443/tcp"     # DNS-over-HTTPS
      - "67:67/udp"       # DHCP (optional — only if using built-in DHCP)
    environment:
      DNS_SERVER_DOMAIN: "dns.home.lab"
      DNS_SERVER_ADMIN_PASSWORD: "changeme"
    volumes:
      - technitium-config:/etc/dns/config
    restart: unless-stopped
    sysctls:
      - net.ipv4.ip_local_port_range=1024 65000

volumes:
  technitium-config:

docker compose up -d

Open http://your-server-ip:5380 and log in with the admin password you set.

Notes on the configuration:

• DNS_SERVER_DOMAIN is the hostname Technitium uses to identify itself, particularly for DNS-over-HTTPS certificates. Set this to whatever makes sense for your setup.
• DNS_SERVER_ADMIN_PASSWORD sets the initial admin password. Change this to something strong.
• Port 5380 is the web UI. Port 53 is standard DNS. Ports 853 and 443 are for encrypted DNS protocols.
• The DHCP port (67) is only needed if you plan to use Technitium as your DHCP server. Leave it out if your router handles DHCP.
• The net.ipv4.ip_local_port_range sysctl prevents port conflicts when Technitium acts as a recursive resolver and opens many outbound connections.

First-run setup

After logging in:

1. Set your upstream forwarders — Go to Settings and configure forwarders if you want to use upstream resolvers (Cloudflare, Quad9, etc.) instead of or alongside recursive resolution
2. Enable recursion — Under Settings, enable the recursive resolver if you want Technitium to query root servers directly
3. Add blocklists — Navigate to the Blocked zone and add your preferred ad-blocking lists
4. Create local zones — This is where Technitium really shines; more on this below

Core Features

Full authoritative and recursive DNS

This is the big differentiator. Pi-hole and AdGuard Home are DNS forwarders — they receive a query, check it against a blocklist, and forward it to an upstream resolver like Cloudflare. They never actually resolve anything themselves.

Technitium can operate as a recursive resolver, walking the DNS hierarchy from root servers down to authoritative servers, just like the resolvers run by your ISP or Cloudflare. This means:

• You do not have to trust any upstream provider with your query data
• You get DNSSEC validation at every step
• Cache performance improves over time as the resolver builds up its cache
• No single third party sees your complete query history

You can also run Technitium in forwarder mode if you prefer the simplicity of handing queries off to an upstream resolver — or use a hybrid approach where some zones use forwarding and others use recursion.

DNS-over-HTTPS, TLS, and QUIC

Technitium supports all three major encrypted DNS protocols as both a client (for upstream queries) and a server (for your network's clients).

As a server, your devices can query Technitium over encrypted connections. Modern browsers and operating systems support DNS-over-HTTPS natively. Point them at https://your-server/dns-query and your DNS traffic is encrypted end-to-end.

As a client, Technitium can forward queries to upstream resolvers over DoH or DoT, encrypting the hop between your server and the upstream. This replaces the cloudflared proxy that Pi-hole users need.

DNS-over-QUIC is the newest protocol and offers lower latency than DoH/DoT thanks to QUIC's zero-round-trip connection establishment. Client support is still growing, but Technitium is ready for it.

Web UI and zone management

The web interface is comprehensive. You can manage:

• Primary zones — Create forward and reverse lookup zones for your local domains
• Secondary zones — Pull zones from other DNS servers via zone transfers (AXFR/IXFR)
• Stub zones — Delegate resolution for specific domains to specific servers
• Conditional forwarder zones — Route queries for specific domains to specific upstream resolvers
• Blocked zones — Manage ad-blocking lists and custom blocklists

For each zone, you can create and edit all standard DNS record types through the UI: A, AAAA, CNAME, MX, TXT, SRV, NS, PTR, CAA, and more. No editing zone files by hand.

Built-in DHCP server

Technitium includes a DHCP server that can replace your router's DHCP. The advantage is tight integration — when a device gets a DHCP lease, Technitium automatically creates a DNS record for it. Your devices become resolvable by hostname without any manual configuration.

Enable this under Settings if you want it. You will need to disable your router's DHCP first to avoid conflicts.

Ad blocking via block lists

Technitium supports the same blocklist formats as Pi-hole and AdGuard Home. You can add lists from all the usual sources:

Add these under the Blocked zone in the Zones section. Technitium downloads and processes the lists on a schedule you configure.

The blocking experience is comparable to Pi-hole and AdGuard Home. You get a query log, you can whitelist domains with a click, and you can see per-client statistics. The UI is not as polished as AdGuard Home's blocking-specific interface, but it is functional and gets the job done.

Advanced Configuration

Split DNS

Split DNS (also called split-horizon) lets you return different answers for the same domain depending on who is asking. This is one of Technitium's strongest features.

A common use case: you host app.example.com on your home server at 192.168.1.50. External users should resolve it to your public IP, but devices on your local network should resolve it to the private IP directly. Without split DNS, your local devices would make a round trip out to the internet and back (called "hairpin NAT"), which is slower and sometimes does not work at all.

In Technitium, create a primary zone for example.com (or just app.example.com) with an A record pointing to 192.168.1.50. Your local devices query Technitium and get the local IP. External DNS remains unaffected because it is handled by your public DNS provider.

This also works for internal-only domains. Create a zone for home.lab and add records for all your services:

Every device on your network can now reach these services by name instead of memorizing IP addresses. If you move a service to a different IP, update it once in Technitium rather than on every device.

Conditional forwarding

Conditional forwarding lets you route DNS queries for specific domains to specific resolvers. This is essential for VPN setups, multi-site networks, and environments where different domains are authoritative on different servers.

Examples:

• Queries for corp.example.com go to the corporate DNS server at 10.0.0.53
• Queries for home.lab are resolved locally by Technitium
• Queries for friend.home.lab go to your friend's DNS server over a WireGuard tunnel
• Everything else goes to Cloudflare or is resolved recursively

Set this up by creating Conditional Forwarder zones in the Zones section. Each zone specifies the domain and the upstream server to forward to.

API automation

Technitium exposes an HTTP API for everything you can do in the web UI. This is useful for:

• Dynamic DNS — Update A records from a script when your public IP changes
• Automated provisioning — Create DNS records when you spin up new containers or VMs
• Integration with configuration management — Ansible, Terraform, or custom scripts can manage zones programmatically
• Monitoring — Pull query statistics and cache data into Grafana or other monitoring tools

The API uses a token-based authentication model. Generate an API token from the web UI, then make HTTP requests:

# Create an A record
curl "http://dns-server:5380/api/zones/records/add?token=YOUR_TOKEN&domain=test.home.lab&zone=home.lab&type=A&ipAddress=192.168.1.100"

# List all zones
curl "http://dns-server:5380/api/zones/list?token=YOUR_TOKEN"

# Update a record
curl "http://dns-server:5380/api/zones/records/update?token=YOUR_TOKEN&domain=test.home.lab&zone=home.lab&type=A&ipAddress=192.168.1.101&existingIpAddress=192.168.1.100"

The API documentation is available in the Technitium DNS web UI under the help menu and on the project's GitHub wiki.

Clustering and zone replication

If you run two Technitium instances (for redundancy or performance), you can configure zone transfers between them. The primary server holds the authoritative copy of a zone, and secondary servers pull updates via AXFR (full transfer) or IXFR (incremental transfer).

This is standard DNS functionality, but it is not something Pi-hole or AdGuard Home support. If your primary DNS server goes down, the secondary continues serving cached and replicated zones without interruption.

For a home lab, running a secondary instance on a different machine is an easy way to ensure DNS stays up even during maintenance. Point your router at both IPs as primary and secondary DNS servers.

Resource Requirements

Technitium is heavier than Pi-hole or AdGuard Home because of the .NET runtime, but it is still modest by any reasonable measure.

In practice, Technitium uses about 150-300 MB of RAM with ad-blocking lists loaded and a populated cache. The recursive resolver uses more memory than forwarder mode because it maintains a larger cache. CPU usage is negligible for home network traffic — you will not notice it on any modern hardware.

For comparison, Pi-hole sits at about 50-80 MB and AdGuard Home at about 50-100 MB. CoreDNS is the lightest at 20-50 MB but offers no web UI or ad blocking.

Honest Limitations

Technitium is a powerful tool, but it is not the right choice for everyone. Here are the trade-offs.

The .NET runtime is heavier than Go-based alternatives. Technitium runs on .NET, which means a larger Docker image (~150 MB vs ~30 MB for AdGuard Home) and higher baseline memory usage. On modern hardware this is irrelevant, but on a Raspberry Pi Zero or other extremely constrained devices, you will feel it. If you are running a Pi Zero, stick with Pi-hole.

Less community content than Pi-hole. Pi-hole has been around since 2014 and has an enormous community. You will find more blog posts, YouTube tutorials, Reddit threads, and Stack Overflow answers for Pi-hole than for Technitium. Technitium's community is active and helpful, but smaller.

The web UI is functional but not beautiful. It is a tool for DNS administrators, not a consumer product. If you are coming from AdGuard Home's polished interface, Technitium's UI will feel more utilitarian. Everything works, but the design prioritizes capability over aesthetics.

Overkill for simple ad blocking. If all you want is DNS-level ad blocking and you do not care about zones, conditional forwarding, or recursive resolution, Technitium adds complexity you do not need. Pi-hole or AdGuard Home will serve you better with less to learn.

No built-in parental controls or safe search. AdGuard Home includes parental controls and per-client safe search enforcement out of the box. Technitium can achieve similar results through blocklists and zone configuration, but it requires more manual setup.

Practical Tips

Start in forwarder mode, then explore recursion. Configure Technitium to forward queries to Cloudflare or Quad9 initially. Once everything is working, enable recursive resolution and compare the experience. Recursive is more private but slightly slower on first lookups.

Create a zone for your local domain early. Even if you only have a few services, a home.lab or local.yourdomain.com zone makes your network much more usable. Add A records for your services and stop memorizing IP addresses.

Use DHCP integration if you enable the DHCP server. The automatic DNS registration for DHCP clients is one of Technitium's best quality-of-life features. Your laptop, phone, and every other device becomes resolvable by hostname automatically.

Back up your configuration. Technitium stores everything in its config directory. If you are using Docker, your named volume contains all zones, settings, blocklists, and DHCP leases. Back up this volume regularly. A restore is as simple as recreating the container with the same volume.

Use the API for dynamic DNS. If your home IP changes, a simple cron job can update your public-facing A records via the API. This replaces services like DuckDNS or No-IP.

Monitor cache hit rates. The dashboard shows cache hit percentages. A healthy recursive resolver should see 70-90% cache hit rates after running for a day. Low hit rates might mean your cache size is too small or TTLs are being ignored.

Do not run DNS on WiFi. Just like with Pi-hole or any DNS server, use a wired Ethernet connection. DNS is the foundation of every network connection. A WiFi hiccup means every device on your network stalls while waiting for name resolution.

Set up a secondary DNS server. If Technitium goes down during maintenance or an update, your entire network loses DNS. Run a second instance on different hardware (even a Raspberry Pi running Pi-hole as a backup works) and configure your router with both as DNS servers.

Resources

• Technitium DNS Server GitHub
• Technitium DNS documentation
• Technitium DNS API documentation
• Technitium blog
• Hagezi's DNS blocklists
• OISD blocklist