What Is a DNS Audit and Why It Matters

The Domain Name System (DNS) is a foundational pillar of the internet, translating human-readable domain names into the IP addresses that machines use to communicate. Despite its critical role, DNS is often overlooked in security assessments, leaving websites and networks vulnerable to a range of attacks including spoofing, cache poisoning, and Distributed Denial of Service (DDoS) amplification. A DNS audit systematically examines your domain’s DNS records, zone files, and provider configurations to uncover misconfigurations, obsolete entries, and security gaps. Performing a regular audit is not a one-time task; it is an essential discipline for any organization that values uptime, email deliverability, and trust.

Without an audit, you may be unknowingly exposing your infrastructure. For example, an unsecured MX record can allow attackers to forge email from your domain, damaging your reputation and enabling phishing campaigns. An outdated A record pointing to a decommissioned server can be hijacked and used to host malware. A missing DMARC policy means anyone can spoof your email. Each of these scenarios is preventable with a thorough DNS audit followed by corrective action. The process requires no special equipment — only a basic understanding of DNS record types, a few reliable tools, and a methodical approach.

Anatomy of a DNS Audit: What You’re Really Checking

A complete DNS audit goes beyond simply listing records. It verifies correctness (records point to the intended targets), completeness (no missing security records), consistency (no conflicting data across authoritative nameservers), and hardening (use of modern security extensions). You will examine each record type and the surrounding infrastructure — nameservers, glue records, TTLs, and the registrar lock status.

Record Types That Demand Attention

Every DNS zone contains at least a few standard record types. Here are the ones you must scrutinize:

  • A and AAAA records — These map your domain to IPv4 and IPv6 addresses. Ensure they point to current, active servers, and not to abandoned IPs you no longer control. An old A record can be used by attackers to claim your domain via a reverse IP lookup.
  • MX records — These handle email routing. Misconfigured MX records can cause mail to be delivered to the wrong servers or not at all. Verify that the priority values make sense and that the hosts accept mail for your domain.
  • TXT records — Most security policies live here: SPF, DKIM, DMARC, and domain verification strings. SPF must include only servers authorized to send mail. DKIM signatures should be valid and match your mail flow. A DMARC policy of “none” offers no protection — you should aim for “quarantine” or “reject”.
  • CNAME records — Ensure they don’t create circular dependencies or point to external domains you no longer own. An orphaned CNAME to a deleted SaaS platform can allow subdomain takeover.
  • NS records — Check that your domain’s nameservers are correct and that they are authoritative for your zone. Unequal NS records across providers can cause intermittent resolution failures.
  • SOA record — The Start of Authority contains the primary nameserver, contact email, and timing values. Verify that the refresh and retry intervals are appropriate (too short can overload servers; too long delays propagation of fixes). A stale SOA can indicate zone management issues.

Zone Transfer and DNSSEC Checks

A less common but critical check is whether your DNS server allows unauthorized zone transfers (AXFR/IXFR). If enabled publicly, anyone can download the entire contents of your zone, including internal hostnames that reveal your network architecture. Use tools like dig axfr @nameserver example.com from an external network to test. If it succeeds, immediately restrict zone transfer to authorized secondary servers.

Also verify that DNSSEC (Domain Name System Security Extensions) is enabled and properly configured. DNSSEC uses cryptographic signatures to ensure that record responses have not been tampered with. Without it, attackers can forge responses and redirect users to malicious sites (cache poisoning). Check that your registrar supports DNSSEC, that you have published DS records in the parent zone, and that your nameservers serve valid RRSIG records. Many DNS providers now enable this with a single toggle, but it’s still worth auditing manually.

Common DNS Vulnerabilities That Audits Uncover

Understanding what you’re looking for helps focus the audit. Below are the most prevalent DNS security issues, each with real-world impact.

DNS Spoofing and Cache Poisoning

