The January Infrastructure Audit — A Checklist for Everything You've Been Ignoring

Infrastructure rots quietly. Domains creep toward expiry on cards that expired first, DNS zones accumulate records pointing at servers that were decommissioned in July, backups run nightly and have never once been restored, and three people who left the company still have API keys that work. None of it pages you — until the one day it does, spectacularly. January is the natural time to pay this debt down: the holiday freeze is over, the roadmap hasn't consumed everyone yet, and a single focused afternoon now prevents a remarkable share of the year's dumbest outages. Here's the audit, item by item.

Everything with an expiry date

Start with the failures that come with a countdown attached, because they're the most preventable things in this entire post:

• Domain registrations. List every domain you own — including the defensive registrations and the one marketing bought for a campaign in 2023 — and check the expiry dates. An expired domain isn't an outage; it's a hostage situation, sometimes with a grace period, sometimes with a drop-catcher on the other end.
• The payment card on the registrar account. Auto-renew is only as reliable as the card behind it, and cards expire on their own schedule. Check the actual card. This single line item has taken down companies you've heard of.
• TLS certificates. Inventory every certificate: apex domains, subdomains, mail servers, internal tools with public certs. Confirm each one has automated renewal and independent expiry monitoring watching what's actually served. This matters more this year than last — maximum certificate lifetimes drop to 200 days this March under the CA/Browser Forum's new rules, so renewals are about to get twice as frequent. We covered the full timeline in 47-day certificates are coming.
• Everything else with a date. API keys with built-in expiry, OAuth app credentials, code-signing certs, that annual license the invoicing depends on. Put every date you find into one shared calendar with reminders at 30 and 7 days.

DNS record inventory — kill the stale records

Pull the full zone file for every domain and read it line by line. It's tedious, and it's worth it:

# export a zone for review (or use your DNS provider's export)
dig @your-dns-provider example.com AXFR
# no zone transfer? walk your provider's dashboard and export to CSV

For each record, answer one question: does the thing this points at still exist? You're hunting for:

• Dangling CNAMEs — the big one. A CNAME pointing at a deprovisioned cloud resource (old-app.azurewebsites.net, a deleted S3 bucket website endpoint, a cancelled SaaS vendor's subdomain) is an open invitation to subdomain takeover: an attacker registers the abandoned resource name, and suddenly your subdomain serves their content — with your domain's credibility, and often your cookies' scope. Delete every CNAME whose target you can't account for.
• A and AAAA records pointing at released IPs. Cloud IPs get recycled to strangers. A forgotten staging.example.com pointing at an IP you released in June now points at whoever has it today.
• Stale MX, SPF and DKIM entries — old mail providers still listed in SPF widen who can send mail as you; delete what you no longer use.
• Mystery records nobody can explain. Every zone has them. Track down each one; the answer is either documentation or deletion.

While you're in there, note what your critical records should be — because next year's audit is much faster when there's a documented baseline to diff against.

Registrar and DNS account security

Your registrar account is the skeleton key to everything — whoever controls it controls your DNS, which means your traffic, your email, and your password resets:

• Two-factor authentication on, and not SMS if avoidable — TOTP or hardware keys on the registrar, the DNS provider, and the CA account.
• Contact emails that actually work. Registrars send renewal and transfer warnings to the account email. If that's an ex-employee's address or a defunct distribution list, warnings go into the void. Check WHOIS/RDAP contact data while you're at it.
• Domain transfer lock enabled, and registry lock for the crown-jewel domain if your registrar offers it.
• Who has access? If the answer includes "the agency we stopped working with in 2024," fix that today.

The backup restore test

A backup you haven't restored is a hope, not a backup. Once a year, minimum, prove the whole loop:

• Restore to a fresh environment — new VM or container, from backup media alone, no peeking at production. You're testing the backup and the documentation and whether the encryption keys are somewhere a survivor can find them.
• Verify the data, not the exit code. Row counts in key tables, a handful of known records, the most recent orders. Backup jobs are notorious for exiting 0 while producing empty or truncated dumps.
• Time it. The restore duration is your real recovery time. If it's nine hours and your assumptions say one, better to renegotiate with reality in January than mid-incident.

Monitor coverage review

Monitoring drifts out of sync with reality in one direction: things get launched, and monitors don't. Walk through everything that went live last year — the new API, the microsite from the autumn campaign, the second region, the status-page-worthy internal tool — and ask what's watching it. The most common finding is a service that has never been monitored because it shipped in a hurry and "we'll add monitoring later" evaporated. The second most common: monitors still faithfully checking things that were decommissioned, generating noise that trains people to ignore the channel. Add the missing, delete the dead.

Access review

Last, the people and the keys:

• Offboarded humans. For everyone who left last year: registrar, DNS, cloud console, CI, monitoring, the shared 1Password vaults. Deactivate what's still active — and rotate any credential they knew that can't be deactivated, especially shared passwords.
• Old API keys and tokens. List every long-lived credential — deploy keys, CI tokens, webhook secrets, database passwords — and for each: is it still used, when was it rotated, what's the blast radius if it leaked? Kill the unused ones; rotate anything older than your policy allows (and if there's no policy, this audit is where one starts).
• Service accounts with human-sized privileges. The cron user that somehow has admin on everything is a breach multiplier. Scope it down.

Make it annual, make it boring

Copy this list into a doc, date-stamp what you checked and what you fixed, and put a recurring reminder in the calendar for next January — the second year takes half the time because you're diffing against a known baseline instead of archaeology. And for everything on this list with a date or a downtime attached, put a machine on it: CompleteStatus monitors domain expiry, certificate expiry and DNS records year-round, and alerts you by email, Slack, Discord, Telegram or webhook when something drifts — so the audit becomes confirmation, not discovery.

Create a free account and start with the two items that end companies: domain expiry monitoring and certificate expiry monitoring. Ten minutes now, and January-you has already made this the year the boring disasters didn't happen.