If you manage any kind of web infrastructure, there is a ticking time bomb you probably haven’t thought about in a while. It is sitting quietly in your DNS zone files, doing nothing, drawing no attention to itself. I am talking about stale DNS entries, those old records pointing to servers you decommissioned, cloud instances you deleted months ago, or campaign landing pages nobody remembers creating.
The problem is not that these records exist. The problem is what happens when someone else notices them before you do.
Why Stale DNS Records Are More Dangerous Than You Think
Most people treat DNS as a set-and-forget system. You add a record when you need it, and then you move on. But DNS records do not expire on their own. That A record pointing to an IP address you released back to your cloud provider six months ago? It is still there, still resolving, still telling the world that address belongs to you.
Here is where it gets ugly. An attacker can claim that old IP address or cloud resource, and suddenly your subdomain is serving their content under your domain name. This is called a subdomain takeover, and it is far more common than most organizations realize. The attacker gets a trusted-looking URL, your visitors get phished, and you get the blame.
I learned this the hard way a few years back. A client had a staging environment on a subdomain that pointed to an AWS Elastic IP. The project ended, the instance was terminated, but nobody touched the DNS. Three months later, someone flagged that the subdomain was serving a cryptocurrency scam page. It took us about ten minutes to fix once we knew about it. The reputational damage took considerably longer to repair.
Common Sources of Stale DNS Entries
Stale records accumulate faster than you would expect, especially in organizations where multiple teams manage their own infrastructure. The usual culpr, include old CNAME records pointing to deprovisioned SaaS platforms like Heroku, GitHub Pages, or Shopify stores. Then there are A records for development and staging servers that were shut down but never cleaned up in DNS.
Marketing teams are frequent contributors too. Campaign microsites, event landing pages, and partner portals all get subdomains. When the campaign ends, the hosting goes away, but the DNS record stays. MX records for old mail services, TXT records for abandoned verification challenges, and deprecated SPF entries all add to the pile.
The bigger your organization, the worse this gets. I have seen companies with over two hundred subdomains where fewer than half were actually serving live content. The rest were just ghosts in the zone file.
A Practical Process for Finding and Cleaning Up Stale Records
Detecting stale entries is not technically difficult. It just requires discipline and a systematic approach. Here is how to do it step by step.
Step one: build a complete inventory. Export your entire DNS zone and list every record. If you only manage DNS through a web panel, most providers let you export zone files. You need the full picture, not just the records you remember creating.
Step two: resolve and verify each record. For every A and AAAA record, check whether the IP address still belongs to you. For CNAME records, verify that the target actually exists and is under your control. A simple dig or nslookup command will tell you if a CNAME target returns NXDOMAIN, which is a classic sign of a dangling record ripe for takeover.
Step three: check HTTP responses. Even if a record resolves, that does not mean it is healthy. Hit each subdomain with a curl request and look at what comes back. A 404 from a cloud provider’s default page is a red flag. So is a connection timeout or an unexpected redirect.
Step four: review TXT and MX records. Old SPF includes referencing services you no longer use waste your SPF lookup limit and can cause legitimate email to fail authentication. Orphaned DKIM records and abandoned MX entries are common clutter that degrades your email security posture over time.
Step five: remove or update. Delete records that serve no purpose. For records you are unsure about, set a calendar reminder to review them in 30 days. If nobody complains, they are safe to remove.
Why Manual Audits Are Not Enough
There is a common misconception that doing a DNS audit once or twice a year is sufficient. It is not. DNS changes happen constantly, new subdomains get created without your knowledge, cloud resources get reprovisioned, and services get deprecated between audits. A quarterly review might catch problems eventually, but eventually is not good enough when subdomain takeovers can happen within hours of a resource being released.
What you actually need is continuous monitoring. Automated tools that watch your DNS infrastructure around the clock and alert you the moment something looks wrong. This is exactly why I built DNSVigil. It automatically discovers all subdomains associated with your domain, monitors their DNS health continuously, and sends immediate alerts when it detects dangling records, misconfigured entries, or potential takeover risks. Instead of manually running dig commands against a spreadsheet of subdomains, you get a live dashboard showing the real state of your DNS infrastructure.
What About Subdomains You Do Not Know Exist?
This is the part that surprises most people. You cannot audit what you do not know about. Employees create subdomains for quick demos. Agencies set up campaign pages under your domain. Legacy systems from before your time still have active records. Subdomain enumeration, the process of discovering all subdomains under a domain, is a critical first step that most manual audit processes skip entirely.
DNSVigil handles this automatically by combining multiple discovery techniques to find subdomains that do not appear in any internal documentation. Many of our users are genuinely shocked at how many subdomains they did not know they had.
Frequently Asked Questions
How quickly can a stale record become a security risk? Almost immediately. Once you release a cloud resource, someone else can claim it within minutes. Automated scanners specifically look for these opportunities.
Are internal subdomains at risk too? If they have public DNS records, yes. Even if the subdomain was intended for internal use, a public DNS record pointing to a released resource is exploitable.
Is it safe to just delete old records? Generally yes, but proceed with caution. Some records may support services you are not aware of. Monitor for issues after deletion, and keep a backup of your zone file before making bulk changes.
Do stale records affect SEO? They can. Search engines may index subdomains serving error pages or, worse, attacker-controlled content. Both scenarios harm your domain’s reputation and search rankings.
The Bottom Line
Stale DNS entries are one of those problems that feel unimportant right up until they become very expensive. The fix is straightforward: know what records you have, verify they are still valid, and automate the monitoring so you catch problems before attackers do. Your DNS zone file is part of your attack surface. Treat it that way.