How to Identify a Website’s CDN: CNAME, Headers, ASN, and TLS Evidence

CDN detection is an evidence chain, not a single lookup

When you enter a hostname, the useful question is rarely just “who owns this IP?” You want to know whether the request passes through a CDN, which provider is most likely, whether different regions use different services, and how strong the conclusion is. Modern deployments combine intelligent DNS, Anycast, reverse proxies, multi-CDN routing, and private edge layers. One clue can easily identify the wrong network component.

CdnChart models detection as the fusion of multiple observation categories. Probes collect DNS, HTTP, network, and TLS facts from controlled vantage points. Versioned fingerprint rules match those facts to providers and produce candidates, evidence, confidence, regional results, and limitations.

Evidence category one: the CNAME chain

A provider scheduling hostname is often the most direct public signal. Many integrations point the customer hostname to a provider-managed domain whose suffix, hierarchy, and naming pattern can be matched against a fingerprint catalog.

However, CNAME is not guaranteed to be visible and its absence does not prove that a site has no CDN. A customer may use A/AAAA records, Anycast, DNS load balancing, a reverse proxy, or a layered CDN. DNS services can also hide or rewrite the public chain. The correct statement is “this CNAME evidence was observed,” not “DNS proves the entire delivery architecture.”

Evidence category two: HTTP headers and cookies

Edge responses may expose provider-specific request IDs, cache states, or tracing headers. Cookie names and formats can also reveal implementation traits. HTTP evidence is close to the actual request path, but customers can remove or rewrite it and an upstream proxy can replace it.

The fingerprint model therefore distinguishes header existence from value matches and exclusive signals from shared signals. A shared Server value should not carry the same strength as a provider-specific response header.

Evidence category three: IP ranges and ASN

After resolving an edge address, a detector can check known IP ranges and the originating autonomous system. IP/CIDR and ASN evidence is useful when the DNS chain is hidden and helps explain why different regions return different edge addresses.

Cloud networks, hosting networks, and resellers may be shared by multiple products. CdnChart caps confidence for ASN-only and IP-only matches. A shared network can support a hypothesis, but it cannot independently confirm a CDN provider.

Evidence category four: TLS summaries

Certificate issuer, subject, SAN entries, and certificate fingerprints can add context when DNS is obscured or an edge layer uses a uniform proxy certificate. TLS normally works best alongside DNS, HTTP, or network evidence; it should not decide the provider in isolation.

Turning evidence into a conclusion

CdnChart fingerprint rules record the type, match mode, evidence strength, polarity, score, and confidence cap. Each observation produces a timestamped match with an observation source. The aggregator keeps the strongest match per evidence category so repeated copies of the same signal cannot inflate confidence without limit.

The result includes:

• candidate providers and candidate scores;
• a confidence level and numeric confidence;
• independent categories such as CNAME, header, IP, ASN, and TLS;
• the concrete matched evidence;
• limitations such as negative evidence, shared networks, or a single category;
• regional providers, conflicts, and observation counts.

Only independent support from multiple categories should reach a high-confidence conclusion. One ASN, one IP range, or one weak header can indicate a suspicion, not a certainty.

Multi-CDN and regional conflicts

A real site may use different CDNs for pages, images, downloads, video, and APIs. It may also switch providers by country, carrier, or network type. In that situation, “which CDN does this website use?” is incomplete by itself.

CdnChart preserves regional observations and distinguishes:

• multiple providers independently supported in different regions;
• contradictory evidence within one region;
• multiple high-confidence providers;
• shared cloud-network evidence that cannot identify a specific CDN.

That is closer to the real network than forcing one provider name into every result. A detector should show what was observed and where, not only a label without provenance.

Central, Agent, and Hybrid execution

CdnChart detection runs can use central probes, distributed Agents, or a Hybrid path. Agent execution selects nodes that are healthy, recently heartbeating, capable of CDN detection, and deduplicated by region. Hybrid execution stores central and Agent observations and aggregates both through the same matcher.

If distributed nodes are unavailable, the run can safely fall back to central execution while recording the requested mode, actual mode, and fallback reason. Idempotency keys prevent duplicate runs. Once a terminal snapshot is finalized, it remains immutable so a fingerprint-rule upgrade does not silently rewrite history.

Using CdnChart to inspect a hostname

Open the CDN detection tool, enter a hostname, and wait for the run to complete. The result page shows the conclusion, candidate providers, confidence, regional differences, and an evidence timeline. For long-term tracking, the public detection result exposes the latest published snapshot.

Start with the evidence, not the provider label. Confirm whether the conclusion comes from CNAME, headers, network ownership, TLS, or a combination across regions. A conflict, shared-network limitation, or insufficient-evidence state is a useful engineering signal, not an error to hide.

Boundaries and responsible use

Detection observes publicly reachable DNS, HTTP, TLS, and network facts. It does not bypass access controls, load an origin, or perform attack-oriented security tests. The result is a probabilistic external observation; it cannot prove an internal customer configuration, contract relationship, or every traffic path.

Summary

A trustworthy CDN detector answers four questions: what evidence was found, where it came from, whether regions agree, and how strong the conclusion is. CdnChart keeps DNS, HTTP, network, and TLS observations in one auditable chain and preserves unknown, conflict, and multi-CDN outcomes. Explicit uncertainty is a mark of a professional detection system.