Files
truenas-stacks/technitium-pilot/README.md
Fizzlepoof 9bb48ee385
Some checks failed
secret-guardrails / artifact-secret-scan (push) Has been cancelled
secret-guardrails / gitleaks (push) Has been cancelled
Add Technitium backup sync automation
2026-05-24 00:15:58 +00:00

3.1 KiB

Technitium DNS pilot on PD

Non-disruptive Technitium DNS Server pilot for PlausibleDeniability.

  • Repo stack path: /home/fizzlepoof/repos/truenas-stacks/technitium-pilot
  • Live PD stack path: /mnt/docker-ssd/docker/compose/technitium-pilot
  • Pilot bind IP: 10.5.30.8
  • DNS ports: 53/tcp, 53/udp
  • Web console: http://10.5.30.8/
  • Friendly hostname inside Technitium: http://dns.home.paccoco.com/

This pilot intentionally does not touch the live Pi-hole service on 10.5.30.6 or the client VIP on 10.5.30.53.

Current mirrored baseline from Pi-hole:

  • blocklists:
    • https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
    • https://big.oisd.nl
  • no custom local DNS entries detected
  • no conditional forwarding detected
  • no extra dnsmasq fragments detected

Pilot-specific adaptation:

  • Production Pi-hole forwards to PD-local Unbound on 127.0.0.1:5335.
  • Because the Technitium pilot uses a dedicated macvlan IP, that loopback-only upstream is not reachable from the pilot without changing production Unbound.
  • For pilot safety, Technitium is seeded as a standalone recursive resolver instead of reconfiguring production Unbound.

Notes:

  • The stack binds only to TECHNITIUM_BIND_IP, so PD must have that secondary address present on LAN_INTERFACE before docker compose up.
  • The helper script adds the pilot IP alias read/write on the live host for the current boot only. That is deliberate for pilot safety.
  • Technitium reads the environment initialization only on first boot when /etc/dns is empty. If you need to re-seed initial settings, stop the container and clear the config directory first.
  • SSO-capable deployments should set the DNS_SERVER_SSO_* variables. Keep a known local admin account as rollback because Technitium may only apply initial auth/env seeding cleanly on first boot or with an empty /etc/dns config dir.
  • For native Authentik OIDC on this pilot, DNS_SERVER_SSO_ALLOW_SIGNUP must be true at least for the initial SSO user provisioning. Keeping DNS_SERVER_SSO_ALLOW_SIGNUP_ONLY_FOR_MAPPED_USERS=true preserves the gate so only users in mapped Authentik groups can auto-provision.
  • Authentik native OIDC callback for Technitium is https://dns.paccoco.com/sso/callback.
  • For Authentik native OIDC, the Technitium OAuth2 provider must have the default OpenID scope mappings attached: openid, email, and profile. Without them, Authentik will mint a token with no OpenID scopes and Technitium fails the /application/o/userinfo/ call with Scope mismatch / SSO authentication failed.
  • The authoritative zone home.paccoco.com is now hosted in Technitium with dns.home.paccoco.com -> 10.5.30.8.
  • Clients will resolve dns.home.paccoco.com only when they query Technitium directly, or after DHCP/cutover points them at Technitium.
  • bin/sync_backup_nodes.sh is the PD-side replication runner that pushes the live Technitium config to the Nomad (10.5.30.9) and Serenity (10.5.30.10) backup nodes, then recycles those backup stacks and verifies DNS answers.
  • Preferred automation model: root cron on PD every 15 minutes, logging to /mnt/tank/docker/appdata/technitium-pilot/logs/sync-backup-nodes.log.