TPTito Pinardo Gutiérrez
← Back to the rack
Español
1U · DNSTechnitium · DoH · dynamic IP In production

Slot 4 of 25 in the rack · In production

1U unit · Home network

Home DNS · Technitium

Migrated with 0 lost queries

Every device at home, the router and the server itself ask here which address each name has. It answers internal names, blocks ads and trackers, validates DNSSEC signatures and whatever it has to ask outside, it asks encrypted.

Why Technitium
It replaces two parts (Pi-hole and Unbound) with one: its own resolution, persistent cache, blocking and local zones, all with an API.
How it was migrated
Next to the old one, in the same container and on the same IP. A port redirect moved new queries to the new service while the old ones finished.
The other tenant
A tiny container checks the home public IP every 5 minutes and, if it changes, updates Cloudflare.
  • 1,200queries during the switch, 0 failures
  • 19.5 msthe slowest answer in that test
  • 276,000+domains on the block lists
  • 5 minhow often the public IP is checked

Its code, in the open Public version of the repo: no IPs or secrets.

Inside the DNS

Every name typed at home comes through here before going anywhere. Pick a flow.

Flows Pick one and follow the packet.

Outside DNS containers · Proxmox Technitium + IP sync Resolve Filter and validate The migration from Pi-hole Dynamic IP and start-up Home devices Router DHCP Hypervisor Public DNS Cloudflare Port 53 Local zones Cache DNS over HTTPS Lists My own blocks DNSSEC Panel Pi-hole New port Redirect Monitoring IP sync Public IP Records Starts first
Hermesvisiting the unit

