Keeping records of which site sits where

Assume your register is already wrong somewhere, because it does not decay evenly. A few rows go stale within hours of an incident while the rest stay accurate for years, and nothing in the file marks which is which. Reconciliation is the habit of asking the live systems what they hold today, then treating every disagreement as a finding rather than a typo.

Where the drift comes from

Every one of these is a normal working day, not negligence:

• The emergency edit. Something breaks at an awkward hour, you move a site onto whichever account is healthy, service returns, and the temporary arrangement quietly becomes permanent.
• The diagnostic relocation. While isolating a fault you park a property elsewhere to see whether the problem follows it. It does not, you find the real cause, and nobody moves the site back because it works fine where it is.
• The renewal that changed hands. A domain renews on a card or an account that is not the one written down, usually because the original instrument expired and somebody rescued the name in a hurry.
• Somebody else's change. A developer swaps nameservers to put a delivery network in front, or adds a subdomain on a different host, and nothing in your process ever sees it.
• Provider-side reshuffles. Plans get renamed, accounts consolidated, an address reissued. Your row is unchanged and now describes something that no longer exists.

Why a confident wrong row beats a blank one for damage

A gap produces a small, safe behaviour: whoever needs the answer goes and looks. A filled cell ends the enquiry, and the reader acts without ever forming the thought that it might be false. That is how somebody cancels a server believing it holds only retired staging work, or edits a zone in a panel that stopped being authoritative a year ago. It also compounds: assignment, capacity and neighbourhood decisions all get built on the bad row, so a late correction means unwinding every judgement that quoted it.

Check against the system that cannot misremember

Pull each fact from the place responsible for it, never from a second copy of your own notes.

Diff in both directions. A register entry with no counterpart in any account is a ghost row. A live account, address or zone with no row is an orphan, and orphans hold the real surprises. Clear the registrar findings first, since those carry a deadline; ownership records are covered under domains.

A cadence you will actually keep

1. Within two days of any unplanned change. The highest yield habit by far. An incident is not closed until the affected rows say what is true now.
2. Monthly, fifteen minutes. Only the machine readable lists: domains, accounts, addresses, users. Diff the exports and change nothing else.
3. Quarterly. The volatile technical facts: resolution, delegation, certificate coverage.
4. Annually. The full pass, marker file test included. Budget about two minutes per site after the first run.

Stamp each row with the date it was last confirmed and by which method; an unstamped row is a rumour with formatting. When a check disagrees with the sheet, decide which side is wrong before editing either, because the correct repair is sometimes to move the site rather than the record. If the disagreement points at a fault rather than a bookkeeping slip, work it through diagnostics first.