Every competitive review, migration plan and vendor negotiation starts with the same question: what is this site actually running on? The answer is rarely a single name, and no one signal is reliable on its own. Here is the order of evidence that works — DNS chain first, headers second, network ownership third — and how to read it when a site is running two CDNs at once.
Start with the DNS chain
Delivery decisions are published in DNS long before they show up anywhere else, so resolution is where detection should begin. Query the hostname you actually care about — usually www or a media subdomain rather than the apex — and follow the CNAME chain to the end rather than stopping at the first hop. A single lookup often returns a vanity alias that means nothing; two or three hops later you land on a delivery hostname whose suffix identifies the operator unambiguously, because every provider terminates its aliases in a domain it owns and publishes.
Chase the chain to the last record that still returns a CNAME, then note the final address record. Do the same for the apex, which frequently behaves differently: apex names cannot legally hold a CNAME alongside other data, so sites either use an ALIAS-style flattened record at the DNS provider or point the apex straight at an address. That asymmetry is itself a finding. A flattened apex plus a normal aliased www usually means the DNS host and the CDN are the same company or are deliberately integrated.
Read the nameserver records at the same time. Authoritative DNS is a separate purchase from delivery, and the combination tells you more than either alone: a site whose nameservers sit with an independent managed-DNS operator but whose content aliases to a large CDN is a company that has kept its steering layer portable — often deliberately, as a precondition for the kind of failover described in our guide to DNS-based CDN steering. A site whose nameservers and delivery belong to one vendor has consolidated, and its switching cost is materially higher.
Read what the response headers admit
DNS tells you who the traffic is addressed to. Headers tell you what handled it. Fetch the resource twice — the first response is frequently a miss and the second a hit, and the difference between them is diagnostic. Look past the obvious branded header to the whole response: the server token, any proxy-identifying hop header, the cache-status field, the request identifier, and the age value. Modern edges increasingly emit a standardised cache status header that names the handling node and the outcome in one line, which removes most of the guesswork that vendor-specific headers used to require.
Three patterns are worth learning to spot. First, a request identifier is almost always provider-shaped — length, character set and prefix are consistent enough to identify an operator even when the branded headers have been stripped. Second, an age header that increments between requests proves you are talking to a cache rather than an origin, which rules out the “DNS-only, proxy off” configuration that makes some sites look like they use a CDN when they do not. Third, security headers travel with the platform that inserted them: a distinctive challenge cookie, a bot-scoring header or a WAF identifier tells you which security vendor is in path even when delivery belongs to someone else.
Header stripping is common on enterprise configurations, so treat absence as weak evidence. A site that returns nothing but a bare server token has usually turned off the identifying headers on purpose, which is a small signal in itself: default configurations leak, hardened ones do not.
Confirm with the address, the network and the certificate
The third layer is ownership. Resolve the hostname to an address and look up the autonomous system that announces it. Because delivery networks announce their own space, the AS number and its registered name confirm or contradict everything the first two layers suggested. This is the check that catches white-labelled and resold delivery, where the DNS suffix and the headers carry a brand that does not operate any infrastructure at all.
The certificate adds a second confirmation. Retrieve the leaf presented on the TLS handshake and read the subject alternative names and the issuer. Shared edge certificates covering a long list of unrelated hostnames indicate a multi-tenant platform tier; a certificate covering only the site’s own names, issued from a CA the customer chose, indicates either a higher plan or a bring-your-own-certificate arrangement. Certificate transparency logs extend this backwards in time and often reveal the origin hostnames a company forgot it had published — the same leak that makes origin obscurity so unreliable, which is why we recommend mutual TLS on the origin hop rather than hidden addresses.
Protocol advertisements round it out. The alternative-service advertisement tells you which HTTP versions the edge offers, and the negotiated protocol tells you what the client actually used. Providers differ in what they enable by default and how quickly they roll out newer transports, so protocol support is a usable secondary fingerprint, and a useful cross-check against a provider’s marketing claims.
When one answer is not the answer
Most detection tools return one name because they check one signal. Real estates are frequently layered, and the layering is the interesting part. A security vendor in front of a delivery network, an image service on a separate hostname, a video platform on a third, and a different provider entirely for the API: that is an ordinary architecture, not an exception, and a single-answer tool will report only whichever layer it happened to touch.
Two habits protect you. Resolve from more than one vantage point, because multi-CDN estates steer by geography or by resolver and will hand different regions different answers — a site that returns one provider from Europe and another from Asia is not misconfigured, it is split. And test more than one hostname: the static asset domain, the image domain, the API domain and the marketing site are frequently four separate contracts, and the expensive one is rarely the one on the homepage.
Watch for the failure modes too. Newly migrated sites serve stale answers for as long as the old records are cached, so a low-authority answer may simply be out of date; check the record’s remaining lifetime before treating it as current. Regional splits are common for mainland China, where a separate operator serves an in-country audience behind the same brand, a structure we cover in delivering into China.
Turn the finding into a decision
Detection is means, not end. What the evidence supports is a commercial read: which layers are bought from whom, which of them overlap, and where a company is paying twice for the same capability. Security purchased from one vendor and delivery from another is a deliberate and often sensible split; security bought twice because a platform bundle included a WAF nobody turned off is a line item waiting to be cut.
If you are running this on your own estate, write down every hostname, the layer serving it, and the contract behind it — the inventory step in documenting your delivery estate. If you are running it on a competitor or a prospect, remember that the stack you find is evidence of what they chose, not proof that the choice was correct.
You can run all of these checks by hand with a resolver and a header client, and you should learn to, because the manual method is the one that survives a tool being wrong. When you want the whole battery at once — chain, headers, network, certificate and protocol in a single pass — our free CDN Finder runs exactly this sequence and shows every layer it finds rather than collapsing the answer to one name. From there, the useful next step is comparing what you found against what it should cost: start with what a CDN should cost in 2026.