DNS Security: How Attackers Exploit Your Domain Configuration

Before an attacker sends a single HTTP request to your application, they have already read your DNS zone. Five minutes of passive enumeration reveals which cloud providers you use, who manages your email, which CDN sits in front of your traffic, and which subdomains have been abandoned. All of it from public data, without authentication, without leaving a trace in your logs.

DNS functions as a public registry of your infrastructure. MX records expose your email provider, CNAMEs reveal cloud services, TXT records enumerate every authorized third party, and stale entries hand subdomains to whoever claims them first. DNS is the last layer most defenders monitor. It is the first one attackers read.

DNS Records Are a Public Registry of Your Infrastructure

A single passive DNS enumeration session exposes your cloud stack, email provider, CDN, and third-party vendor relationships before triggering a single SIEM alert. MITRE ATT&CK documents this technique as T1590.002, noting its routine use by tracked threat actors during pre-exploitation reconnaissance.

MX records are the most informative starting point. A record pointing to aspmx.l.google.com confirms Google Workspace; protection.outlook.com confirms Microsoft 365. Proofpoint and Mimecast have equally recognizable patterns. The attacker knows, before any contact with the application, which email platform to target.

CNAME records map cloud services precisely: a destination ending in amazonaws.com identifies AWS and often the region; azurewebsites.net confirms Azure App Service; fastly.net and cdn.cloudflare.net identify CDN providers. NS records reveal the DNS provider and zone structure — information useful for social engineering and domain transfer attacks. A records map IP ranges to hosting providers without active scanning. Tools like OWASP Amass and Subfinder perform subdomain enumeration routinely in bug bounty programs using certificate transparency logs and passive DNS brute-force. All of this is accessible before any scan touches the application.

Zone Transfers: One Query, Every Record

A misconfigured AXFR converts a single unauthenticated DNS query into a full zone dump. CVE-1999-0532, classified as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), describes exactly this: DNS servers permitting zone transfers without access controls. The vulnerability is over twenty-five years old and remains misconfigured in a meaningful fraction of enterprise environments — periodic Shodan scans consistently surface public resolvers that respond to AXFR.

NIST SP 800-81-2 (2013) recommends restricting zone transfers to authorized secondary nameservers as a baseline DNS hardening control. The protocol was designed for replication between authoritative DNS servers, not public query. The command is straightforward:

dig axfr target.com @ns1.target.com

If the server is misconfigured, the response contains every record type: A, AAAA, MX, CNAME, TXT, SRV, PTR. It is the equivalent of reading the organization's complete infrastructure inventory. Naming conventions reveal purpose immediately: payroll.example.com, vpn.example.com, staging.example.com, internal-api.example.com.

DNS configurations are rarely audited with the same frequency as firewalls or WAFs. That audit gap is why a vulnerability documented in 1999 persists in enterprise environments in 2025. The fix is to restrict zone transfers exclusively to authorized secondary NS servers.

Stale Records Turn Forgotten Subdomains into Attack Platforms

When DNS records outlive the services they reference, attackers claim the abandoned resource and inherit the trust associated with the subdomain. In 2024, this pattern evolved into a supply chain attack vector affecting Fortune 500 companies and government agencies.

SentinelOne flagged over 1,250 subdomain takeover risks in 2024 from deprovisioned cloud resources, plus an additional 650 instances from other sources in the same period. From October 2024 to January 2025, researchers identified approximately 150 deleted AWS S3 buckets still referenced by active DNS records that received more than 8 million requests. Those requests included fetches for container images, binaries, and SSL VPN configurations. Anyone who registered those buckets could serve malicious content from a trusted FQDN belonging to real organizations.

HackerOne #1089502 documents the pattern in the 8x8 case: deleted S3 bucket, DNS CNAME not removed, subdomain claimable by anyone who registered the deleted bucket name. HackerOne #272357 is the more instructive case. The domain email.bitwarden.com had a CNAME pointing to a Mailgun namespace. After Bitwarden ended that integration, the namespace became available for third-party registration. Anyone who registered that Mailgun namespace could send email originating from email.bitwarden.com, with full domain credibility to recipients. Bitwarden removed the record after disclosure. The pattern repeats in any organization that does not include DNS cleanup in service decommissioning processes.

A DNS record's lifecycle must match the lifecycle of the service it references. Microsoft documents CNAMEs pointing to Azure services as the most prevalent dangling DNS vector. The problem is not technical: it is process. Services are decommissioned, buckets deleted, SaaS contracts ended, and the corresponding DNS records simply remain.

