Every week, security teams get asked the same handful of DNS questions – often right after an incident, sometimes during an audit, occasionally during a coffee-break conversation that turns into a two-hour rabbit hole. This article pulls together the questions that come up most often around DNS security, subdomain takeover, and DNS record hygiene, and answers them the way an experienced administrator would explain them to a colleague – no jargon for the sake of jargon, just what actually matters and why.
Why DNS keeps showing up in security incidents
DNS was designed in the 1980s to solve a naming problem, not a security problem. That mismatch is the root of almost every issue discussed below. Every record you create – an A record, a CNAME, an SPF entry – is a promise that something specific controls that name. The moment that “something” changes hands or disappears, the promise becomes a liability.
A common scenario: a marketing team spins up a CNAME pointing a campaign subdomain like promo.company.com to a third-party landing page builder. The campaign runs for six weeks, gets great numbers, and everyone moves on. Eighteen months later, nobody remembers the subdomain exists, the landing page account has long since expired, and the CNAME is still sitting there pointing at a service that will happily hand that hostname to the next person who signs up. That’s a dangling DNS record, and it’s one of the most exploitable misconfigurations in modern infrastructure.
Is subdomain takeover really a serious threat, or is it overhyped?
It’s real, and it’s underreported rather than overhyped. A subdomain takeover happens when a DNS record points to an external service – a cloud host, a SaaS platform, a CDN – that no longer has the corresponding resource claimed. An attacker who notices this can register the same resource on that service and instantly control content served from your subdomain, on your domain’s reputation and cookies.
The damage isn’t theoretical: attackers use taken-over subdomains for phishing pages that look completely legitimate because the URL bar shows your real domain, for malware distribution, and for stealing session cookies scoped to the parent domain. The technical mechanics are covered in detail in a technical walkthrough of how these takeovers actually happen, but the short version is: it doesn’t require breaching your network, only finding a DNS record you forgot about.
What’s the most common misconception about DNS security?
The biggest myth is that DNS security is mostly about DNSSEC and preventing spoofed responses. DNSSEC matters, but in practice, the vast majority of real-world DNS incidents come from misconfiguration and abandonment, not from someone forging DNS responses in transit. Stale CNAMEs, forgotten test subdomains, expired cloud resources still referenced by active records, missing or misaligned SPF/DKIM/DMARC – these are the issues that show up in breach reports again and again, and they have nothing to do with cryptographic signing.
Another persistent myth: “we don’t have that many subdomains, so this isn’t really a risk for us.” Almost every organization underestimates its subdomain count. Between marketing campaigns, staging environments, partner integrations, and old acquisitions, mid-sized companies routinely discover two to five times more subdomains than they expected once they actually enumerate their DNS zone.
How often should DNS records actually be reviewed?
Annual reviews are common but insufficient. DNS changes constantly – a new subdomain gets created for a proof-of-concept, a cloud resource gets decommissioned, a vendor contract ends – and any of those events can create a security gap the same day. Waiting twelve months to catch that gap gives an attacker a very wide window.
A practical cadence looks like this: continuous automated monitoring for anything that changes DNS state (new records, resolution failures, ownership changes), combined with a deeper manual review on a quarterly basis to catch anything monitoring might miss, like misaligned SPF includes or DKIM keys nearing rotation. The reasoning behind favoring quarterly checks over a single annual audit is laid out well in this comparison of review cadences.
Do SPF, DKIM, and DMARC actually stop phishing?
They reduce it significantly, but only when configured correctly and enforced. SPF tells receiving mail servers which IPs are allowed to send mail for your domain. DKIM adds a cryptographic signature so recipients can verify a message wasn’t altered in transit. DMARC ties the two together and tells receiving servers what to do when a message fails – quarantine it, reject it, or do nothing.
The catch is that a huge number of domains have SPF records that are either too permissive (using “~all” instead of “-all,” or including third-party senders that no longer send mail) or a DMARC policy set to “p=none,” which does nothing but generate reports. Getting this stack right is one of the highest-leverage things a domain owner can do, and the step-by-step mechanics are covered in this breakdown of SPF and DKIM configuration.
What should a first DNS security check actually cover?
Start with an honest inventory. You cannot secure what you don’t know exists, and most organizations have more DNS records than their documentation suggests. A reasonable first pass covers:
Every A, AAAA, and CNAME record, cross-referenced against what actually resolves and what should still be active.
Every subdomain, including ones created for one-off tests, demos, or campaigns that were never formally decommissioned.
Email authentication records – SPF, DKIM, DMARC – checked for both presence and correct configuration, not just existence.
Any CNAME pointing to third-party services (cloud storage buckets, SaaS platforms, CDNs) that could be reclaimed if the underlying resource is gone.
A full walkthrough of this process, including which findings tend to be most severe, is available in the DNS security checklist for website owners.
Frequently asked questions
Can DNS monitoring prevent a subdomain takeover before it happens?
Yes, when it’s continuous rather than periodic. Takeovers exploit the gap between a resource being decommissioned and someone noticing the dangling DNS record. Continuous monitoring shrinks that gap from months to hours, which is usually enough to remove or reclaim the record before an attacker finds it.
Does having a small website mean DNS security doesn’t apply?
No. Attackers scan broadly for dangling records and misconfigurations regardless of company size, and a smaller site often has fewer people watching for problems, which makes it an easier target, not a safer one.
Is DNSSEC enough on its own to secure a domain?
No. DNSSEC protects the integrity of DNS responses in transit, but it does nothing about a dangling CNAME, a missing SPF record, or a forgotten subdomain. It’s one layer among several, not a substitute for record hygiene and ongoing monitoring.
DNS security isn’t a single control you switch on – it’s an ongoing discipline of knowing what records exist, why they exist, and whether the thing they point to is still yours. The organizations that get burned aren’t usually the ones with exotic attackers; they’re the ones with an old CNAME nobody remembered to delete.