r/technitium

When I was using dsnmasq I had the possibility to map a name to a MAC: every time this MAC was being offered an IP, the built-in DNS was mapping my chosen name to that IP. In other words, the IP was floating, but each device had a wel-defined name.

I cannot find this feature in technitium. The only thig I found is to fix the current IP that the device got, and then manually map this IP to a name in the DNS section.

Is there a better way?

Technitium DNS Server's Advanced Blocking app (the one that does per-client-group block lists, regex lists, adblock lists) only exposes its config as a raw JSON textarea in the web console. There's no button to just pause blocking for a bit, and no form to edit groups or block lists without hand-editing that JSON.

Im sharing my small self-contained addon that runs alongside the DNS server and adds:

- Pause/resume for the whole app or individual groups, with an optional timer (5 min, 1 hour, custom duration, whatever) and a countdown, so you can turn blocking off for a bit without forgetting to turn it back on

- A proper form based editor for the whole config: groups, block lists, allow lists, endpoint/network mappings, instead of hand editing JSON

- Styled to match the actual Technitium console (same CSS, same theme switcher, light/dark/amber) so it doesn't feel bolted on

- Self update from GitHub releases, works on Windows (including as a real Windows Service) and Linux (systemd), self contained so nothing extra needs installing on the host

It talks to the DNS server over its existing HTTP API, the same one the web console itself uses, so it's not forking or modifying the DNS server or the Advanced Blocking app in any way. It has its own login separate from your DNS server's auth, since it holds an API token with modify permissions and I didn't want that exposed to anyone who can reach the port.

Still early, v0.1.0, and only covers Advanced Blocking for now. Plan is to cover other apps in the store that use JSON config too, eventually.

GitHub: https://github.com/Hemsby/TDNS-AdvAppConfig

Is there a way to pause blocking when using the advanced blocking app? I see ho to do it with the standard built in blocking but I can’t seem to find a way to do it when using an app.

Happy to be here!

I've been using AdGuard Home (AGH) in my homelab for about four years to protect my family's devices and to avoid relying on my ISP for DNS. It worked well overall, but I ran into a few issues over the years, especially with DHCP and some resolver-related behavior.

My setup was:

Clients → AdGuard Home → Unbound → Cloudflare DoT

This gave me two layers: AGH for filtering and Unbound as the validating recursive resolver forwarding securely to Cloudflare.

I had tried Technitium DNS Server before, but I wasn't confident enough to switch completely. This week I decided to give it another chance and see if I could use it as a complete solution without adding multiple DNS layers.

The only thing that confused me was DNSSEC validation. At first, I added Unbound because I wasn't sure whether Technitium was validating correctly. After doing much deeper testing with dig and other tools, I tested dnssec-failed.org:

dig dnssec-failed.org +dnssec

Here are the results I received:

Cloudflare

EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

Quad9

EDE: 6 (DNSSEC Bogus)

Technitium (DNSSEC Validation enabled, forwarding to Cloudflare DoT)

EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)   ← From Cloudflare

EDE: 9 (DNSKEY Missing): (Attack detected! No SEP matching the DS found for dnssec-failed.org.)   ← Added by Technitium

Based on these results, it appears that Technitium is performing DNSSEC validation correctly. However, I'm still confused about one thing:

Why does Technitium report EDE 9 (DNSKEY Missing) instead of EDE 6 (DNSSEC Bogus) like Quad9?

Is this simply a difference in implementation and reporting between DNS resolvers, or is there something in my configuration that I'm missing?

I'd appreciate any clarification from people who have more experience with Technitium and DNSSEC.

This issue led me to use Unbound for DNSSEC validation with Technitium DNS Server. I adjusted several settings to optimize compatibility with Unbound, and the issue has been resolved successfully.

Below is my Unbound configuration file, along with screenshots of the Technitium DNS Server cache and main settings. Feel free to use them if you find them helpful.: https://gist.github.com/jo20201/0c9df33bc26faefca9b44ba9729cb83a#file-unbound-conf

https://preview.redd.it/bhkvl2r5b8ah1.png?width=516&format=png&auto=webp&s=b757342c60c2903cbbda7034825b9e9c4714e4c9

