dnsweaver vs Technitium DNS Server: Proxmox Homelab

If you're running Docker containers, VMs, and Kubernetes pods on a Proxmox homelab, you've likely hit the same wall: every new workload needs DNS, and manually pointing each one at a resolver gets old fast. dnsweaver and Technitium DNS Server both claim to fix this, but they take very different approaches. Compare the two below and you'll know exactly which one belongs in your network.

Key Takeaways

• Configuration model: dnsweaver auto-configures DNS for new workloads; Technitium asks you to create zones and records yourself.
• Maturity: Technitium is a mature, widely deployed open-source server; dnsweaver is a newer, purpose-built auto-config tool.
• Best fit: dnsweaver thrives in dynamic Docker and Kubernetes environments; Technitium wins for stable, fully controlled setups.
• Resource use: Technitium idles around 150 MB of RAM; dnsweaver's resolver footprint is noticeably lighter.
• Interface: Technitium ships a full web admin UI; dnsweaver leans on config files and a CLI.

How Do Technitium and dnsweaver Actually Differ?

The core difference is architectural, and it changes where you spend your time.

Technitium DNS Server is a full-featured DNS server. It's authoritative for your custom zones and recursive for the outside world, all inside one .NET application. You install it, point clients at it, and then manually define the zones, records, and blocklists you want. It's powerful precisely because you control every record.

dnsweaver takes a different philosophy. Instead of you maintaining a zone file, dnsweaver runs a local resolver alongside a registry of known service names, then reaches into your workloads and configures their resolver settings for you. When a container or pod appears, dnsweaver makes sure it resolves your internal names without you editing a single file. It's built for the ephemeral, rapidly changing environments that homelabs and small Kubernetes clusters actually are.

Think of Technitium as the DNS server you operate, and dnsweaver as the layer that operates DNS on your behalf.

Technitium DNS Server: Full Control with a Web UI

Technitium is written in C#/.NET and runs anywhere .NET runs, but its Docker image is the most common way to deploy it on a Proxmox VE 9 host. The image handles the tricky part of binding to port 53 without requiring the container to run as root, which keeps the deployment clean.

docker run -d \
  --name technitium \
  --restart unless-stopped \
  -p 53:53/tcp \
  -p 53:53/udp \
  -p 5380:5380 \
  -v technitium-data:/data \
  technitium/dns

Once it's up, open the admin UI at http://<host-ip>:5380. From there you can create internal zones, add records, and manage blocklists.

The web UI is where Technitium earns its keep. To add an internal domain, navigate to Zones and add a new zone for something like homelab.local, then add A records for each service. You can also paste in popular ad-blocking blocklists, and Technitium filters queries across every client that points at it. That's the same ad-blocking behavior you'd want whether a query originates from a container, a VM, or a phone on your LAN.

For DNS-over-HTTPS or DNS-over-TLS clients, Technitium has built-in certificate and endpoint settings, so you can serve encrypted queries without juggling a separate TLS proxy. Locally cached queries resolve in a few milliseconds, which is snappy enough that you'll stop noticing DNS latency entirely.

One thing to get right up front: DNS runs over both TCP and UDP. The command above publishes both -p 53:53/tcp and -p 53:53/udp. A common mistake is publishing only the UDP half and wondering why large responses or zone transfers time out. DNS falls back to TCP for oversized messages, so a UDP-only publish silently breaks a subset of queries.

Technitium also runs inside an LXC container, which is handy if you want DNS isolated from your other workloads. The catch there is that an unprivileged container must be granted the net_bind_service capability before it can bind port 53, otherwise the server starts but never answers.

dnsweaver: Auto-Configured DNS for Dynamic Workloads

dnsweaver is the newer entry in this space, and its whole selling point is removal of manual DNS work. Instead of you maintaining records, dnsweaver discovers your workloads and configures their resolver settings automatically.

The way it works: dnsweaver runs a local resolver on your host along with a registry of known service names, then uses network redirection and resolver-file injection to point Docker containers, VMs, and Kubernetes pods at itself. When a workload comes up, dnsweaver ensures it can resolve your internal domain; when it goes away, dnsweaver drops the record. You declare your network topology and services once, and the rest keeps itself in sync.

Because dnsweaver is resolver-focused rather than a full authoritative server, its resource footprint is small. You can expect it to sit comfortably below Technitium's ~150 MB idle, which matters on a low-end homelab box where every megabyte counts.

The tradeoff for that convenience is visibility. Since dnsweaver manages your workload DNS behind the scenes, a misconfiguration or a crashed resolver agent can leave every workload unable to resolve names at once. There's no web UI to eyeball the way Technitium offers — you read the state through its config and CLI. If you value transparency over turnkey setup, keep an eye on how dnsweaver surfaces its status.

How to Point Your Containers, VMs, and Pods at the Server

Whichever server you choose, the workloads still need to know where to send queries. The method depends on the workload type.

For Docker Compose, add a dns key to the service so the container uses your resolver instead of Docker's default:

services:
  whoami:
    image: containrrr/whoami
    dns: 192.168.1.50
    networks:
      - appnet

networks:
  appnet:
    driver: bridge

For a VM, point the DHCP server (usually your router) at the resolver's IP, or set a static resolver in the guest's network config. For Kubernetes, configure the cluster's DNS forwarder or node resolver so pods inherit the internal server.

If you extend the same DNS to remote nodes, running it over a WireGuard fabric keeps queries encrypted end to end. And once your DNS and segmentation are in place, pairing them with the firewall and SSH hardening steps you'd apply to any segmented Proxmox network pays off. On a network where VLANs carry multiple tagged subnets, a single resolver that every VLAN trusts is what makes the whole thing usable.

dnsweaver vs Technitium at a Glance

Feature	dnsweaver	Technitium DNS Server
Configuration model	Auto-configures workload DNS	Manual zone and record setup
Ideal environment	Dynamic Docker and Kubernetes	Stable, controlled setups
Ad / blocklist support	Depends on upstream	Built-in blocklist filtering
Admin interface	Config file and CLI	Web-based UI
Maturity	Newer project	Mature and widely used
Idle resource use	Light resolver footprint	~150 MB RAM

Which One Should You Run on Your Proxmox Homelab?

The answer comes down to how much manual DNS work you enjoy.

If your homelab is a moving target — containers and pods appearing and disappearing daily, and you'd rather not edit zone files after every deploy — dnsweaver removes the most tedious part of the job. You accept a sliver less visibility in exchange for a resolver that keeps itself current.

If you prefer to see and edit every record, want built-in ad blocking, and want a battle-tested server with a rich web UI, Technitium is the more reliable long-term choice. It costs a bit more setup time, but you keep full control.

For most homelabs, a practical path is to start with Technitium for the authoritative internal zone and ad blocking, then layer dnsweaver on top if you find yourself tired of re-pointing workloads. Both run side by side without conflict as long as only one answers on port 53.

Conclusion

dnsweaver and Technitium both get your workloads resolving, but they disagree on who should do the work: dnsweaver automates it, and Technitium puts you in control. Choose dnsweaver for a hands-off setup in a dynamic environment, and Technitium if you want full control, a web UI, and built-in ad blocking. Your next step is to stand up Technitium with the command above and add your homelab.local zone, or spin up dnsweaver and point one bridge at it to see auto-configuration in action.