How to Audit Your Company's External DNS Footprint

To audit external DNS footprint effectively, you must systematically discover, document, and analyze every public-facing DNS record, authoritative name server, and delegated zone associated with your organization. This process uncovers forgotten subdomains, shadow IT, and dangling CNAME records that leave your infrastructure vulnerable to takeover attacks. Neglecting this part of your attack surface management often results in threat actors exploiting misconfigured or abandoned public DNS entries.

Why External DNS Auditing Matters

Your external DNS footprint is the complete set of publicly accessible DNS records that point the world to your web servers, mail exchangers, cloud buckets, and applications. Attackers map this footprint before launching targeted campaigns. If you have legacy records pointing to decommissioned third-party SaaS providers, bad actors can claim those external resources and intercept your traffic or brand reputation.

An effective audit goes beyond checking your primary domain name. It encompasses all corporate acquisitions, marketing campaigns, historical subdomains, and SPF/DKIM validation records. By utilizing utilities like the NS Lookup tool on XiaTools, you can quickly query specific name servers and verify what the public internet sees regarding your hostnames, making it easier to spot anomalous entries.

Step 1: Enumerate Authoritative Name Servers

Before gathering individual records, you need to identify which name servers are authoritative for your domain apex. Misconfigurations here can lead to cache poisoning, amplification attacks, or zone tampering.

Open your terminal and use dig to query the NS records for your target domain, replacing example.com with your organization's domain:

dig NS example.com +noall +answer

Sample output:

example.com.      3600    IN      NS      ns1.example-dns.net.
example.com.      3600    IN      NS      ns2.example-dns.net.

Verify that these name servers match your authorized DNS hosting provider. If you find unfamiliar name servers or legacy providers you no longer use, your domain registrar account may have stale delegations.

Step 2: Comprehensive Record Harvesting

Next, you need to pull every standard record type (A, AAAA, MX, TXT, CNAME, SRV) to build a complete inventory. Avoid relying solely on zone transfers (AXFR), as modern authoritative servers block zone transfers by default to prevent reconnaissance.

Instead, query individual record types using standard command-line tools:

# Query IPv4 addresses
dig A example.com +noall +answer

# Query mail exchangers
dig MX example.com +noall +answer

# Query TXT records (SPF, DMARC, Domain verification)
dig TXT example.com +noall +answer

# Query IPv6 addresses
dig AAAA example.com +noall +answer

# Query Service records
dig SRV _sip._tls.example.com +noall +answer

For Windows administrators, nslookup provides a direct interactive or single-line alternative:

nslookup -type=ANY example.com

Note: Many modern DNS providers truncate ANY queries to mitigate DDoS vectors. Always query specific record types for reliable enumeration.

Step 3: Subdomain Discovery and Enumeration

Subdomains represent the largest vector for forgotten assets. Development environments, staging portals, and old marketing campaigns are often left publicly accessible long after their expiration.

To discover subdomains:

1. Search Certificate Transparency (CT) Logs: Attackers and auditors alike query public certificate logs because organizations must submit TLS certificates to public logs when generating them. Sites like crt.sh or automated scripts can parse these logs.
2. Brute-Force Dictionaries: Run wordlists of common prefixes (api, dev, staging, vpn, mail, test, internal) against your base domain using reliable network testing frameworks.

Step 4: Identify Dangling CNAMEs and Subdomain Takeovers

A dangling CNAME occurs when a subdomain points to an external service provider (such as GitHub Pages, AWS S3, Heroku, or Azure) that has been provisionally deleted or released, but the DNS record remains active.

If deleted-bucket.s3.amazonaws.com returns a NoSuchBucket error, an attacker can register that exact bucket name on AWS and instantly hijack legacy.example.com to host malicious content under your trusted domain name.

Step 5: Check Email Authentication and TXT Footprint

Your external footprint includes text-based records designed to protect your email deliverability and brand integrity. Validate your SPF, DKIM, and DMARC implementations to ensure unauthorized parties cannot spoof your domain.

Run a check for your DMARC record:

dig TXT _dmarc.example.com +noall +answer

Sample output:

_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com;"

Ensure your policy (p=) is set to quarantine or reject rather than none to fully enforce protection against email spoofing.

Common Mistakes and How to Fix Them

• Mistake 1: Forgetting internal IPs leaked via public records. Sometimes administrators map private RFC 1918 addresses (like 192.0.2.55) into public DNS records.
  • Fix: Purge internal-only hostnames from public zones to prevent giving network architects a blueprint of your internal topology.
• Mistake 2: Leaving TTLs extremely high during migrations. Setting your Time-To-Live (TTL) to 86400 seconds (24 hours) right before a service migration causes extended downtime.
  • Fix: Lower your TTLs to 300 seconds at least 48 hours before planned architectural changes.
• Mistake 3: Neglecting IPv6 (AAAA) records. Securing your IPv4 footprint while ignoring IPv6 leaves unmonitored pathways into your perimeter.
  • Fix: Audit AAAA records with the same rigor applied to A records.

External DNS Audit Checklist

• Inventory all authoritative name servers and registrar accounts.
• Export all A, AAAA, MX, TXT, and SRV records for the domain apex.
• Harvest subdomains using certificate transparency logs and wordlists.
• Cross-reference all CNAME targets to ensure external service buckets or apps still exist under your ownership.
• Verify SPF, DKIM, and DMARC posture via TXT queries.
• Document all orphaned or dangling records and remediate immediately.
• Establish automated monitoring to alert on newly created public DNS records.

By executing this workflow regularly, you maintain complete visibility over your external perimeter, block potential subdomain takeover vectors, and harden your organization's overall cybersecurity posture.