https://preview.redd.it/t17wutk7b8ah1.png?width=517&format=png&auto=webp&s=e3b518145df1ef355943e3982e9b38a247d40227

Hi

So I have a cluster - 4 nodes and around ~ 10 zones forward and reverse

Now I want to set the default access policy and xfer and notify.

If I set this on the catalog - then all of the zones that are part of the catalog will inherit those values ?

Should I have the primary node as part of the notify / xfer list

right now my zones are up ffailed to notify when they try to notify themselves

so pi5-a is my primary - it has 3 ip's ipv4 ipv6 GUA & ULA.

in the lof it fails because notify to itself fails

what do i do ?

i used two filters : https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/wildcard/ultimate-onlydomains.txt

https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/wildcard/tif-onlydomains.txtso it's good or add more

This is new. Or at least I just found it today. In View Logs, I see logs going back to November 2025 when I reinstalled everything. But it appears only about 2 1/4 hours are searchable on one server and around 7 1/2 hours on the other. Currently the oldest thing I can find is 2026-06-29 11:46:14 on one server and 2026-06-29 06:32:44 on the other and the newest 2026-06-29 14:01:22. Dashboard stats go back to November.

Logging is to file and In-memory stats is off. This was working at least a few months ago, but now everything seems to no stay in the database. Version 15.2

I have a weird situation and probably doing this wrong. What’s the best way?

Currently have *.local.com pointing to 192.168.1.2 for caddy but also also nas.local.com pointing to 192.168.1.10 as an A record in the same zone.

Some devices resolve nas to .10 and others to .2

What’s the way to do this properly? Thanks

Looking at https://hub.docker.com/r/technitium/dns-server the oldest version that exists seems to be 14.0.0.

Dunno if thats the first container edition or not but anyway.

If I would start with 14.0.0 can I then just reload into 15.2.0 and it will just work (regarding config-files) or how does upgrading works?

Is it also possible to downgrade?

Like if I got a 15.2.0 installation and replace the image with an older one - how far back can I moonwalk?

Im thinking since its not uncommon (compared to others) that if you for example would have been on version 13.0.0 you must upgrade through all major version like from 13.0.0 to 14.0.0 then 15.0.0 and finally you can jump onto the last one currently being 15.2.0.

And also that downgrading outside of current majorversion is often not supported.

Like if I currently have 15.2.0 I can downgrade down to 15.0.0 but not like back to 14.x.x or below.

So whats the official support for upgrading and downgrading containers with Technitium?

And what have those of you running technitium/dns-server experienced in the wild regarding upgrading or downgrading?

My main concern is how critical it is to apply each update.

Unless there are some CVE findings or some other bugs/features affecting me I would normally no jump onto each released version (unless I got some spare time to call for another maintenance window). But at the same time waiting for too long, at least with others, will also cause a headache.

If I have a cluster of two TDNS servers, am I correct in thinking that, for my DHCP advertised DNS servers, I can use one as primary and the other as secondary?

Technitium keeps assigning ip addresses to one google client.

Fresh LXC install with restored setting file.

````

