Home / Knowledge hub / Dangling DNS
Knowledge hub
Dangling DNS
A DNS record pointing at something you no longer own or run.
What it means
A dangling DNS record is an entry in your DNS zone that still points at something you no longer control. A common case is a CNAME for help.example.com pointing at a hosting service where the account or project has since been deleted.
The record keeps working as an address, so visitors still arrive. What it points at is now empty, and on many platforms anyone can register that empty name. Your domain then serves their content. This is the usual route to a subdomain takeover.
Why it matters
Whoever claims the abandoned target can serve pages from your own domain name. Browsers trust that name, so the page can host a convincing phishing form, and in some setups it can read or set cookies that were meant only for your real application.
Customers and partners see your domain and nothing looks wrong to them. The first report is often from a security researcher or an angry customer. Cleaning up afterwards costs far more than the five minutes it takes to delete a record when a service is retired.
How it shows up
The records pile up quietly. A marketing campaign ends, a trial of a hosting product is cancelled, a staging environment is torn down, and nobody removes the DNS entry. Each one is an attack surface item that no one is watching.
The check is simple to describe. List every record in every zone, resolve each target, and ask whether you still own what answers. Do it when you retire a service, not only once a year. Keep an inventory so a record always has an owner.
Questions people ask
Dangling DNS, answered
Is dangling DNS the same as subdomain takeover?
Not quite. Dangling DNS is the condition: a record pointing at nothing you control. Subdomain takeover is what happens when someone else registers that target and starts serving content from your name.
Which records are usually affected?
CNAME records are the classic case, pointing at a third-party hosting, storage or platform name. A records pointing at an IP address you released back to a cloud provider can end up the same way, though they are harder to claim on purpose.
How do we find dangling records?
Export your DNS zones, resolve every target, and flag names that return errors or a provider's placeholder page. Then check whether the account behind each target is still yours. Automate it, because the list changes as teams spin services up and down.
Does HTTPS protect against it?
No. Anyone who controls the target can usually get a valid certificate for the name, since they now control what answers for it. A padlock tells you the connection is private, not that the page belongs to you.
Who should own the clean-up?
Whoever retires a service should remove its DNS record in the same change. Put it on the decommission checklist, and review the zone on a schedule as a backstop.
Sources
Where this comes from
Related
Terms that sit next to this one
Subdomain takeover
Claiming an abandoned cloud resource that one of your DNS names still points to.
Attack surface
Everything about your application an outsider can touch.
Asset inventory
A current list of the systems, apps and data you are responsible for.
DNS security
Protecting the lookup system that turns your domain name into a server address.
Cloud misconfiguration
A cloud setting left unsafe, such as open storage or an overly broad permission.
Who owns your old subdomains?
We look for what an outsider can reach on your domains, and report only what we proved, with the request and response attached. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.