Click a part or pick a flow. If you came from a skill, the parts where I use it are already lit.

      Someone opens a website
      1. Home devices — A phone at home wants to open a website.
      2. Router DHCP — It uses the DNS the router gave it when it joined: this one.
      3. DNS entry point — The query reaches the DNS server.
      4. Block lists — First, is it on a block list? No.
      5. Persistent cache — Is it cached? No: it's the first time anyone has asked.
      6. Encrypted upstream (DoH) — It goes out to ask, over HTTPS.
      7. Public resolvers — A public resolver answers.
      8. Encrypted upstream (DoH) — The answer comes back encrypted and its DNSSEC signature is validated if it has one.
      9. Persistent cache — It's cached for next time.
      10. Home devices — The phone gets the address and opens the site.
      An internal name
      1. Home devices — From home I ask for a panel by its internal name.
      2. DNS entry point — The query reaches the DNS.
      3. Local zones — The name is in a local zone: it's answered right here, without asking outside.
      4. Home devices — The device gets the address of the internal door.
      A website tries to load ads
      1. Home devices — A website asks for an ad domain.
      2. DNS entry point — The query reaches the DNS.
      3. Block lists — It's on the block lists.
      4. Manual blocks — Or on my own blocks.
      5. Home devices — The answer is «doesn't exist»: the ad doesn't load, on any device in the house.
      The migration, without downtime
      1. The previous DNS — Pi-hole is still answering everyone.
      2. Technitium on another port — Technitium starts on another port in the same container and I test it: names, blocks, DNSSEC.
      3. nftables redirect — An nftables rule sends new connections on 53 to the new server, without changing the IP or anything on the clients.
      4. DNS entry point — New queries are now answered by Technitium.
      5. Monitoring — For five minutes I fire 1,200 queries alternating external and internal names: 0 failures, the slowest 19.5 ms.
      6. The previous DNS — Pi-hole stops once its last connections finish, and stays installed as a way back.
      The home IP changes
      1. IP sync — Every 5 minutes the sync job wakes up.
      2. What's my IP? — It asks what public IP home has.
      3. Public resolvers — The answer comes from outside.
      4. IP sync — It has changed since last time.
      5. Cloudflare DNS — It updates Cloudflare.
      6. Public records — The records that should point home now have the new IP.
      The power comes back
      1. The hypervisor and its containers — After a power cut the server boots. With the disk checks it can take over an hour.
      2. Start-up order — DNS is first in the start-up order.
      3. DNS entry point — As soon as it answers, the other containers can resolve names.
      4. The hypervisor and its containers — The hypervisor asks it first, and a public one only if it doesn't answer.
      5. Home devices — Meanwhile, home devices can set a public DNS by hand: nothing is forced in the router.
      6. Router DHCP — When everything is back, DHCP keeps handing out this DNS.

      1. Home devices

        Phones, laptops, the TV and the server's containers: they all ask here.

      2. Router DHCP

        When giving a device its address, the router tells it which DNS to use: this one, on all three segments.

        • MikroTik

      3. The hypervisor and its containers

        The server resolves here too since October, with a public one as fallback if this doesn't answer.

        • Proxmox VE

      4. Public resolvers

        Whatever isn't cached is asked outside, over HTTPS.

      5. Cloudflare DNS

        Where my domains' public records live.

      6. DNS entry point

        The same address as always: devices didn't notice the server change.

        • Technitium DNS

      7. Local zones

        The homelab's and the lab's internal names. Never asked outside.

        • Technitium DNS

      8. Persistent cache

        Stores answers honouring their expiry, survives restarts and refreshes the most used ones ahead of time.

        • Technitium DNS

      9. Encrypted upstream (DoH)

        Queries leaving home go over HTTPS: anyone watching the line can't see which names are asked. Checked: nothing leaves on port 53 any more.

        • Technitium DNS
        • Linux / SSH hardening

      10. Block lists

        The same twelve lists I had on Pi-hole, over 276,000 ad and tracking domains.

        • Technitium DNS

      11. Manual blocks

        A few domains blocked by hand, plus the signals some browsers check to bypass the network's DNS.

        • Technitium DNS

      12. DNSSEC validation

        If a signed domain answers with a signature that doesn't add up, the answer is rejected.

        • Technitium DNS
        • Linux / SSH hardening

      13. Admin panel

        Only from inside, behind the internal door with two-factor. The service doesn't run as root.

        • Linux / SSH hardening

      14. The previous DNS

        Pi-hole with Unbound. Left installed, stopped, as a way back.

      15. Technitium on another port

        The new server started next to the old one, on another port, to test it without affecting anyone.

        • Linux (Debian, Alpine, Arch)

      16. nftables redirect

        A rule moved new connections on port 53 to the new server inside the same container. Those already open finished on the old one.

        • Linux (Debian, Alpine, Arch)

      17. Monitoring

        Zabbix checks it resolves external names and both services are up; Wazuh watches for configuration changes.

      18. IP sync

        A minimal container with a script. It checks the home public IP every 5 minutes.

        • Linux (Debian, Alpine, Arch)

      19. What's my IP?

        It asks outside which IP the world sees and compares it with the last known one.

        • Linux (Debian, Alpine, Arch)

      20. Public records

        If the IP changed, it updates the records that should point home. Otherwise it does nothing.

      21. Start-up order

        After a power cut, DNS is the first container to start: everything else needs it.

        • Proxmox VE

      What I use from my skill tree

      Pick a skill: the parts where I use it light up on the map and I tell you what for.

      Proxmox VE
      The hypervisor and its containers resolve here, and DNS is first in the start-up order.
      LXC
      Technitium and the sync job run in their own LXC containers.
      Linux (Debian, Alpine, Arch)
      nftables for the migration redirect and to protect the new ports; the service runs without root under systemd's restrictions.
      MikroTik
      The router's DHCP announces this DNS on all three segments, and the router itself asks it too.
      Technitium DNS
      Technitium: local zones, persistent cache with prefetch, DNSSEC, query minimisation, block lists and DoH upstream.
      Linux / SSH hardening
      Panel only behind the internal door with two-factor, encrypted external queries and signature validation.

      Incident log

      Real failures. Read the symptom, pick the cause you think it was and see how it was fixed.

      1. #1

        Home DNS was encrypted… except the server's

        10-10-2026 · privacy

        Whatever went through the home DNS left encrypted. But checking the server's connections there were still plain DNS queries going out.

        What do you think was going on?

        Show the fix
        Cause
        The hypervisor had public resolvers configured and 16 of the 18 containers inherited them: they asked outside, on 53, unencrypted and uncached.
        Fix
        A playbook that points the hypervisor and the containers at the home DNS, with a public one only as fallback, updated live without restarting anything. And DNS first to start.
        Lesson
        Check the real path of the traffic, not the configuration you assume. The flaw was on the server itself, not on the home devices.

      2. #2

        DNS goes down for the whole house

        13-09-2026 · migration

        The very night of the migration, the house couldn't resolve names for a while.

        What do you think was going on?

        Show the fix
        Cause
        There were two containers with similar names: the test one and the production one. I switched off the one serving the house, thinking it was the old one.
        Fix
        Turn it back on, check resolution, blocking and the redirect, re-enable auto-start and rename both containers so they can't be confused.
        Lesson
        Names are part of operational safety: whatever can be confused, someone will confuse. Me included.

      3. #3

        Force DNS on the router?

        10-10-2026 · decision

        To stop any device bypassing the home DNS, the usual move is for the router to redirect or block any query to port 53 going out. I didn't do it.

        What do you think was going on?

        Show the fix
        Cause
        After a power cut the server can take over an hour to boot. With 53 forced, the house would be without internet until then.
        Fix
        Decision: don't force it. DHCP hands out this DNS, and anyone who needs to can set a public one by hand to keep working.
        Lesson
        Security that leaves everyone without service when one part fails isn't an improvement. Decide with the worst case in front of you.

      How it was built

      1. Summer 2026

        Pi-hole and Unbound

        • Ad blocking for the whole house and its own recursive resolution.
        • Two services to maintain and update separately.

      2. 13-09-2026

        Migration to Technitium

        • Installed next to the old one, with the official package checked against its hash.
        • Same lists, same blocks and same local zones.
        • Switch through a port redirect, without touching any client: 0 lost queries.

      3. 10-10-2026

        Encryption and start-up

        • Upstream over DNS over HTTPS, checked by watching the connections.
        • The hypervisor and its containers now resolve here.
        • DNS first to start after a power cut.

      Decisions (and why)

      • How to migrate a service everyone uses

        On the same address, with a port redirect

        Changing the DNS IP means touching DHCP and waiting for every device to renew. Redirecting the port inside the same container makes the switch invisible and reversible in seconds.

      • How it goes out

        DNS over HTTPS

        Unencrypted, anyone on the path sees which names are asked at home. With DoH they only see HTTPS connections to a resolver.

      • The dynamic IP

        A container of its own that updates Cloudflare

        My connection has no fixed IP. A small script in its own container is easy to monitor and doesn't depend on third-party services.

      What I learned

      • A service everyone uses is changed without anyone noticing, or not at all.
      • Look at real traffic: the server kept asking in plain text while the house was already encrypted.
      • Names that can't be confused, especially for what serves everyone.

      What's next

      • Serve DNS over IPv6 too, once the bug I found testing it is sorted.
      • Move the lists and zones into code in the infrastructure repo.

      Shall we talk?

      I can walk through any of these decisions in detail in an interview.

      Download CV Get in touch ← Back to the rack

      Rebuilt from my documentation: no addresses, zones or internal names.