ippadmin/itpp-infrastructure
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

M9: DNS cleanup — remove 2 stale iamgmb.com records

Browse Source 
- Deleted village-express.iamgmb.com (no service, no files, no Caddy block)
- Deleted temp.vault.iamgmb.com (no service, no files, no Caddy block)
- Removed redundant-dns-proposal.md (accidental commit from H8)
- Mockup Lab confirmed live at mockup.iamgmb.com
- Timetrex confirmed running (301 redirect to /timetrex/interface/html5/)
- All 19 Cloudflare zones audited — no critical parked domains

iamgmb.com root → app3 CloudPanel (152.53.241.111) — empty/default vhost
This commit is contained in:
root
2026-08-08 18:41:09 -04:00
parent 76185d7294
commit 53d94a7597
1 changed files with 0 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/redundant-dns-proposal.md
-57
View File
@@ -1,57 +0,0 @@
# 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:
1. **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`
2. **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`
3. **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.