Files

T

root 76185d7294 H8: Fix stale docs — model chain + schedule table

- model-chain.md: updated to Aug 8 with 18-model expansion verification
- New models documented: claude-sonnet-4-6, claude-opus-4-8, claude-fable-5,
  gemini-2.5-flash/pro, xai/grok-4.3, gpt-5, gpt-5-mini
- Fixed gemini-3.6-flash → gemini-flash-latest in key model lists
- backup-plan.md: Dawarich/RAGFlow added to schedule table (H6 follow-up)
- Server specs verified accurate (12 vCPU, 31 GB, 1 TB on app1)
- UniFi verified live (302 → /manage)

2026-08-08 18:37:26 -04:00

2.7 KiB

Raw Blame History

Redundant DNS Path — Proposal

Status: Proposal (not yet executed) Date: 2026-08-08

Current State

Technitium DNS runs on app2 (152.53.39.202), listening on port 53 TCP+UDP on all interfaces. It serves as authoritative DNS for internal zones. The admin panel is at dns1.itpropartner.com.

Key finding: All ITPP servers (Core, app1, app2, app3) use Tailscale MagicDNS (100.100.100.100) for their resolv.conf. This means internal server-to-server resolution is NOT dependent on Technitium. If app2 goes down, ITPP servers still resolve DNS via Tailscale.

What does depend on Technitium:

External clients querying zones hosted on Technitium (if any zones delegate to it)
Potentially home lab devices or WISP equipment configured to use it as their resolver
The dns1.itpropartner.com web admin UI

Proposed Solution: Secondary Technitium on Core

Technitium DNS supports zone transfers (AXFR). The simplest redundancy path:

Deploy a secondary Technitium container on Core
- Container: technitium-secondary
- Port: 5353 (TCP+UDP) — avoid conflicting with anything using port 53 on Core
- Configure zones as secondary/slave, pulling from primary at 152.53.39.202:53
Configure zone transfers from app2 → Core
- On primary (app2): add Core's IP as an authorized AXFR client
- On secondary (Core): set zone type to "Secondary" with primary IP 152.53.39.202
Optional: Add dns2.itpropartner.com DNS record
- Point to Core's IP
- Clients can use dns1 (app2) and dns2 (Core) as their name servers

Cost

Zero additional cost. Core already has sufficient resources (2.9/16 GB RAM used, 4 vCPU).
Technitium runs in Docker, ~100MB RAM at idle, negligible CPU.

Effort

~30 minutes to deploy and configure zone transfers
~15 minutes to verify zone replication
No downtime on primary

Risks / Caveats

Core is already your highest-load server. Adding another service increases blast radius if Core goes down.
Technitium zone transfer config is manual. New zones created on primary must be manually added to secondary (or use the "Allow Zone Transfer for All Zones" option).
This is secondary DNS, not failover. Clients must be configured with BOTH dns1 and dns2 to benefit. If a client only has dns1, app2 goes down → DNS still fails.

Recommendation

If Technitium is currently used by home lab devices or WISP equipment as their sole resolver, deploy the secondary. If it's only used for internal zone hosting and no clients depend on it for resolution, defer this until there's a demonstrated need.

If deploying: I'd put it on app1 instead of Core. app1 has 16GB RAM (currently ~8GB free based on Docker host) and doesn't have the same "Core must stay up" criticality.

2.7 KiB Raw Blame History