DNS Architecture and Resolution

DNS separates public authority from private infrastructure naming. Cloudflare serves aorxi.io publicly; the target Technitium deployment serves core.aorxi.io internally. OPNsense provides temporary resolution until the Technitium cutover passes its Phase A10 tests.

Technitium Is a Phase A10 Target

The final DNS VMs are not part of the live Phase A2 bootstrap state. Site A first proves DHCP and DNS through OPNsense, then deploys sa-dns-01 and sa-dns-02 during Phase A10. Site B DNS and cross-site replication wait for the later Site B and WireGuard campaigns.

Namespace and Authority

Namespace	Visibility	Authority	Purpose
`aorxi.io`	Public internet	Cloudflare	Public records and DNS-01 certificate challenges
`core.aorxi.io`	Homelab clients only	Technitium	Infrastructure forward and reverse records

core.aorxi.io is a subdomain of the public domain, but its infrastructure records remain private. Technitium performs full recursive resolution from root servers rather than forwarding queries to an upstream resolver.

Resolver Lifecycle

Stage	Client resolver	Change boundary
Site A target-LAN commissioning	Local OPNsense VLAN interface	Prove DHCP, DNS, NAT, and isolation before moving endpoints
Site A Phase A10	`10.10.30.10` and `10.10.30.11`	Change DHCP DNS options only after Technitium replication and failover pass
Future Site B target	`10.20.30.10` and `10.20.30.11`	Keep client queries local to Site B
Future cross-site operation	Local resolver pair at each site	Use WireGuard for zone replication and controlled updates, not routine client queries

OPNsense Unbound remains available during the Site A resolver transition and is disabled only after the Technitium path is verified.

Target DNS Nodes

Hostname	Site	Address	Authority role
`sa-dns-01`	Site A	`10.10.30.10`	Primary and single write endpoint
`sa-dns-02`	Site A	`10.10.30.11`	Read-only secondary
`sb-dns-01`	Site B	`10.20.30.10`	Read-only secondary
`sb-dns-02`	Site B	`10.20.30.11`	Read-only secondary

All four nodes use VLAN 30 (VM Services). Records are authored on sa-dns-01; it notifies the secondaries, which transfer forward and reverse zones with AXFR. Local clients query their site's pair.

Resolution and Update Flows

Flow	Path	Dependency
Site A client query	Client → `sa-dns-01` or `sa-dns-02`	Site A VLAN policy
Site B client query	Client → `sb-dns-01` or `sb-dns-02`	Site B VLAN policy
Local zone replication	`sa-dns-01` → `sa-dns-02`	Site A VM Services reachability
Cross-site zone replication	`sa-dns-01` → `sb-dns-01` and `sb-dns-02`	WireGuard and narrow DNS rules
DHCP dynamic update	OPNsense → `sa-dns-01`	Tested RFC 2136 integration
Kubernetes record update	`external-dns` → `sa-dns-01`	Deployed cluster and scoped update credentials

Tunnel Failure Degrades Freshness, Not Local Resolution

If WireGuard is unavailable, Site B resolvers continue serving their last replicated zones. New or changed Site A records do not appear at Site B until the tunnel returns.

Certificate Boundary

Let's Encrypt certificates use DNS-01 challenges in the public Cloudflare aorxi.io zone. Challenge TXT records never depend on the private Technitium zone, so internal services can receive publicly trusted certificates without publishing their private A or AAAA records.

Implementation References

This page defines resolution and authority. The DNS VMs page owns VM sizing, zone and replication configuration, dynamic updates, and firewall ports. The DNS Deployment and Cutover Runbook owns installation, validation, rollback, and the DHCP option change. Certificate resources belong to CA and Certificates. The DHCP and IPAM Operations page owns resolver option assignment, while the Network Validation Runbook defines DNS acceptance evidence.