Takeover Detection
A CNAME pointing at a deprovisioned service is an open invitation: anyone who claims the target owns a page on your domain. It is one of the most exploited DNS mistakes on the internet.
Subdomain takeover works because DNS outlives infrastructure. A team spins up a site on a cloud service, points a CNAME at it, and later shuts the service down - but the DNS record stays. Anyone who claims the abandoned target now serves content on your subdomain: phishing pages under your name, with your reputation. Attackers scan the internet for exactly this pattern, constantly.
DNS Watchdog resolves every record in your estate daily and flags CNAMEs whose targets no longer exist and hostnames that fail to resolve. It then goes a step further: responses are matched against a fingerprint database of 46 cloud services - Amazon S3, Heroku, GitHub Pages, Azure, Netlify, Shopify, Zendesk, and more - built from the known signatures abandoned services leave behind. A takeover candidate is confirmed by two independent signals, the CNAME target pattern and the tell-tale response body, so findings are evidence, not guesswork.
Dangling subdomains and confirmed takeover fingerprints are raised as Critical issues; broken nameserver delegations, which silently take whole subzones offline, are raised as High; IPs answering on no ports at all are flagged before the address is recycled under your name. And because detection runs from your live DNS rather than a manually maintained asset list, every zone synced from your providers is covered automatically - when you fix or remove the offending record, the issue closes itself on the next scan.
How it works
- ResolveEvery DNS record in every zone is resolved daily, across all your connected providers.
- Verify targetsCNAME targets are checked for existence and hostnames for resolution - a target with no A or AAAA records left is the classic dangling pattern.
- FingerprintResponses are matched against signatures for 46 cloud services, pairing the CNAME target pattern with the specific response an abandoned service serves - like S3's NoSuchBucket.
- Grade and raiseDangling subdomains and confirmed takeover candidates are raised as Critical issues, broken delegations as High - each linked to the exact record and zone affected, with the matched service named as evidence.
- Auto-resolveFix or remove the record and the issue closes on the next scan, with the detection and resolution both captured in your change log.
What you get
- Dangling CNAME and unresolvable hostname detection across every zone
- Takeover fingerprints for 46 cloud services, from S3 and Heroku to GitHub Pages and Shopify
- Confirmed candidates require both a CNAME match and the service's abandonment signature
- Dead and inactive IP addresses still pointed at by records
- Broken nameserver delegations flagged before whole subzones go dark
- Issues auto-close the moment the offending record is fixed or removed
Why it matters
Close the door before it is found
Attackers automate the hunt for dangling records. Daily detection means the window between a service being deprovisioned and the record being cleaned up shrinks from months to hours.
No asset inventory required
Coverage comes from your DNS itself. Every record your providers hold is checked - including the ones nobody remembers creating.
Built for third-party churn
Dangling records are a side effect of using SaaS: trials end, projects close, vendors change. Continuous checking absorbs that churn so your DNS does not accumulate risk.
Proof of remediation
Every detection and every resolution is recorded in the change log - evidence for auditors that takeover risk is monitored and managed.
Common questions
What exactly is a subdomain takeover?
When a DNS record points at a resource that no longer exists - a deleted cloud site, an abandoned SaaS account - anyone who claims that resource controls what your subdomain serves. Visitors see your domain in the address bar while the attacker controls the content, which makes it a devastating platform for phishing.
What conditions does DNS Watchdog detect?
Dangling CNAMEs whose targets no longer resolve, takeover fingerprints across 46 cloud services, IP addresses answering on no ports, and broken nameserver delegations - each graded by severity and linked to the affected record.
How do you keep false positives down?
Two ways. Fingerprint matches require both the CNAME target pattern and the service's specific abandonment response, not just one or the other. And hostnames whose records carry MX entries are not flagged as dangling, since third-party email platforms routinely look like dangling web targets without being takeover risks.
What happens when I fix the record?
The next daily scan confirms the condition is gone and resolves the issue automatically. If you have notifications configured, the resolution is reported alongside any other changes - no manual bookkeeping.