DNS is the layer of internet infrastructure that translates domain names into addresses. Security issues at the DNS layer can undermine controls deployed at higher layers: HTTPS, email authentication, and subdomain isolation all depend on DNS behaving as intended. Misconfigurations in DNS records are often invisible to site owners because they do not produce errors that affect normal site operation.
This article covers the DNS conditions that affect web security, how each one creates exploitable risk, and what remediation looks like for each.
DNS as an Attack Surface
DNS attacks fall into a few broad categories: attacks on the DNS infrastructure itself (cache poisoning, resolver compromise), attacks that exploit misconfigured zone data (dangling records, overly permissive NS delegation), and attacks that exploit the absence of DNS-based authentication records (missing SPF, DKIM, DMARC).
WebDefect audits the zone data for the scanned domain rather than attempting to attack the DNS infrastructure. The checks cover record configurations that are directly controllable by domain owners and that have known security implications.
Dangling DNS Records
A dangling DNS record is one that points to a hostname, IP address, or service that is no longer claimed by the organization. The record is still valid DNS: it resolves correctly. But the destination it resolves to is now claimable by a third party.
CNAME records that point to cloud platform hostnames are the most common source. When a Heroku app, Netlify site, or GitHub Pages deployment is decommissioned, the CNAME record often remains. Until it is removed, an attacker can claim the target hostname on that platform and serve content under the original subdomain.
A records pointing to released IP addresses are a related issue. Cloud providers recycle IP addresses from deprovisioned instances. If a domain points an A record at an IP that was previously assigned to a cloud instance you operated, and that IP is later assigned to another customer, requests to your domain are served by that customer's infrastructure.
Remediation: Audit all DNS records and remove any that point to services no longer under organizational control. Build record removal into deprovisioning procedures. The full mechanics of subdomain takeover are covered in the subdomain takeover article.
Missing Email Authentication Records
SPF, DKIM, and DMARC are three DNS record types that together implement domain-based email authentication. Their absence allows any mail server on the internet to send email that appears to come from your domain, with no technical barrier to prevent it.
SPF (Sender Policy Framework) is a TXT record that lists the mail servers authorized to send email from your domain. A missing SPF record means there are no declared authorized senders, and receiving mail servers have no SPF policy to enforce.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing email, signed with a private key held by the sending server. The public key is published in a DNS record. Receiving servers verify the signature to confirm the message was sent by a server in control of the private key. DKIM protects against message tampering in transit as well as spoofing.
DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together into a policy that receiving servers can enforce. DMARC tells receiving servers what to do with messages that fail SPF or DKIM alignment: allow them, quarantine them, or reject them. A DMARC record with p=none only requests reports and does not enforce any action.
All three are required. SPF alone does not prevent spoofing of the From header. DKIM alone without DMARC does not prevent spoofing. DMARC without properly configured SPF and DKIM policies does not enforce alignment. The article on SPF, DKIM, and DMARC covers the configuration requirements and verification in detail.
Wildcard DNS Records
A wildcard DNS record (for example, *.example.com A 192.0.2.1) matches any subdomain not covered by a more specific record. Wildcard records are used for routing all subdomains to a single application that handles the routing internally, which is a legitimate pattern.
The security implication is that any subdomain that is not explicitly excluded resolves to the wildcard target. This can mask dangling records (a CNAME for a specific subdomain takes precedence over the wildcard), but it can also mean that a subdomain that should not exist or should return NXDOMAIN instead silently resolves. Tools that enumerate subdomains and check for NXDOMAIN as a signal of non-existence will produce incorrect results for domains with wildcards.
If a wildcard is used intentionally, ensure the application handling wildcard subdomains does not expose unexpected functionality for arbitrary subdomain values, and verify that known sensitive subdomains are explicitly listed in DNS rather than relying on the wildcard.
Zone Transfer Exposure
DNS zone transfers (AXFR queries) are used to replicate zone data from primary to secondary name servers. If a name server is configured to allow zone transfers from any IP, any party can query the full contents of the DNS zone, including all hostnames, subdomains, mail server configurations, and internal infrastructure hints.
Zone transfers should be restricted to the IP addresses of secondary name servers only. Most modern DNS hosting providers do not expose AXFR publicly. The issue is more common on self-managed BIND or PowerDNS installations where the default configuration may be permissive.
To test whether a name server allows unrestricted zone transfers:
dig AXFR example.com @ns1.example.comA correctly configured name server will return REFUSED or a connection error. A misconfigured one will return the full zone contents.
DNS Over HTTP and Subdomain Enumeration
DNS over HTTPS (DoH) and DNS over TLS (DoT) are protocols that encrypt DNS queries, preventing network-level observation of which domains a user is resolving. From a server configuration standpoint, this affects logging and monitoring more than it affects the attack surface described in this article.
One DNS-adjacent security consideration is DNS-based subdomain enumeration. Attackers use wordlists to brute-force subdomains by querying for common names. This is a passive reconnaissance activity that requires no access beyond the ability to make DNS queries. The practical defense is to ensure that subdomains that exist are secured, rather than attempting to prevent discovery. A subdomain that exists but has no security controls is a risk regardless of whether it is enumerated by an attacker.
What WebDefect Checks in DNS
WebDefect's DNS phase includes the following checks:
- SPF record presence and syntax: Whether a valid SPF TXT record exists at the root domain. Records with syntax errors or multiple SPF records (which invalidates the configuration per RFC 7208) are flagged.
- DMARC record presence and policy strength: Whether a
_dmarc.example.comTXT record exists and whether the policy isnone,quarantine, orreject. Ap=nonepolicy is flagged as a finding because it does not prevent spoofed mail from being delivered. - DKIM selector discovery: WebDefect attempts to discover common DKIM selector names (
default._domainkey,google._domainkey, and others). The absence of any discoverable DKIM selector is recorded as a finding. - Dangling CNAME detection: CNAME targets are checked against known cloud platform namespaces and tested for unclaimed-resource response fingerprints.
- Zone transfer: AXFR queries are sent to discovered name servers to check whether they permit unrestricted zone transfers.