truenas-stacks/technitium-pilot/README.md

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 stack is no longer just a side-by-side pilot. It is the active DNS source of truth, and the old Pi-hole service/VIP path has been retired.

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 now resolve dns.home.paccoco.com through the Technitium trio because the Pi-hole VIP path has been retired.
• 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 both a private authoritative answer and a public recursive answer.
• Active automation model: root cron on PD runs the sync every 15 minutes from /mnt/docker-ssd/docker/compose/technitium-pilot, logging to /mnt/tank/docker/appdata/technitium-pilot/logs/sync-backup-nodes.log.
• External fallback 9.9.9.9 keeps general internet DNS available if the Technitium trio is down, but it is not a substitute for the private home.paccoco.com zone.
• Because the pilot and backup nodes use macvlan IPs, same-host DNS probes can fail even when the resolver is healthy for real clients; verify from another LAN host when checking node health.