Dangling DNS Records and Subdomain Takeover Guide

A dangling DNS record is a record that still points a subdomain at an outside service after your account or project on that service is gone. MDN (Opens in a new tab) describes the consequence: someone else can register the empty slot at the provider and publish content under your name. The defense is a matter of order. When you retire a service, remove the DNS record first. When you launch one, add the DNS record last. If you run a bookshop café that spins up pages for author evenings, reading circles and newsletter campaigns, the sections here show how to list every record, decide which ones are stale and remove them safely.

How a CNAME hands a name to someone else

According to MDN's glossary (Opens in a new tab), DNS is a hierarchical and decentralized naming system for internet-connected resources. It keeps domain names together with the resources, such as IP addresses, associated with them, and its best-known job is translating human-friendly names into numeric addresses. For a refresher on record types, see the DNS record types guide.

The record type at the center of this topic is the CNAME. RFC 1034 (Opens in a new tab) says a CNAME record identifies its owner name as an alias, and the data in the record names the canonical name. It also says that if a CNAME is present at a node, no other data should be present there. In practice a CNAME says: this name is really that other name, go there. That works for as long as the other name is under your control. When it is not, every visitor to your subdomain is sent to a destination you no longer govern.

The namespace itself is a tree. RFC 1034 says each node and leaf corresponds to a resource set, which may be empty, and that a zone is authoritative for all names in its connected region. The records in your own DNS panel are authoritative data for your zone, so each one is your responsibility, including the forgotten ones.

The two moments a name can be claimed

MDN defines a subdomain takeover as an attacker gaining control over a subdomain of a target domain. In the case MDN describes, the subdomain has a CNAME in DNS but no host is providing content for it, either because a virtual host has not been published yet or because it has been removed. The attacker then provides their own virtual host and hosts their own content. Both moments rely on a provider that does not verify who owns the domain name. The weakness is described here from the defender's side only.

MDN explains it with an analogy. A subdomain is like an electrical outlet. If your appliance is plugged in, everything is fine. If you unplug it, or never plugged it in, someone else can plug in a different one. You must cut power at the breaker, which is DNS, to prevent the outlet from being used by anyone else.

What is at stake

MDN says that with a taken-over subdomain an attacker can potentially read cookies set from the main domain, perform cross-site scripting, or circumvent content security policies, which may expose protected information, including logins, or deliver malicious content to unsuspecting users. So the damage is not limited to an embarrassing blank page. The security assumptions you built for the main domain, such as cookie scoping and CSP, can be weakened.

The reputation side

MDN does not discuss reputation as a separate topic, but the logic is plain. Visitors see your domain name in the address bar, and they trust it. Practical suggestion: assume that unwanted content on a subdomain of yours reflects on your brand, whatever its origin. If you suspect that spam or unexpected content already sits on your domain, the hacked site and SEO spam cleanup guide covers the search side of recovery, and the website security and hosting checklist for publishers covers the surrounding controls.

Build the inventory first

MDN's prevention advice starts with an inventory: create a list of all of your organization's domains and their hosting providers, and update it as things change, to ensure that nothing is left dangling. Here is a practical layout.

Where to collect the records

• Your registrar and DNS provider zone listings
• Agency and vendor contracts and the related email threads
• Notes from whoever built the site, including former staff
• Account dashboards of hosting, newsletter, booking and ticketing services
• Old campaign pages and printed material that mention a subdomain

The wider routine of renewals, transfers and DNS access is covered in the domain name management guide.

Classify each record: a three-question rule

For every record that points to an outside service, answer three questions in order.

1. Does an active account, project or virtual host that belongs to you still exist at the target for this name?
2. Is anything live relying on this address: a page, a link, an email flow?
3. Does a named, reachable person or role own this record?

Decision table: what the answers mean.

Deleting in the right order

MDN's rule for deprovisioning is to start by removing DNS records, and to do all steps as closely together as possible. Practical suggestion for a clean sequence:

