DNS Security: What Your Domain Configuration Reveals to Attackers

Introduction

Every domain name on the internet broadcasts a surprising amount of information to anyone who asks. DNS -- the Domain Name System -- is inherently public. It has to be: the entire system depends on resolvers around the world being able to query your records and route traffic to the right servers.

The problem is that most organizations treat DNS as plumbing. Records get created during initial setup, third-party services add verification tokens, infrastructure changes leave behind stale entries, and nobody ever goes back to audit what the zone file actually says. Meanwhile, attackers treat your DNS as the first chapter of a detailed reconnaissance report.

Before a single packet touches your firewall, an attacker can learn your hosting provider, your email platform, your CDN, every third-party SaaS product you use, and sometimes the internal structure of your network. All of this information is available through simple, unauthenticated DNS queries that generate no alerts and leave no logs on your systems.

What DNS Records Tell Attackers

Each DNS record type serves a legitimate purpose, but each one also leaks information that attackers use to plan their approach.

A and AAAA Records

A records map your domain to IPv4 addresses. AAAA records do the same for IPv6. These are the most basic records, and they immediately reveal your hosting provider and server geography. An IP address in AWS's us-east-1 range tells an attacker you are on AWS in Northern Virginia. An IP in the Cloudflare range tells them you are behind a CDN, which changes their approach. A direct IP pointing to a smaller hosting provider might suggest less sophisticated infrastructure.

Attackers cross-reference these IPs against known ranges, check for other domains hosted on the same IP (reverse DNS), and scan those addresses for open ports and services.

MX Records

Mail exchange records expose your email infrastructure completely. If your MX records point to aspmx.l.google.com, you are on Google Workspace. Records pointing to mail.protection.outlook.com mean Microsoft 365. Self-hosted MX records pointing to your own IP range tell attackers exactly where to aim phishing infrastructure and email-based attacks.

This matters because each email platform has different security characteristics, different authentication flows, and different known vulnerabilities. Knowing the platform lets attackers tailor their social engineering precisely.

TXT Records

TXT records are the most information-dense records from a reconnaissance perspective. SPF records explicitly list every IP address and service authorized to send email on your behalf. A typical SPF record might include include:_spf.google.com include:sendgrid.net include:mailchimp.com, which tells an attacker that the organization uses Google Workspace for corporate email, SendGrid for transactional email, and Mailchimp for marketing campaigns.

Domain verification tokens are even more revealing. Services like Google, Atlassian, HubSpot, Salesforce, and dozens of others require you to add a TXT record to prove domain ownership. Each of these tokens follows a recognizable pattern (google-site-verification=, atlassian-domain-verification=, MS=), giving attackers a catalog of every SaaS platform your organization uses. That catalog becomes a target list for credential stuffing, phishing, and supply chain attacks.

CNAME Records

CNAME records create aliases, and they reveal your third-party dependencies. A CNAME from blog.example.com to example.ghost.io exposes your blogging platform. A CNAME from status.example.com to stats.uptimerobot.com shows your monitoring provider. Each CNAME is a link in your supply chain that attackers can investigate for weaknesses.

NS Records

Nameserver records identify who controls your DNS infrastructure. If all your NS records point to a single provider, that provider becomes a single point of failure. Attackers also check for nameserver misconfigurations -- lame delegations where an NS record points to a server that does not actually serve your zone, which can sometimes be exploited.

The Subdomain Takeover Risk

Dangling CNAME records represent one of the most underappreciated risks in DNS security. The scenario is straightforward: your team sets up a service on Heroku, creates a CNAME from app.example.com to example-app.herokuapp.com, and everything works. Six months later, the Heroku app gets decommissioned, but nobody removes the CNAME record.

Now app.example.com points to a Heroku hostname that no longer exists. An attacker discovers this, creates a new Heroku app claiming that hostname, and suddenly controls the content served at app.example.com. They can host phishing pages, serve malware, or set cookies scoped to your parent domain -- all under your legitimate domain name.

This vulnerability affects dozens of services: AWS S3 buckets, Azure resources, GitHub Pages, Shopify stores, Fastly CDN endpoints, and many more. Each platform handles unclaimed hostnames differently, but the pattern is the same -- a CNAME pointing to a resource that the attacker can claim. For an in-depth look at detection and prevention strategies, read our guide on subdomain takeover prevention.

