Phase 2: internal DNS and the bootstrap chicken-and-egg
Standing up an authoritative internal resolver as code — split-horizon, encrypted upstreams, and the moment the new DNS box couldn't resolve its own installer.
Nothing resolves until DNS is up, so it’s the first real service in the rebuild. I gave it a dedicated VM and a self-hosted authoritative resolver, configured entirely through its API from an Ansible role.
Split-horizon, on purpose
My public domain stays where it belongs — at the registrar, serving the world. The resolver becomes authoritative only for a private internal subdomain, answering homelab hostnames from its own zone and forwarding everything else upstream. Before flipping anything I pulled the public zone read-only and checked what actually lived under that subdomain publicly: exactly one record, which I deliberately left alone. Split-horizon only bites you when you forget something it now shadows.
The chicken-and-egg
I’d configured the new box to use itself for DNS. Correct end state — useless during install, because the resolver it points at isn’t running yet, so it can’t even resolve its own package downloads. The fix is a throwaway upstream resolver just for the install window, after which the installer hands resolution to the local service and the loop closes. Bootstrap order is a feature you design, not an accident you discover.
Encrypt the upstreams
Recursion goes out over DNS-over-TLS to two independent providers, not plaintext UDP to one. Two so a single provider hiccup doesn’t take resolution with it; encrypted so the path between me and them isn’t an open postcard.
Your resolver sees every site you visit. Don’t hand that to the network in clear text, and don’t trust it to a single upstream.
One honest gotcha: my own workstation still resolves via the gateway, so it kept “helpfully” answering with a stale lease — the box’s own loopback query was the only trustworthy witness. The cutover itself is deliberate and staged, lowest-risk network first. Next phase: identity and secrets.