1. Record the current value of the DNS entry so you can restore it if you were wrong.
2. Confirm in the inventory what the record was for and who owned it.
3. Check that nothing still calls the address: site links, emails, printed codes.
4. If the address should keep working, plan a redirect from infrastructure you control.
5. Delete the DNS record.
6. Close the project or account at the outside service.
7. Update the inventory with the date, reason and old value.

Cached DNS answers mean a deletion may not take effect everywhere at once. For the timing side of DNS changes, read the web host change and DNS cutover checklist.

Opening a new subdomain safely

MDN's provisioning advice is to start by claiming the virtual host and to create DNS records last. Pair it with the inventory.

Whether to use a subdomain at all is a separate question, with its own search implications, discussed in the subdomain versus subfolder decision guide. Practical suggestion: for a short campaign a subfolder on the main site means one DNS entry fewer to forget.

Other record types need a look too

MDN builds its explanation on CNAME and says nothing separate about other types. During an inventory, though, it is natural to review every record, because stale A, MX and TXT entries pile up. Treat this table as a practical suggestion rather than MDN's statement.

RFC 1034 explains delegation: at a zone cut, NS records name the servers for the subzone. If you delegated a subdomain to a former partner's name servers, you depend on that partner for as long as the record exists, so NS entries belong in the inventory as their own rows.

Example scenario: a bookshop café and its event pages

Example scenario: a bookshop café opened a subdomain for a ticketed author evening, another for a reading circle sign-up, a newsletter campaign address and a table booking tool. A trial account at one service lapsed, a freelance agency left, and a new manager opening the DNS panel finds a long list of entries nobody can explain.

The recommended flow: copy every record into the inventory table, apply the three-question rule to each outside-service record, treat records that point to lapsed accounts as dangling and delete them first, keep the live booking and newsletter entries with a named owner role, and write a short open and close checklist for future events.

Decisions in the same scenario

Checking printed material before deleting

A café prints codes on menus, posters and bookmarks, and a printed code can circulate for years. Before deleting an event address, check whether any printed item still points to it. If one does, move the address to a page you control and redirect from your own infrastructure instead of leaving it pointing at an outside service. This is a practical suggestion that follows from the inventory.

If you think a name has been taken

MDN's response advice is that the first step, if possible, is to cut power by removing the DNS entry for the subdomain. If your site has several layers of virtualization, for example a CDN in addition to virtual hosting, you may need to examine each layer to see where the attacker asserted their virtual host claim.

1. Remove the DNS record and note the time.
2. Check each layer, such as the host, the CDN and any outside platform, for where the name is defined.
3. Judge whether cookies and sessions on the main domain are affected. Practical suggestion: end sessions and reset passwords if in doubt.
4. Look in search results and in Search Console for unexpected content on that subdomain.
5. Write an incident note and add the lesson to the inventory process.

Why the order matters: two timelines

The same two steps, DNS and the outside service, produce opposite outcomes depending on which one comes first. Reading them as timelines makes the rule easy to remember.

MDN's instruction to do all steps as closely together as possible is about shrinking that exposure window. If two different people own the DNS panel and the service account, agree on a short handover so the second step does not wait for a meeting.

Questions for hosting and platform vendors

• When someone claims a virtual host for a domain name, how do you verify they have a legitimate claim to that name?
• If I close my account, what happens to the name I had configured, and can it be claimed by someone else?
• Do you offer a verification record or token that I can publish before the host goes live?
• How will I be notified if a configured name stops resolving to my project?

MDN urges putting pressure on vendors to close gaps and the first question is the one it names. Answers to the others are in each vendor's own documentation.

A one-page runbook

Practical suggestion: keep a single page that any team member can follow. It lists where the DNS panel is and who has access, where the inventory lives, the safe order for opening and closing, the first response when something looks wrong, and who to call at the registrar and the main providers. A runbook turns the rule from memory into routine, which matters when the person who set everything up is on leave. Review it whenever a provider, an agency or an access holder changes.

