Subdomains accumulate. Marketing creates a landing page for a campaign, developers spin up a staging environment, partners get integrated through a dedicated subdomain, and over time the public DNS for any sizeable organisation grows into a sprawling list that nobody maintains carefully. Most of those subdomains sit harmlessly. Some of them quietly become liabilities, waiting for the wrong person to notice.
Dangling DNS Records Cause Real Damage
When a subdomain points to a service that no longer exists, attackers can sometimes claim the abandoned service and host content on it. Cloud platforms, content delivery networks, and SaaS providers vary in how easily this can be done, but several major incidents have followed exactly this pattern. The attacker sets up a phishing page on what looks like a legitimate domain, complete with valid TLS certificate, and the click-through rates climb. external network penetration testing that includes proper DNS hygiene catches these issues before someone else does.
Old Applications on Forgotten Subdomains
Beyond pure DNS issues, forgotten subdomains often host actual applications nobody has updated for years. The blog from 2017 that nobody bothered to take down, the marketing microsite for a product that was discontinued, the test environment for an old project that never quite got cleaned up. Each of these typically runs outdated software, lacks current security patches, and provides a foothold into the wider environment when exploited. Periodic discovery and cleanup remove the easy wins.
Expert Commentary
Name: William Fieldhouse
Title: Director of Aardwolf Security Ltd
Comments: When I run external surface reviews, forgotten subdomains routinely produce the most damaging findings. The current production environment is usually well-maintained. The forgotten staging server from a 2018 project, running unpatched software, sitting on a subdomain that points back to internal infrastructure, almost always provides a foothold.
Subdomain Takeovers Versus Dangling DNS
These two terms get used interchangeably but describe slightly different scenarios. A subdomain takeover specifically means an attacker can claim the underlying service the DNS record points at. Dangling DNS records, by contrast, are records pointing at addresses no longer under your control, which may or may not allow takeover depending on the service. Both produce risk. The fix is the same: identify them through regular discovery and remove the orphaned records promptly.
Continuous Discovery Beats Periodic Audit
An audit done once a year shows you the surface as it was on the day of the audit. By next month, your developers have launched new properties and your DNS team has added more entries. Continuous discovery, where new assets trigger an alert and feed automatically into a review queue, keeps the picture current. Pair this with regular vulnerability scanning services so that anything new gets checked for known weaknesses without anyone having to remember to ask.
Process and Ownership
Most subdomain problems trace back to unclear ownership. Marketing creates subdomains through one process, developers through another, IT through a third, and nobody owns the eventual cleanup. A central register, maintained by a single team with clear authority, prevents the slow accumulation of cruft. Combine the register with mandatory expiry dates for temporary subdomains and you avoid the problem at source rather than fighting the symptoms.
Practical Steps This Week
Run a discovery exercise against your domains. Compare the result to whatever DNS list you currently consider authoritative. Investigate every difference. The exercise itself usually surfaces several subdomains that nobody can explain, several that point to services that no longer exist, and at least one or two that present immediate security risks. Treat the cleanup as a one-time project followed by ongoing process improvements, and you remove a class of risk that quietly grows in every other organisation.
