Most guides on third-party subdomain discovery stop at the list. You run an enumeration tool, pull certificate transparency logs, merge the output, and end up with four hundred names under your domain. The question that actually matters starts there: whose asset is each of those names, and who can patch it when something goes wrong.
That question is harder than enumeration, and it is the one that decides whether your list is an inventory or just a long text file.
Third-party means two different things
The phrase gets used loosely, and the two meanings pull in different directions.
Sense one: the data sources are third-party
Nobody has a complete internal register of their own DNS. Zone files drift, delegated subdomains live in someone else’s account, and the marketing team’s platform created records nobody in IT ever saw. So discovery leans on outside records: certificate transparency logs, passive DNS collections, registration and WHOIS data, search engine indexes. You are reading what the internet already knows about you, the way an attacker does: from the outside.
Sense two: the hosting is third-party
The riskier meaning. A name on your domain that resolves to infrastructure you do not run at all: a status page on a monitoring vendor, a help centre on a support platform, a careers portal on an applicant tracking system, an email gateway at a security supplier. You publish the name. You inherit the reputation. You do not control the patch cycle, the console, the logging, or the moment the vendor deprecates a feature.
That asymmetry is the whole problem in one sentence. Your domain carries the trust; someone else carries the keys.
And whatever the source, discovery gives you candidates, not assets. A name found in a certificate log may never have resolved. It may have been retired three years ago and left behind as a log entry that cannot be deleted. It may belong to a supplier who used your brand inside a hostname they own outright, which looks like your estate and is not. Verification of the resolution chain is the step that turns a candidate into an asset with an owner.
Where the candidate names come from
Start from a seed: your apex domains, your known brands, your acquired companies. Expansion then works outward through public records.
- Certificate transparency logs. Every publicly trusted certificate is logged, so a name appears the moment a certificate is issued for it, often before anything is deployed behind it.
- DNS record types. A and AAAA for addresses, CNAME for aliases, NS for delegation, MX and TXT for mail and verification records that quietly name your suppliers.
- Registration data. WHOIS and registry records that link domains to the same organisation, registrant email or name servers.
- Passive DNS. Historical resolution data, which surfaces names that stopped resolving but never stopped being published.
Two blind spots deserve naming. Wildcard certificates hide whole branches of an estate from log-based enumeration, because *.internal.example.co.uk appears once in the log and tells you nothing about the twelve hosts behind it. The second-order effect is worse: a wildcard handed to a vendor host means that if the host is compromised, the attacker holds a valid certificate for every name under that branch. Internal or private certificate authorities do the same thing, issuing certificates that never reach a public log at all. We cover the gaps in log-based discovery in more detail in our piece on what certificate transparency logs miss.
When you merge sources, deduplicate carefully and record where each candidate was first seen and when. That metadata is not bookkeeping for its own sake. Six months later it is the difference between “this name appeared in passive DNS in 2019 and has not resolved since”and “this name was first seen last Tuesday and nobody can explain it”.
Reading the resolution chain to find the real owner
Ownership is decided at the end of the chain, not the first hop. This is where most discovery work quietly fails.
A name CNAMEs to a CDN. The CDN fronts a SaaS tenancy. The tenancy runs on a cloud platform. Three parties sit in that path, and the one who can apply a patch is rarely the one named in your zone file. So follow the chain all the way: CNAME to CNAME to A record, NS delegation to whoever is answering authoritatively, and note the provider at each step rather than the first redirect you hit.
Fingerprinting then narrows the platform. HTTP response headers, cookie names, default error pages, redirect behaviour and the issuer on the TLS certificate all hint at who is behind a name. A certificate issued to a vendor’s own common name on a host under your domain is a strong signal. A default “site not found”page from a landing-page platform is a stronger one.
Treat all of it as inference. A banner tells you what is likely running, not what is definitely running, and version strings are routinely stale, spoofed or stripped by a proxy in front. Only active testing or a straight answer from the supplier moves a finding from likely to definite, which is the distinction we draw in EASM versus vulnerability scanning.
One practical refinement: flag shared-platform names differently from dedicated infrastructure. A name resolving to a multi-tenant IP that hosts thousands of customers behaves differently under investigation than a name resolving to your own address space, and an apex-level redirect to a vendor is a different beast again. Sorting those categories early saves you chasing shared addresses that will never tell you anything useful.
Dangling records: the resource is gone, the name is not
A dangling record is a pointer to nothing: a CNAME that still exists in your zone while the resource it points at has been deleted. It is a DNS housekeeping failure, not a vendor flaw. The window opens when the cloud bucket, app service or SaaS tenancy is decommissioned ahead of the DNS record, which is exactly why decommissioning runbooks should remove the DNS entry first and the resource second. Do it in that order and the window never opens.
The classic case is a storage bucket deleted during a cloud tidy-up while the CNAME survives, so the platform now answers requests for your hostname with an error saying no such bucket exists. On a shared platform where names are claimed first come, first served, that error is an advertisement. An attacker registers the slug or bucket name on the same platform, and suddenly content of their choosing is served under your domain, with your brand around it, inside your cookie scope, trading on your reputation. A lapsed status page subscription produces the same outcome: the monitoring vendor frees the unused slug, anyone can claim it, and the DNS record in your zone points politely at them.
When you suspect a takeover candidate, do not prove it by claiming the resource. Registering the vendor name to demonstrate the issue leaves you holding an asset you then have to manage and maintain, and it can breach the platform’s terms of service. The DNS record plus the platform’s error response plus the vendor’s own documentation on how names are claimed is enough evidence to act on. Nobody needs a live proof of concept to justify deleting a stale CNAME.
Closing it properly means removing or repointing the record, then hunting for hard-coded references to that hostname in applications, email templates, redirect rules, API configurations and printed documentation. Delete the record and break a payment redirect and you have simply traded one incident for another. Our walkthrough of the dangling DNS problem goes through the verification sequence step by step.
What third-party subdomains expose besides takeover
Takeover gets the attention. The duller exposures are more common.
Agency leftovers are the standard example. A campaign microsite built on a landing-page platform, still resolving two years after the contract ended, still accepting form submissions. Those submissions contain names, email addresses and sometimes more, collected under your domain, which makes the organisation the controller in the eyes of UK GDPR regardless of who built the page. The ICO’s guidance for organisations is clear enough on controller responsibility; the uncomfortable part is that nobody internally is reading the inbox the form posts to.
Then there are the login pages. Vendor platforms routinely expose an admin or customer interface on a hostname under your domain, sitting entirely outside your single sign-on, your conditional access rules and your log pipeline. The authentication events never reach your SIEM. You will not see the password spraying because it is not happening on your side of the boundary.
Certificate hygiene is the third. Names you do not renew get certificates you do not manage: expired, mismatched to the hostname, or a supplier-issued wildcard with a validity period nobody tracks. An expired certificate on a vendor-hosted name still says your brand’s name in the browser warning.
From candidate list to inventory with an owner for every name
A list becomes useful when every row answers “who decides about this”. For third-party names, the fields that actually drive action are the hosting platform, the internal owner, the supplier contact, the contract status and the removal decision. Our breakdown of the fields worth recording in an internet-facing asset inventory covers the general case; third-party names need the contract and supplier columns on top, because the fix is frequently a conversation rather than a configuration change.
For each name, pick one of four outcomes: keep it, consolidate it onto a platform you already run, repoint it, or retire it. Someone has to sign that off by name. “The team agreed to review it”is how a microsite survives for two years.
Change detection is what keeps the inventory alive. The useful alert is not “this name exists”but “this name now resolves somewhere different”, “this name now returns a claimable-resource error”, or “a new name appeared on a platform nobody has approved”. Suppress the known-good churn, the rotating CDN addresses and the load balancer reshuffles, or the signal drowns. An alert feed nobody reads is worse than useless, because it gives false confidence.
Where discovery stops and other controls take over
Passive external observation tells you a name exists, where it resolves, and what platform probably sits behind it. That is the limit. Confirming a vulnerability needs authenticated scanning, a penetration test or a direct answer from the supplier. Discovery sits alongside vulnerability scanning, CMDB data and supplier assurance; it does not replace any of them.
Worth correcting a persistent myth: reading certificate logs, passive DNS and registration data does not touch the target systems and does not make you more of a target. Those records are public, continuously harvested, and already indexed by people with less friendly intentions. You are reading your own public footprint slightly later than they did.
On cadence, quarterly is the common answer and it is the wrong one. Records change daily, and the gap between a dangling CNAME appearing and anyone noticing is the entire exposure window. Continuous observation with daily or near-daily collection catches the name that appeared on the Tuesday after your review, which is the argument we make in why a point-in-time scan is not enough. Regulatory pressure is moving the same way: the NCSC’s asset management guidance expects organisations to know what they own and expose, and the Cyber Security and Resilience Bill, in progress at the time of writing, points in-scope UK operators towards the same expectation.
The Short Version
- Third-party subdomain discovery means two things: using outside data sources to find names, and finding names on your domain that someone else hosts. The second carries the real risk.
- Enumeration output is a candidate list. Resolution-chain verification is what makes it an inventory.
- Follow the chain to its end. The party who can patch is rarely the one named in your zone file.
- Dangling records come from removing the resource before the DNS record. Reverse that order in your runbooks.
- Do not claim a vendor resource to prove a takeover. The record and the platform’s error response are enough.
- Wildcard certificates hide names from log-based discovery and hand a compromised vendor host a certificate for the whole branch.
- Every third-party name needs an internal owner, a supplier contact, a contract status and a keep, consolidate, repoint or retire decision.
Frequently Asked Questions
What is third-party subdomain discovery?
It covers finding subdomains using external data sources such as certificate transparency logs, passive DNS and registration records, and identifying which of those names resolve to infrastructure run by someone other than you. The output is a set of candidates to verify, not a finished asset register. The verification work is what assigns each name an owner.
How do you tell whether a subdomain is hosted by a third party?
Follow the resolution chain all the way through: CNAME targets, NS delegation and the final A or AAAA record, noting the provider at each hop. Then look at the fingerprint clues, such as the TLS certificate issuer, HTTP headers, cookie names and default vendor pages. Those point to a likely platform; a supplier confirmation or a contract record turns likely into certain.
Is a CNAME pointing to a deleted bucket a real security risk?
Yes, where the platform lets anyone claim the freed name. An attacker who registers that bucket or slug serves their content on your hostname, inside your cookie scope and under your brand, which is useful for phishing, credential capture and session abuse. If the platform does not allow reclamation, the record is an error page rather than a takeover, but it should still be removed.
Can subdomain discovery be done without touching the target systems?
Largely, yes. Certificate logs, passive DNS, WHOIS and registry data are public records read from third-party collections, so nothing is sent to your infrastructure at all. Resolving a name or fetching a page does involve contacting the host, which is ordinary internet traffic rather than testing, and confirming a vulnerability still requires active scanning or a supplier answer.
How often should third-party subdomain discovery be repeated?
Treat it as continuous rather than periodic. Certificates are issued, DNS records are added and cloud resources are deleted every working day, so a quarterly pass misses everything that appears and disappears between runs. Daily or near-daily collection with alerting on ownership and resolution changes is the practical target.