Core Router #

Purpose #

The core router is the production network authority for each Deevnet site. It provides routing, firewall, DNS, DHCP, and gateway services for all substrate hosts.

graph LR
    A[Edge Router
unmanaged] <--> B[Core Router
managed] <--> C[Site Hosts]

Hardware Platforms #

Operating System #

Both core routers run OPNsense, providing a consistent firewall and routing platform across sites.

Roles #

Configuration Management #

Configured via the deevnet.net Ansible collection:

DNS: Unbound #

Three distinct collections, reconciled from inventory by the opnsense_dns role:

The API shape for Query Forwarding is not where you would look for it, verified on 25.7.10. These rows are not part of unbound/settings/get — that payload’s keys are general, advanced, acls, dnsbl, forwarding, dots, hosts, aliases, and forwarding is the use system nameservers toggle rather than a collection. Forward rows have their own endpoints and are wrapped in a dot object that backs both DNS-over-TLS and plain rows:

POST /api/unbound/settings/searchForward
POST /api/unbound/settings/addForward
POST /api/unbound/settings/setForward/<uuid>
POST /api/unbound/settings/delForward/<uuid>

body: {"dot": {"enabled": "1", "type": "forward",
               "domain": "...", "server": "...", "description": "..."}}

type must be forward. The default would attempt DNS-over-TLS against an authoritative server on port 53.

Changes land in the saved configuration only; the running resolver is not updated until POST /api/unbound/service/reconfigure.

Because these are forwards rather than referrals, the resolver never consults the tenant zone’s own apex records — see Naming and Addressing for what that changes.

DHCP: Kea #

Reservations are generated from inventory and keyed on each host’s declared hardware address, which makes the MAC load-bearing: a guest whose NIC does not carry its declared address does not match its reservation and silently receives a pool address instead. On the management segment the pool begins at .200, so that failure shows up as a host sitting somewhere in the .200+ range with no name pointing at it.

The platform segment has reservations only and no pool at all.

Authority Transition #

Per the Correctness Standard:

1. During initial provisioning, the bootstrap node provides DNS/DHCP
2. Core router is provisioned and configured via Ansible
3. Authority explicitly transitions to core router
4. Bootstrap node’s dnsmasq is disabled
5. Core router becomes the production DNS/DHCP server

This transition is explicit, not automatic. Running two DNS/DHCP authorities simultaneously will cause conflicts.