Cache Poisoning: The Problem Kaminsky Fixed and SADDNS Reopened

Zone transfers and passive DNS reading exploit what your DNS reveals; cache poisoning exploits what your users trust it to say.

DNS cache poisoning was considered solved after Dan Kaminsky's 2008 disclosure. SADDNS, published in 2020 by researchers from Purdue University and Tsinghua University, demonstrated that ICMP side-channels bypass source port randomization, leaving recursive resolvers exploitable more than a decade after the supposed fix.

Kaminsky's attack exploited DNS resolvers by sending forged responses for nonexistent subdomains. For each nonexistent subdomain queried, the resolver issued a new query, giving the attacker unlimited attempts to guess the correct transaction ID and inject a forged response. The adopted defense was source port randomization: 65,536 ports multiplied by 65,536 TXIDs produce about 4.3 billion combinations, impractical to brute-force.

SADDNS exploited ICMP packet rate-limiting as a side-channel to infer which UDP port the resolver was using for a specific query. That side-channel reduces the search space to approximately 65,536 attempts — exactly the quantity the post-Kaminsky defense was meant to make impractical. The impact of a successful poisoning is amplified by the recursive model: every client of that compromised resolver receives forged responses until the cache expires. DNSSEC solves the problem correctly, but adoption remains low. Most resolvers still rely on source port randomization that SADDNS demonstrated is breakable by off-path attackers.

TXT Records: The Metadata Layer Attackers Read Before You Do

SPF, DMARC records, and domain verification tokens collectively expose your authorized email stack, every third-party vendor relationship, and occasionally authentication tokens. All of this in a single DNS query, without authentication. The paper "TXTing 101" (IEEE EuroSP 2020) documented the long tail of security issues in TXT records, including API keys and authentication tokens accidentally published in production zones during manual verification processes.

An SPF record like v=spf1 include:amazonses.com include:sendgrid.net ~all immediately reveals two email relay providers. include: chains create inherited authorizations: a domain included in your SPF that is later compromised or abandoned grants that third party send authorization from your domain. The DMARC record exposes your monitoring vendor via rua=mailto:[e-mail], identifying the email security partner precisely.

Verification tokens confirm platform integrations: Google Site Verification, Facebook Domain Verification, Stripe, Atlassian, and Adobe all publish recognizable tokens as TXT records. The "TXTing 101" paper found that 37% of TXT records in the Alexa top 1M contain vendor relationship data usable as pretext in targeted phishing campaigns. A researcher crafts a spear-phishing email specific to "your Stripe partner" because the TXT record confirmed you use Stripe.

Stale SPF include: chains are the most dangerous case: the included domain can be claimed by a third party, granting them send capability from your domain.

DNS Change Monitoring Is the Earliest Signal Defenders Have

Every new DNS record represents a new attack surface. Organizations that monitor DNS changes detect shadow IT, subdomain takeover attempts, and phishing infrastructure before any defensive layer closer to the application registers activity. MITRE ATT&CK maps passive DNS monitoring to data source DS0029 (Network Traffic) under technique T1590.002 (DNS).

The highest-risk changes follow recognizable patterns: a new CNAME pointing to a claimable cloud namespace, a new MX record delegating to an unexpected external provider, an NS delegation change, a TXT record added with an unfamiliar verification token. Passive DNS feeds correlate historical resolution data: a domain that resolved to your IP six months ago and now points elsewhere may have been silently transferred. Changes appear in passive DNS databases within hours. Attackers monitor these feeds actively.

Red Canary documents that passive DNS monitoring surfaces retroactive compromise evidence when domains later classified as malicious appear in historical resolution logs. Defenders who maintain that history can identify patient zero and the blast radius of a compromise days or weeks after the fact. Every new CNAME is a new cloud service and a new attack surface. Every new TXT record is a new vendor relationship and a new phishing angle. Every NS delegation is a new application without an audit trail.

The DNS analysis module at intel.mago.team applies passive DNS enumeration as part of its reconnaissance pipeline. The same techniques attackers use are applied defensively to monitor your domain footprint and detect record changes before they become incidents.

You do not need a zero-day to read a target's DNS zone. You need dig, five minutes, and a public nameserver. MITRE documents this activity as T1590.002, HackerOne pays bounties for stale records, and security researchers found 8 million requests flowing to dead subdomains of Fortune 500 companies. The question is not whether attackers enumerate your DNS. The question is whether your team reads your DNS records with the same frequency and intent as your adversaries.