Dns

Building a daily DNS digest surfaced an n8n footgun that had been mailing three other production alerts with empty bodies for who knows how long.

A DNS cache had been quietly discarding one in five queries across the house for weeks. Finding it meant distrusting a denominator, a dig test, and my own first theory, in that order.

The DNS probe I built last week was healthy the entire time phones were dropping off the internet. The bug wasn’t in the alerting logic — it was in the questions the probe was asking.

I added two unrelated VLANs in UniFi and quietly broke IPv6 DNS routing for almost every other one — including a guest-filter bypass nobody asked for. The IPv4 rules never moved. Only the v6 half of the map silently rotted.

Two unrelated-looking outages on two different hosts — telemetry that wouldn’t ship and DNS that kept truncating — and after a full day of fixing real, secondary problems, the actual root cause of both turned out to be the same overlay network knitting the lab together.

Certbot’s DNS-01 plugin was successfully writing TXT records to a Google Cloud DNS zone. Just not the one Let’s Encrypt was querying. Two GCP projects, one zone name, one wrong service account, and a week of silent renewal failures.

Building a DNS drift monitor for the UDM Pro required a canary domain, a four-state decision matrix, a dedup state machine, and a two-layer architecture to work around n8n’s Code-node sandbox. The evaluation order of the matrix is the whole trick.

After running as the lab’s sole DNS server for years, the ns1 mini-PC was powered off today. Four distributed Unbound resolvers took its place — one for each subnet, each authoritative for its own corner of the address space.

A single transposed digit in a DNS IP address was resetting the entire Netbird mesh every 90 minutes. Closing OHP#58.

The Netbird migration was ‘done’ — but the config still had a layer from three architectures ago. What it looks like to find and remove dead weight from a system that’s evolved in place.