Attackers find these dangling records through two primary methods. First, certificate transparency (CT) logs record every TLS certificate ever issued for your domain and its subdomains. Monitoring these logs gives attackers a comprehensive subdomain list to check. Second, brute-force enumeration using wordlists of common subdomain names (dev, staging, api, app, mail, vpn) uncovers subdomains that may not appear in CT logs.

Zone Transfer Vulnerabilities

DNS zone transfers (AXFR) are a replication mechanism designed to let secondary nameservers pull a complete copy of your zone file from the primary server. When zone transfers are left open to the public -- which happens more often than you would expect -- anyone can request the complete zone file with a single command:

dig @ns1.example.com example.com AXFR

A successful zone transfer hands the attacker every record in your zone: every subdomain, every internal hostname, every IP address, every service mapping. It is the equivalent of giving an attacker a complete network map. Internal subdomains like jenkins.internal.example.com or vpn-admin.example.com that were never meant to be discovered become immediately visible.

Testing is simple. Run the command above against each of your nameservers. If you get back a list of records instead of a "Transfer refused" message, you have a problem. The fix is equally simple: configure your nameservers to restrict AXFR to authorized secondary nameserver IPs only.

DNSSEC: Cryptographic Verification

Standard DNS has no authentication mechanism. When your computer queries a DNS resolver for the IP of bank.example.com, it trusts whatever answer comes back. DNS cache poisoning attacks exploit this by injecting forged responses into resolver caches, redirecting users to attacker-controlled servers without changing a single record on your authoritative nameservers.

DNSSEC (Domain Name System Security Extensions) solves this by adding cryptographic signatures to DNS responses. Each record is signed with a private key, and resolvers can verify the signature using the corresponding public key published in the DNS hierarchy. If an attacker tampers with a response, the signature verification fails and the resolver rejects it.

Despite being standardized for over a decade, DNSSEC adoption remains frustratingly low. The reasons are practical: key management adds operational complexity, misconfiguration can make your domain completely unresolvable, and the signing process increases response sizes. However, the protection against cache poisoning attacks is significant, and modern DNS providers have made enabling DNSSEC considerably easier than it once was. For a step-by-step guide to enabling DNSSEC and deploying CAA records, see our DNSSEC and CAA records setup guide.

Practical Steps to Lock Down Your DNS

Securing your DNS does not require exotic tools or deep expertise. These concrete steps address the most common exposures.

Audit and remove stale records regularly. Schedule quarterly reviews of your zone file. For every CNAME, verify that the target still exists and is under your control. For every A record, confirm the IP is still yours. Remove anything that is no longer in use. Stale records are the primary cause of subdomain takeovers.

Disable zone transfers to unauthorized hosts. Configure your nameservers to only allow AXFR requests from your secondary nameserver IPs. Test from an external network to confirm transfers are refused.

Enable DNSSEC. If your registrar and DNS provider support it, enable DNSSEC. Most major providers now offer one-click enablement. Test with tools like dnsviz.net to verify your chain of trust is correctly configured.

Monitor certificate transparency logs. Use a CT monitoring service to receive alerts when any certificate is issued for your domain or subdomains. Unexpected certificates indicate either a subdomain takeover or unauthorized certificate issuance.

Deploy CAA records. Certificate Authority Authorization records specify which certificate authorities are permitted to issue certificates for your domain. Adding a CAA record like 0 issue "letsencrypt.org" tells all compliant CAs that only Let's Encrypt should issue certificates for your domain. This limits an attacker's ability to obtain fraudulent certificates.

Review TXT records for information disclosure. Remove domain verification tokens for services you no longer use. Consider whether each TXT record is still necessary. Every verification token and SPF include entry is intelligence for an attacker. Reducing your WHOIS footprint is equally important -- our domain registration and WHOIS hygiene guide covers privacy settings and registrar best practices.

How CyberShield Helps

CyberShield's posture scan automates the checks described in this article. When you run a scan against your domain, it tests for open zone transfers, verifies DNSSEC deployment and chain-of-trust integrity, checks nameserver redundancy and configuration, identifies dangling CNAME records that are vulnerable to takeover, and enumerates subdomains through certificate transparency logs to map your full attack surface.

Rather than performing these checks manually across multiple tools, a single CyberShield scan gives you a prioritized view of your DNS security posture with specific remediation guidance for each finding. Run your first scan and see what your domain is broadcasting.