Files
truenas-stacks/technitium-serenity
Fizzlepoof 9e0f66c2b6
Some checks failed
secret-guardrails / artifact-secret-scan (push) Has been cancelled
secret-guardrails / gitleaks (push) Has been cancelled
docs: capture DNS resilience and Technitium backup sync
2026-05-24 02:49:23 +00:00
..
2026-05-24 00:15:58 +00:00

Technitium backup on Serenity

Backup Technitium DNS node cloned from the PD pilot for Serenity.

  • Repo stack path: /home/fizzlepoof/repos/truenas-stacks/technitium-serenity
  • Live stack path: /mnt/user/appdata/technitium-serenity
  • Bind IP: 10.5.30.10
  • DNS ports: 53/tcp, 53/udp
  • Web console: http://10.5.30.10/
  • Bootstrap domain if reset from empty config: technitium-serenity.home.paccoco.com

This backup node is an active DHCP-advertised backup resolver at 10.5.30.10. It is kept aligned from PD's live Technitium config and preserves both recursive DNS service and the private home.paccoco.com zone when PD is unavailable.

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.

  • Host interface parent for macvlan: br0

  • Operational note: this node is refreshed from PD by /mnt/docker-ssd/docker/compose/technitium-pilot/bin/sync_backup_nodes.sh, which root cron runs on PD every 15 minutes. Same-host checks from Serenity to 10.5.30.10 are unreliable because of macvlan isolation; verify from another host when testing health.