DNS accumulates records faster than anyone removes them, and a CNAME pointing at a decommissioned cloud resource is a subdomain takeover waiting to be found by someone else. This inventory makes stale records visible.
What you get
A record register with purpose and owner per entry
A dangling-record check specifically for takeover risk
Mail authentication records tracked separately, since they break differently
Registrar and nameserver details, including who can make changes
How to use this template
1
Record the purpose of every entry. A record whose purpose nobody knows cannot be safely removed, so it stays forever and the zone becomes unmaintainable. Backfill purposes during the first pass.
2
Check CNAMEs resolve to something you still control. A CNAME pointing at a deleted cloud resource can be claimed by anyone who registers that resource name, giving them a valid subdomain of yours. Verify every external CNAME target is still yours.
3
Track who can change DNS. Registrar and DNS provider access is among the most dangerous access you hold: it can redirect mail and issue certificates. List who has it and review that list as carefully as domain admin.
What's inside
Here's a preview. Unlock the free download to get all 4 sections (3 more below).
Certificate expiry is the most predictable outage there is, and it still happens constantly, usually on an internal service nobody realised had a certificate at all. This tracker covers those as deliberately as the public ones.
Network documentation fails because it is written once, as a project deliverable, and then diverges from reality within a quarter. This template is scoped to the things that change slowly and are expensive to rediscover at 02:00.
The risk in decommissioning is rarely the shutdown; it is the dependency nobody knew about and the data nobody checked for. This checklist front-loads both, and ends with the licence and backup cleanup that pays for the exercise.
A record (usually a CNAME) pointing at a resource that no longer exists, such as a deleted cloud app or storage bucket. If someone else can register that resource name, they control a valid subdomain of your domain, which is a subdomain takeover.
How do you prevent subdomain takeover?
+
Remove the DNS record before deleting the resource it points at, make DNS cleanup a step in your decommission checklist, and verify quarterly that every external CNAME target is still something you control.
Why track SPF DNS lookups?
+
SPF permits a maximum of ten DNS lookups during evaluation. Exceeding it causes a permanent error and SPF failure for all your mail. Each `include:` consumes lookups, so adding one marketing tool too many can silently break deliverability.