How to Audit DNS Records You Inherited From Someone Else

To audit DNS records you inherited, you enumerate every record in the zone, map each one to the service that depends on it, and only then change anything. The goal is a complete inventory you understand, not a tidy-looking zone file, because the records that look obsolete are often the ones holding mail or a forgotten subdomain together.

Start by getting the zone out of the provider's control panel and onto your own disk. Whatever the interface, it should offer a zone file export or a plain text listing. Save that as your baseline before you touch a single record. If you cannot export, you can reconstruct most of it with dig, but a query only answers for names you already know exist, so it will miss the subdomains you have forgotten about.

Pull the Zone and Read the SOA First

Ask the authoritative nameservers directly rather than your resolver, so you see the zone as published and not a cached copy. Find the authority first, then query it.

dig +short NS example.com
dig @ns1.example.net example.com SOA +noall +answer

The SOA record tells you the primary nameserver, the responsible mailbox, and the serial number. That serial is your version marker: note it before and after any change. The refresh, retry, expire and minimum fields also matter, because a very long negative TTL means a mistake you make now will linger in resolvers long after you fix it.

How to Audit DNS Records Methodically

Walk the zone one record type at a time and write down, for each entry, what would break if it disappeared. That question is the whole audit. A record nobody can justify is a candidate for removal, but only after you have checked the dependency.

For A and AAAA records, resolve each name and see what answers. A host pointing at a load balancer or a provider's shared address may be doing real work even if the name looks stale.

dig +short www.example.com A
dig +short www.example.com AAAA
dig +short mail.example.com A

Mail is where inherited zones hurt most. Check the MX records and their priorities, then verify that every hostname an MX points to actually resolves and accepts connections on port 25. A dangling MX is worse than no MX, because senders will try it and fail.

Then inspect the sending policy. The TXT record at the root, or at a selector label, carries your SPF and DKIM data, and a second TXT at _dmarc carries the DMARC policy. Look at them as raw strings and count the lookups in any SPF record, since the protocol caps the number of DNS lookups a single evaluation may perform. Multiple SPF records on one name is a misconfiguration, not a redundancy, because receivers treat it as a permanent error.

dig +short example.com TXT
dig +short _dmarc.example.com TXT
dig +short selector1._domainkey.example.com TXT

CNAME records are the next trap. A CNAME cannot coexist with any other record on the same name, so a name that carries both a CNAME and a TXT is broken in a way that may only show up on some resolvers. Also check whether any CNAME chain loops back on itself, and whether the target still exists. Chained CNAMEs to a decommissioned service are common in inherited zones.

Do not skip NS and SRV. Delegated subdomains under NS records are separate zones that someone else may still control, and stale delegations are a takeover risk. SRV records point at services such as mail submission, calendar, or voice, and they often survive long after the service behind them was retired.

Finally, look for wildcards and for the TXT records used by domain verification. A wildcard A or CNAME will silently answer for every name you have not defined, which hides typos and can send traffic somewhere unexpected. Verification TXT records are harmless individually, but a pile of them from services nobody uses is clutter you can prune once you confirm the service is gone.

Validate Before You Change Anything

Once you have the inventory, check it against the live services rather than against your assumptions. Resolve every name from a resolver outside your own network, because split-horizon setups can make an internal view disagree with what the public sees. Check the TTL on each record: a low TTL means a fast rollback, a high one means a slow mistake.

Before editing, take the exported zone file and put it in version control. Then make changes in small batches, one record type at a time, and watch the authoritative servers pick up the new serial. Query the authority directly after each batch so you are not fooled by a cached answer.

dig @ns1.example.net example.com SOA +short
dig @ns1.example.net www.example.com A +short
dig +trace example.com | tail -n 20

Keep a written note of why each record exists. A comment beside every entry, even a one-line reason, turns the next audit from an investigation into a review. If you cannot state the reason, treat the record as suspect and test its removal rather than deleting it outright.

When you are ready to clean up, change one thing at a time and give it time to propagate before the next change. Lower the TTL on anything you plan to move well in advance, verify mail flow end to end after touching MX or policy records, and keep the old zone file until you are confident nothing regressed. The next step is to schedule this audit on a recurring basis, because zones drift as services are added and retired, and the inventory you build today is only accurate until the next change.