41 lines
3.6 KiB
Markdown
41 lines
3.6 KiB
Markdown
# 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 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.
|