In August, I migrated nine domain names to a new registrar: the NES Studio website and the eight domains of my media titles. A routine operation, which nonetheless caused a week-long outage on some domains and, more importantly, taught a broader lesson.
The outage
During the transfer, several domains served a parking page instead of their website. Discovered by chance, less than 24 hours later. On another domain, a DNS security key that had become inconsistent made the domain unreachable: the only corrective action was in the hands of the outgoing registrar. Neither of the two expected outcomes happened; the outage resolved itself when the transfer carried the key across.
The mistake avoided
So as never again to discover this kind of outage by chance, I wrote a tool that declares the intended state of each DNS zone and compares it with reality every day. First version: the tool read the live DNS and took it as the intended state.
That was correct on 5 August, when everything worked. On the 6th, some domains had moved to the new registrar: their live DNS was the parking page. The tool would have copied the failure, declared it as the target, and the drift detector would then have confirmed every day that everything was compliant.
A tool that derives its target from what exists is only reliable while what exists is healthy.
Two principles that follow
The intended state is written, never derived. What must be true is declared by a human and versioned, and reality is compared against it, not the other way round.
Compare the thing, not its shape. Two email signing keys had exactly the same length and completely different fingerprints. A key is compared by its fingerprint, an address as an address. Most false alarms come from surface comparisons, and a tool that cries wolf stops being read.
Beyond DNS
The same mistake threatens every AI project that “learns from what exists”: an agent that derives good practice from your current data will also learn your anomalies. Before automating, write down what must be true.