Process: contracts, owners and a review calendar

MDN suggests putting pressure on hosting vendors to close gaps: ask how they verify that someone claiming a virtual host has a legitimate claim to the domain name. It also notes that organizational complexity can only increase the likelihood of a vulnerable misconfiguration, so coordination across departments matters. Practical suggestion: tie the authority to open and close subdomains to one role, and write these points into agency and vendor contracts. Every subdomain opened for you is reported in writing. Records are deleted or handed over when the work ends. The owner of each service account is named. The vendor states how its hosting verifies domain ownership.

MDN suggests no review interval. A business that opens campaigns every month may review monthly, while a stable site can review at longer intervals.

Self-checks on your own subdomains

An inventory shows only the expected state, so verify the live state of names you own. Open each subdomain in a browser and look for the expected content and a valid certificate. A provider's generic error page saying the site or project does not exist is a warning sign, though its wording differs per service. Search for the subdomain in search results and look for titles you do not recognize. Treat anything unfamiliar as urgent, and remove the related DNS record first. Log the results in the last verified column.

Ranking the findings from an audit

An audit can return several suspicious records at once. Practical suggestion: rank them by risk instead of deleting everything in one sitting.

Decision rule: when two findings look equal, take the subdomain that members or customers really use first. Its failure is noticed sooner, and the reason for acting is easier to explain.

Misreadings to avoid

First, the idea that an unused record is harmless. In MDN's account the unused record is the problem. Second, closing the outside account and leaving DNS in place keeps the gap open. Third, treating the inventory as a one-time task, when MDN says to update it as things change. Fourth, assuming a redirect makes a subdomain safe: a redirect that depends on a target you do not control carries the same exposure. Fifth, deleting without noting the old value, which makes a mistaken deletion hard to undo. Sixth, relying on one person's memory instead of a role recorded in the inventory. Seventh, believing the check is finished once the DNS panel looks clean: names can also be defined in a CDN, a hosting control panel or an outside platform, and MDN specifically notes that multiple layers may each need to be examined. Eighth, treating a subdomain as cheap and therefore unimportant. A subdomain costs nothing to create, which is exactly why campaign names multiply, and each one that outlives its purpose adds to the list someone must keep accurate.

At each handover, ask who opened every external account and with whose mailbox. An account tied to a personal address cannot be closed once that person leaves, so the DNS record stays behind. Move service accounts to a shared organizational address and give the administrator role to at least two people.

Frequently Asked Questions

What is a dangling DNS record?

In MDN's account, a subdomain has a CNAME in DNS but no host is providing content for it, because the virtual host was never published or has been removed.

What can happen if a subdomain is taken over?

MDN says an attacker could potentially read cookies set from the main domain, perform cross-site scripting or circumvent content security policies.

In what order should I retire an old service?

MDN advises starting deprovisioning by removing DNS records, then closing the virtual host or account, and doing all steps as closely together as possible.

In what order should I launch a new subdomain?

MDN advises claiming the virtual host first and creating DNS records last.

What should the inventory contain?

MDN recommends listing all of your organization's domains and their hosting providers and updating the list as things change. Record name, target, owner role, end date and last verified date are useful columns, which is a practical suggestion.

What is the first step if I suspect a takeover?

MDN says the first step, if possible, is to cut power by removing the DNS entry for the subdomain, then to examine each layer such as a CDN to see where the claim was made.

Conclusion

A dangling record is a door that still carries your name but that nobody on your team can open or close. MDN's remedy is simple and ordered: claim the host before you add DNS, remove DNS before you close the host, keep an inventory of every domain and provider, and ask vendors how they verify ownership. Run it as a process with an owner and an end date for every subdomain, not as a one-off cleanup.

Once your domain is tidy and safe, you can look at growing its reach. For link building support, see our backlink packages.