Without DNSSEC, an attacker who controls a recursive resolver or sits on the network path can inject false DNS responses. Your users would be directed to a fake website without knowing. This is a classic man-in-the-middle attack vector. DNSSEC is the only comprehensive defense.

Open DNS Resolvers

If your DNS server is configured to answer queries from any IP (an open resolver), it can be used in amplification DDoS attacks. Attackers send a small query with a spoofed victim IP, and the resolver sends a much larger response to flood the victim. Check that your authoritative nameservers only respond to queries for domains they serve, and that recursive resolvers are either not exposed or are limited to your internal networks.

Subdomain Takeover

When a CNAME or NS record points to an external service that has been decommissioned (e.g., a cloud load balancer, a CDN, or a GitHub Pages site), an attacker can register that service and gain control of your subdomain. This can lead to phishing or malware distribution under your trusted brand. The audit must identify all external A and CNAME targets and verify they still belong to you.

Email Spoofing and Phishing

Missing or misconfigured SPF, DKIM, and DMARC records make it trivial for attackers to send emails that appear to come from your domain. DMARC policies should be at least p=quarantine and ideally p=reject after a monitoring period. Without DKIM, email receivers cannot verify that the message content was not altered in transit.

Domain Hijacking

If your registrar account is compromised or your domain is not locked, an attacker can change the NS records and redirect all traffic. Setting a registrar lock (also called transfer lock) and using strong authentication on your registrar account are basic defenses. The audit should confirm that the registrar lock is enabled and that your account contact information is up to date.

Step-by-Step Guide to Performing a DNS Audit

Follow this structured process. You can use command-line tools (dig, nslookup, whois) or online platforms such as MXToolbox and DNSChecker. Both approaches are valid; choose the one that fits your technical comfort and automation needs.

1. Enumerate All DNS Records

Start by pulling the full zone. Use dig any or AXFR (if allowed) for a complete list. Manual checks for each record type can also be done:

  • dig A example.com
  • dig AAAA example.com
  • dig MX example.com
  • dig TXT example.com
  • dig CNAME sub.example.com (for each subdomain you care about)
  • dig NS example.com
  • dig SOA example.com

If you have many subdomains, consider using a tool like Subfinder or DNSRecon for automated enumeration. Document every record in a spreadsheet or configuration management file.

2. Validate Each Record’s Target and Purpose

For every A/AAAA record, ensure the IP corresponds to an active server under your control. Use whois to check the IP ownership if unsure. For MX records, test that each mail server accepts connections on port 25 and that they are not blacklisted (use MXToolbox Blacklist Check). For TXT records, verify SPF syntax using a tool like spf-tools — common mistakes include missing include mechanisms, exceeding the 10-DNS-lookup limit, or missing an allow for your ESP. For DKIM, check that the public key in the TXT record matches the private key used to sign emails. DMARC validation tools can parse the policy and suggest improvements.

3. Check for Orphaned Records

Compare your DNS records against your asset inventory. Any record pointing to a service you no longer use (a decommissioned cloud instance, a retired mail server, a sunset CDN) should be flagged for removal. Orphaned records are the primary source of subdomain takeovers. If you find a CNAME to deleted-application.herokuapp.com or similar, delete it immediately.

4. Review TTL Values

Time-to-Live (TTL) determines how long a record is cached by resolvers. Too short a TTL (e.g., 30 seconds) increases query load; too long (e.g., 1 month) impedes incident response. As a general rule, set TTLs between 300 and 3600 seconds for production records, and reduce them to 60 seconds before a planned change, then restore the original value after propagation. The audit should catch any abnormally high or low TTLs.

5. Test Zone Transfer Security

Run dig axfr @ns1.example.com example.com from an external IP. If you receive the zone data, this is a critical vulnerability. Restrict AXFR to authorized secondary nameservers only (using allow-transfer bind statements or equivalent).

6. Confirm DNSSEC Validity

