dns
Resolution, wildcards, split horizons, and the failures that return success.
-
Probing the Names You Publish, Not the Services You Run
A service that checks only its own process health can report perfectly healthy while nobody outside it can reach it at all. This covers why external, black-box probing against the published name catches an entire class of failure that internal health checks structurally cannot, with a complete blackbox_exporter setup that runs on a laptop.
-
DNS Wildcards and Empty Non-Terminals: The Answer That Is Not an Error
A stale ACME DNS-01 TXT record can turn part of a domain into an empty non-terminal, and RFC 1034's wildcard rule then refuses to cover it — not as a bug, but as specified behaviour. This walks through the closest-encloser algorithm behind that refusal, reproduces it with a BIND container and a small zone file, and gives a script and a record-lifecycle pattern that catch the problem before it reaches production.
-
Overlay Mesh Networking with NetBird: Peer Addressing and the Public DNS Fallthrough
An overlay mesh gives every machine a stable address and a direct encrypted path to every other one, replacing a hub-and-spoke VPN. It also gives internal hostnames a silent way to resolve to the wrong place the moment the mesh resolver is not in the loop. This walks through why, and includes a runnable DNS setup that reproduces the fallthrough and the one-line fix that closes it.
-
ndots and the Accidental Search-Domain Leak in Pod DNS
Kubernetes gives every pod a DNS search list and ndots:5 by default, which is usually harmless. Add a custom internal domain to that search list and it stops being harmless: an ordinary external hostname can resolve through the internal domain's own records before it is ever tried as written. Here is why, and three ways to close it off.
-
A DNS Canary CronJob as a Regression Test for Split-Horizon Resolution
A pod's search domain or CoreDNS configuration can resolve a public name to an internal blackhole, and once that bug is fixed it tends to come back the next time someone touches the Corefile for an unrelated reason. This walks through a CronJob that resolves a small, deliberate set of names on the exact path real pods use, so the regression fails a Job instead of a customer's request.
-
Managing a Shared DNS Zone Through a Replace-Everything API
Many registrar and DNS provider APIs expose only "replace the whole zone", with no way to add or remove a single record, so naive automation that computes its desired records and pushes them deletes every record it does not know about. This builds a read-merge-write client with an ownership marker that tells apart managed and unmanaged records, backed by a small local test server so the whole pattern can be run and verified without any real registrar.