026-06-27 06:42:20 UTC] Logging started.
[2026-06-27 06:42:20 UTC] [10.10.10.111:56632] [admin] All log files were deleted.
[2026-06-27 06:42:20 UTC] DHCP Server successfully saved scope file: /etc/dns/scopes/Default.scope
[2026-06-27 06:42:20 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:42:25 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:42:27 UTC] [0.0.0.0:68] DHCP Server offered IP address [10.10.21.1] to wlan0 [CC-8C-BF-55-E7-63] for scope: Default
[2026-06-27 06:42:28 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.1] to wlan0 [CC-8C-BF-55-E7-63] for scope: Default
[2026-06-27 06:42:28 UTC] DHCP Server updated DNS A record 'TuyaE763.lan.718homelab.net' with IP address [10.10.21.1].
[2026-06-27 06:42:28 UTC] DHCP Server updated DNS PTR record '1.21.10.10.in-addr.arpa' with domain name 'TuyaE763.lan.718homelab.net'.
[2026-06-27 06:42:29 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:42:30 UTC] DHCP Server successfully saved scope file: /etc/dns/scopes/Default.scope
[2026-06-27 06:42:33 UTC] Saved zone file for domain: lan.718homelab.net
[2026-06-27 06:42:33 UTC] Saved zone file for domain: 10.10.in-addr.arpa
[2026-06-27 06:42:33 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:42:38 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:42:40 UTC] DHCP Server successfully saved scope file: /etc/dns/scopes/Default.scope
[2026-06-27 06:42:42 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:42:46 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:42:50 UTC] DHCP Server successfully saved scope file: /etc/dns/scopes/Default.scope
[2026-06-27 06:42:50 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:42:55 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:42:59 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:43:00 UTC] DHCP Server successfully saved scope file: /etc/dns/scopes/Default.scope
[2026-06-27 06:43:03 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:43:08 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:43:10 UTC] DHCP Server successfully saved scope file: /etc/dns/scopes/Default.scope
[2026-06-27 06:43:12 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:43:16 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:43:20 UTC] DHCP Server successfully saved scope file: /etc/dns/scopes/Default.scope
[2026-06-27 06:43:20 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
[2026-06-27 06:43:25 UTC] [0.0.0.0:68] DHCP Server leased IP address [10.10.21.2] to [1C-53-F9-13-AF-B3] for scope: Default
````

I have been trying to figure out why zone transfers will fail occasionally between the primary and secondary. Also, nslookup against the secondary will fail.

After spending several hours digging into the issue I have found the problem, but not sure how to fix.

Primary is running in Docker on my NAS IP 10.0.10.20
Secondary is running on Win 11 IP 10.0.10.10

After doing DNS client tests from the primary to the secondary, I found that TCP works, UDP fails every time. Same issue from any client as well.

My secondary is a special creature. It is a PC running the following
NIC 1 10.0.10.10 with full routing table and gateway
Wireguard Server (WS4W) with ICS
Tailscale

NIC 2 10.0.12.6 has no gateway and is on the VLAN with my cameras. This is to minimize RTSP traffic across my router between BlueIris and the cameras
BlueIris

ICS also uses UDP 53 which is causing DNS requests to fail due to the port conflict. If I disable ICS, UDP works immediately.

https://preview.redd.it/ac9kj8nuv79h1.png?width=1142&format=png&auto=webp&s=a72a132412495cf7931e58a867c43f50f49d1c3b

Any suggestions on how I can make this work?

EDIT: I ordered a GL.inet Brume 3 to take over the VPN duties. That should fix the issue, as ICS won't be needed any longer.

Need to convince the wife that I need a redundant NAS for data security, then I can move my secondary DNS to it, and of course keep a redundant copy of my data there.

Fresh install of technitium. Set Forward server etc. I use this instance(cluster) at school and people are complaining regarding performance. Currently i have about 60 clients - from last our 45.500 requests. DO I need to tweak something to make it better? I have no blocking rules set etc. I use DNS over UDP - no tls nor quic, Rate limts are set to 0.
Technitium is set on Proxmox(VM) 4cpu/8Gb Ram, OS: Ubuntu Latest stable

Im trying to do some housekeeping of which images is used and instead of relying on tag:latest I try to figure out what is the actual latest version and fetch that tag.

This way I can also better track of what is actually being runned where.

So when I take backup of an image it will be stored as (for example) technitium_dns-server_15.2.0_260624.tar.gz

Any of you who happens to know if this is possible purely through CLI?

You can use "sudo podman inspect" to find out the digest of an image.

But I assume you then cant pull that with its current tag from a repo such as docker.io?

Currently Im doing a manual method of visiting https://hub.docker.com/r/technitium/dns-server and in the dropdown for Recent tags compare their digest.

Using the above manual method I found that for https://hub.docker.com/r/technitium/dns-server the digest between tag:latest and tag:15.2.0 is different - how come?

Is tag:latest newer than tag:15.2.0 when it comes to technitium/dns-server?

On the dashboard there is a simple list of top clients. As I use static IP's and not the inbuilt DHCP server how can I give those client IP's friendly names ?