DNS Audit Checklist: Find Stale Records, Security Gaps, and Misrouted Traffic

Overview

When someone asks, “How do I audit my DNS records?”, the first step is not to delete old entries. It is to establish what the domain is supposed to do and compare that intended design with the records currently published.

Start by recording the domain, its registrar, the authoritative nameservers, the DNS hosting service in use, and the people or systems responsible for changes. DNS may be managed at the domain registrar, by a separate managed DNS provider, or through a hosting platform. Confirming this boundary prevents a common error: editing a zone that is not authoritative for the domain.

Next, export or copy the current DNS zone into a review worksheet. For each record, capture the name or host, type, value, TTL, purpose, owner, and proposed action. The core record types to review are:

• A: Maps a hostname to an IPv4 address, often for a website or application.
• AAAA: Maps a hostname to an IPv6 address. An outdated IPv6 destination can create inconsistent access if some networks prefer IPv6.
• CNAME: Aliases one hostname to another. It is common for subdomains connected to hosted services.
• MX: Identifies the mail servers that receive email for the domain.
• TXT: Stores text-based instructions and verification data, including email authentication records.
• CAA: Defines which certificate authorities may issue certificates for the domain, when this control is used.

Also document the SOA and NS records, including the authoritative nameservers. A record inventory is only useful when every entry has a known purpose. If nobody can explain why a record exists or which service owns it, mark it for investigation rather than assuming it is safe to remove.

Checklist by scenario

Routine DNS record review

• List every active hostname, including the root domain, www, development environments, staging systems, portals, APIs, and legacy subdomains.
• Match each A, AAAA, and CNAME record to a current server, platform, application, or documented business function.
• Check for duplicate or conflicting records that could send users to different destinations.
• Look for hostnames pointing to services that have been retired, renamed, or moved.
• Confirm that records for development and test environments are clearly labeled and access-controlled where appropriate.
• Record the owner and planned action for every unexplained entry.

Before moving a website or hosting provider

• Identify the current A, AAAA, and CNAME records used by the production website.
• Confirm the destination values supplied by the new host and verify them through the provider’s documentation or control panel.
• Check whether the new platform requires additional verification, redirect, CDN, or subdomain records.
• Reduce TTLs only when there is a defined migration window and a plan to restore them afterward. Lower TTLs do not instantly remove cached answers.
• Keep email-related MX and TXT records unchanged unless the email service is also being migrated.
• Test the website, redirects, forms, APIs, and certificate coverage after the change.

For a broader migration sequence, use this cloud hosting migration checklist. If the change includes moving the registration itself, review the guidance on how to transfer a domain without downtime or losing email.

After an email or DNS security review

• Confirm that MX records point only to the intended email provider.
• Review SPF TXT records for obsolete senders, accidental duplicates, or services no longer used.
• Check DKIM records and verify that selectors belong to active email systems.
• Review DMARC policy and reporting destinations, if configured, and make sure the responsible team receives and understands the reports.
• Inspect CAA records, if used, and compare them with the certificate issuance process.
• Check whether DNSSEC is enabled, whether the signing status is healthy, and whether the registrar has the expected delegation information.

Use a documented managed DNS process for changes, with access controls, backups or exports, and a rollback plan. The managed DNS setup guide provides useful context for organizing these controls.

What to double-check

Nameservers: Query the domain from outside the provider dashboard and compare the observed authoritative nameservers with the ones recorded at the registrar. If they differ, changes made in the wrong dashboard will not affect the live zone.

Dangling subdomains: A CNAME or other alias can remain after a hosted service is closed. Check every alias with its service owner. Remove or replace records that point to an abandoned resource, but verify ownership before acting because a temporary failure can look similar to an unused record.

IPv6 paths: Review AAAA records as carefully as A records. A website may appear healthy from one network while failing from another if the IPv6 destination is old or unavailable.

Wildcard records: A wildcard can answer for previously undefined subdomains. Confirm that this behavior is intentional and does not expose an unexpected application or create confusing routing during a migration.

TTL and propagation expectations: Record the TTL for important entries and communicate that resolvers may retain earlier answers until their cached values expire. Plan validation over an appropriate period rather than treating one successful lookup as proof that every user sees the new destination.

Delegation and DNSSEC: Check the parent-level delegation and the zone’s signing configuration together. If DNSSEC is enabled, changing nameservers or signing details without a coordinated plan can make a domain difficult to resolve.

Common mistakes

• Deleting before identifying: An old-looking TXT record may support email authentication or a service verification process. Assign an owner and confirm its purpose first.
• Changing nameservers and records at the same time: This makes troubleshooting harder because it is unclear whether the problem is delegation, zone content, caching, or the hosting service.
• Ignoring email during a website migration: A web hosting change does not necessarily require MX changes. Altering mail records unnecessarily can interrupt delivery.
• Keeping undocumented emergency records: Temporary failover and verification entries should have an expiry date, owner, and removal condition.
• Relying on a single lookup: Check from more than one network or resolver and test the actual service, not only the DNS response.
• Allowing unrestricted access: Limit who can edit the registrar and DNS provider, enable available account protections, and retain a record of approved changes.

Keep the final worksheet with the domain portfolio documentation. Ownership, renewal, and expiration controls are covered in the domain portfolio management guide.

When to revisit

Run a focused DNS review before a website launch, hosting migration, email provider change, certificate process change, or major application release. Repeat the review after a domain transfer, nameserver change, security incident, or unexplained routing problem.

For routine operations, schedule a quarterly or otherwise documented review based on the number and sensitivity of your domains. Revisit sooner when team responsibilities change, a provider retires a workflow, or new subdomains are introduced. At each review, update the record owner, purpose, TTL, last-checked date, and approved action.

The practical completion test is simple: another qualified administrator should be able to open the worksheet, understand where DNS is managed, explain every important record, identify the approved production destinations, and follow a rollback plan. If they cannot, the audit is not finished. Resolve the unknowns, document the decision, and only then make the next DNS change.