Use a tool like Verisign DNSSEC Analyzer to check your domain’s DNSSEC chain. It will tell you if signatures are present, whether the DS record matches the DNSKEY, and if any records are expired. Fix any errors by contacting your DNS provider or regenerating keys if needed.

7. Verify Registrar Lock and Contacts

Log into your registrar panel and confirm that transfer lock (or registry lock) is enabled. Also check that the administrative and technical contact email addresses are correct and monitored. These contacts receive expiration and abuse notifications; if they go stale, you may lose your domain without notice.

How to Fix Common DNS Security Vulnerabilities

Once your audit reveals issues, prioritize fixes based on severity. Below are remediation steps for the most frequent findings.

Enabling and Configuring DNSSEC

If DNSSEC is missing, ask your DNS provider to sign your zone. The process typically involves generating a Zone Signing Key (ZSK) and a Key Signing Key (KSK), and publishing DS records at your registrar. After enabling, use the Verisign analyzer mentioned above to verify the chain. While DNSSEC adds some operational overhead (key management), the security benefit against spoofing is immense.

Correcting SPF, DKIM, and DMARC

Rewrite your SPF record to include only authorized servers. Use the include: mechanism for third-party services and ~all (softfail) or -all (hardfail) at the end. For DKIM, generate a 2048-bit key pair, place the public key in a TXT record under selector._domainkey.example.com, and configure your mail server to sign with the private key. Set a DMARC record with p=quarantine and rua=mailto:[email protected] to receive aggregate reports. Gradually move to p=reject after confirming no legitimate emails are being blocked.

Removing Orphaned CNAME or A Records

Delete records that point to deprovisioned external services. If you need to preserve the subdomain for historical reasons, redirect it to a controlled landing page via your own infrastructure. Regularly re-scan subdomains using automated tools to catch new orphans.

Hardening DNS Servers

If you operate authoritative nameservers directly, disable recursion (unless intentionally running an internal resolver), restrict zone transfers via IP allow lists, and disable DNS version disclosure. Use a firewall to allow only necessary traffic (UDP/TCP 53). Consider using a managed DNS provider who handles these configurations for you.

Implementing Registrar Lock and Strong Authentication

Enable transfer lock and use two-factor authentication (2FA) on your registrar account. If your registrar supports it, also enable registry lock (a higher level of protection that requires manual approval from the registry for any changes). Keep your account email secure and monitored.

Building a Long-Term DNS Security Practice

A single audit is not a set-and-forget exercise. DNS configurations change as you add subdomains, switch providers, or decommission servers. Adopt these habits to maintain a secure posture.

Schedule Regular Audits

Run a full DNS audit quarterly, and do a quick check after every infrastructure change that involves new hostnames or services. Automated scripts can alert you to deviations from a baseline; consider using an infrastructure-as-code approach where DNS records are managed via version-controlled files.

Use Monitoring and Alerting

Set up monitoring for DNS resolution failures, MX blacklisting, and certificate expiration tied to your domain (TLS certificates often rely on DNS validation). Many DNS providers offer health checks; external services like DNSOps can provide ongoing scanning.

Limit DNS Access and Logging

Only grant DNS modification access to administrators who need it. Enable query logging on your authoritative servers to detect unusual patterns (e.g., a sudden high volume of queries for a specific record may indicate abuse).

Stay Updated on DNS Threats

The DNS threat landscape evolves. Follow resources like the OWASP DNS Security Cheat Sheet for current best practices. New extensions such as DANE (DNS-based Authentication of Named Entities) may become relevant as they gain adoption.

Conclusion

Performing a DNS audit is a straightforward but high-impact security practice. By methodically examining each record, testing for openness, validating DNSSEC, and checking your registrar settings, you can eliminate the most common attack vectors that compromise domains today. The effort required is small compared to the cost of a successful breach, a hijacked domain, or a damaged reputation from email spoofing. Make the first audit happen this week, then schedule the next as a recurring calendar entry. Your DNS infrastructure will become a strong asset rather than a weak link in your security posture.