Find the Subdomains That Point to Services You No Longer Use

This article was written with the help of AI. We used an AI assistant to research recent attacks and draft the text, then reviewed it ourselves. Sources are linked throughout.

A subdomain can keep working after your business has stopped using the service behind it.

Picture an Akron clinic that ends a benefits-vendor contract. The clinic moves its portal, but the benefits subdomain stays in DNS. Patients still get the old link on printed materials. The address may now show a provider landing page instead of the clinic's benefits portal.

The first-party subdomain still carries the clinic's name. Visitors may trust it because it sits under a domain the clinic controls. The DNS dashboard may show no obvious error. Meanwhile, another party may be able to claim the abandoned service name at the other provider.

That is the problem. Our security research for November 2, 2026 put this check on the next-seven-days list for domain owners. We did not verify a specific takeover campaign during the October 26 to November 2, 2026 research window. That does not make abandoned aliases harmless. It means this is a standing configuration risk that owners should review now.

A Working Page Can Still Be an Old Door

A CNAME record maps one hostname to another hostname. Businesses use them for hosted applications, customer portals, status pages, legacy file services, and vendor projects.

Consider this chain:

benefits.example.com
    CNAME -> retired-benefits.vendor.net
    CNAME -> tenant.active-platform.net

The final target may still work. The final provider may have an active account. That sounds safe, but it does not clear the middle hostname.

The provider that controls retired-benefits.vendor.net may consider that exact hostname unclaimed. Another party could claim it and redirect visitors to a fraudulent login page or a malicious download. A safe final destination does not make an abandoned link earlier in the chain safe.

This is why we check the full CNAME chain and ask the provider who controls each target. A new CNAME target is not proof of a takeover. It is a reason to investigate. The research treats the finding as strong only when the target provider confirms that the exact hostname is unclaimed.

Start With the Names You Control

"First-party subdomain" means a hostname under a domain your organization owns. That includes subdomains that point to an outside provider.

Start with a complete inventory. Pull the following:

• The authoritative DNS zone export.
• Records from the registrar and DNS-provider accounts.
• Passive DNS records that show older names.
• Certificate transparency records for names that were issued certificates.
• Web analytics and server logs.
• Links found in email signatures, invoices, printed materials, QR codes, and vendor documentation.

Passive sources can miss old records. Your DNS zone and your provider accounts are the better starting points.

Check for wildcard records too. A wildcard makes individual names harder to find during a casual review. It can also produce a response for names nobody consciously configured.

For every hostname, record the business purpose, the responsible owner, the full CNAME chain, the target provider, and the last date somebody confirmed the service was still needed.

The Owner and the Analyst Are Two Different Jobs

The owner matters. The person who created a DNS record may not be the person who understands its business use. Marketing may need a link to keep an old campaign landing page live. A clinic may need a benefits portal for reference material. A manufacturer may have a status page connected to a customer workflow.

The business owner can confirm whether the service is still needed. The DNS analyst can confirm where it points. Both jobs need to happen.

Trace the Full CNAME Chain

Start with the first-party hostname. A basic DNS query shows its CNAME target:

dig +short CNAME benefits.example.com

If the result is retired-benefits.vendor.net, query that hostname next:

dig +short CNAME retired-benefits.vendor.net

Keep following the chain until you reach a hostname that does not return another CNAME.

Document each step. A useful chain record includes:

• The first-party hostname.
• Every CNAME target in order.
• The final destination.
• The provider that controls each target.
• Whether each exact hostname is claimed.
• The business decision for keeping or removing it.

Do not stop after the first answer. DNS tools are good at showing the path. They cannot tell you whether an account at the final provider still claims an intermediate hostname.

A successful connection is not ownership proof. The page may be active, parked, or showing a default response. It may also have a valid certificate without belonging to your organization. The person or company controlling the provider account is the fact that matters.

Ask the Provider the Exact Question

Contact the provider that controls the namespace for each target. The provider displaying the final application may not control the intermediate hostname.

Give support the exact hostname. Do not ask whether the service is "safe." Ask who controls the name and whether another party can claim it.

Our provider question includes:

