A marketing request to restore a promotional landing page from three years ago revealed a serious but common DNS hygiene problem. The team opened the original URL and encountered a completely unrelated website, even though the browser displayed the company's own domain name and a valid TLS padlock.
The original page had been hosted on external infrastructure using a project-specific name such as company-promo-2023. A CNAME record was created in the corporate DNS zone to map the promotional subdomain to that external address. When the campaign ended, the hosting project was deleted, yet the DNS record was never removed.
How dangling records form
External hosting platforms assign project names on a first-come, first-served basis. Once the original project is deleted, the name becomes available for anyone to register. Because the corporate CNAME still exists, any new registrant instantly receives traffic intended for the company's subdomain and obtains an automatically issued TLS certificate.
Standard monitoring misses these records. Availability checks only test known applications, and DNS resolvers return addresses even for non-existent projects when the hosting provider uses a wildcard record such as *.github.io.
Security impact
- Cookies set for the parent domain (for example, .example.com) are sent to any subdomain, allowing the new owner to receive session tokens.
- Subdomains often remain in Content-Security-Policy, CORS headers, OAuth redirect lists, and proxy rules long after the original service is gone.
- Attackers can complete domain-ownership challenges that rely on placing a file on the host.
The recommended cleanup process begins with exporting the entire zone from every DNS provider, assigning explicit owners and business justifications to each record, and validating external CNAME targets by checking the actual HTTP response rather than DNS resolution alone. Records whose owners cannot be identified are treated as candidates for immediate deletion.
