Dns

A mis-typed IP address quietly turned one branch of the lab’s encrypted DNS into plaintext, and the only reason I found it was that I started shipping resolver logs the same day.

Retiring an abandoned container image across two fleets, teaching nginx to stop caching a container’s IP, and a research digest that mostly reported things fixing themselves.

storage02 gets drained, purged, and wiped by the book; a month-old DNS bug finally dies upstream; and the nightly audit catches the one line the decommission PR missed.

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.