• Is this exact hostname currently assigned to an active account or resource?
• If it is assigned, is that account tied to our organization?
• If it is not assigned, can another party claim the exact hostname?
• What content appears if the hostname is unclaimed?
• Can the hostname be attached to our existing account without transferring ownership of our parent domain?

Keep the response in a ticket or a shared record. A support answer also has a date attached to it. Provider accounts change, and a hostname claimed now may be released later.

An answer such as "we receive DNS traffic for that name" is not enough. Many services can point to the same shared platform. The provider needs to confirm the claim status of the exact hostname.

Use RDAP and Root Zone Data for the Right Job

Public registration data helps with ownership research, but it has limits. ICANN's Registration Data Access Protocol (RDAP) provides a standardized way to access domain registration information. It can help identify the registrar behind a parent domain and point your inquiry in the right direction.

RDAP does not answer whether a SaaS provider has claimed retired-benefits.vendor.net. It also does not inspect the provider's customer account. Registration data and service-resource ownership are separate checks.

The IANA Root Zone Database lists top-level domains and their delegation details. It can confirm that a top-level domain is delegated. It does not show how a particular subdomain is configured or whether an outside company still claims a service name.

Use these sources to orient your investigation. Use direct provider confirmation to settle the hostname claim.

Make the Business Decision

Once the chain and claim status are known, the owner needs to choose what happens next.

If the service is retired and no known workflow depends on the subdomain, remove the first-party DNS record. Check printed materials, saved bookmarks, email templates, customer documents, and application integrations first. A cleanup can expose an old dependency.

If the business still needs the service, claim the target hostname and attach it to the correct account. The goal is an active provider account that controls the exact name your first-party subdomain references.

If the business has moved to a new service, point the first-party record to the new target only after confirming that target is claimed. Shortening the chain helps, but only when every remaining link has a known owner.

If the claim status is unknown, record it as unknown. Do not call it safe. If the business has no current need for the service, removing the alias is the cleaner option. If the service is still needed, get a written provider response before making a risk decision.

Record the owner and the decision in an internal register. Future staff should not have to guess why a legacy alias remains.

Know What the Finding Actually Means

A CNAME chain review can produce several different conclusions, and the wording matters. Getting this wrong in either direction is how a report stops being read.

A strong indicator is still not proof that a takeover occurred. For that, you need evidence that another party claimed the target or used it maliciously. Keep the investigation record factual.

This distinction protects your team from crying wolf. If every new alias gets called a takeover, owners stop reading the report. We reserve the strong label for confirmation from the provider that controls the exact hostname.

Remove the Alias and Verify the Result

Before making a DNS change, save the existing record and chain. You want a record of what was removed and why.

After the change:

1. Query the first-party hostname again.
2. Confirm the old CNAME no longer resolves as intended.
3. Open the old URL from a clean browser session.
4. Check the DNS provider account for a recreated or duplicate record.
5. Review recent requests for the retired hostname.
6. Add the hostname to your monitoring list.

DNS changes do not disappear from every resolver at once. Cached results may continue briefly. If old links must fail cleanly, replace them with a notice on a destination your organization controls. Do not leave the abandoned CNAME in place.

If the service remains active, ask the provider to confirm the hostname is attached to the correct account after the DNS update. Then test the full path from a public resolver and from the business network.

DNS Cleanup Does Not Replace Account Protection

A clean DNS inventory closes one path for an attacker. It does not stop somebody from sending a convincing phishing email. CISA's phishing guidance explains that attackers often impersonate legitimate organizations, and recommends phishing-resistant multifactor authentication as one layer of protection.

That control matters if someone reaches a fake login page. It does not repair an unclaimed hostname under your domain. You need both sound DNS ownership and strong account protection.

At NHM Ohio, this review starts with the records you already manage. We inventory first-party names, trace CNAME chains, identify the controlling provider, and document the owner's decision. We do not label every new alias a takeover.

For businesses in Stark County, Summit County, and the rest of Northeast Ohio, the stale link may sit in a quote, an email signature, a patient handout, or a customer portal. Those references decide whether you remove the name now or migrate it to a service your organization still controls.

Sources

• CISA: Phishing Guidance: Stopping the Attack Cycle at Phase One, AA23-320A
• ICANN: Registration Data Access Protocol (RDAP)
• IANA: Root Zone Database

Common questions