CDN Detector

Inspect a domain's public CNAME, NS, and A records through Google DNS-over-HTTPS and compare CNAME and nameserver values with built-in fingerprints for well-known CDN and edge platforms. The detector follows one additional CNAME hop, reports matching providers with high or medium confidence and the DNS evidence, and still shows the collected records when no match is found. Detection is heuristic: direct A records are displayed but are not matched to provider IP ranges, hidden or custom hostnames can avoid recognition, and DNS hosting by a provider does not always prove that website traffic uses its CDN.

How to Use the CDN Detector

Check a public hostname for recognizable CDN or edge-platform fingerprints in its CNAME and nameserver chain.

  1. Enter the exact public domain or subdomain whose delivery path you want to inspect.
  2. Select Detect to query its CNAME, NS, and A records through Google DNS-over-HTTPS.
  3. Review each provider match, confidence level, and the DNS value shown as evidence.
  4. Inspect the CNAMEs, nameservers, and A records even when no built-in fingerprint matches.
  5. Confirm important conclusions with provider configuration or additional HTTP and network evidence.

Detection methodology

The detector matches CNAME and NS text against a fixed provider-pattern list and follows one extra CNAME hop. A direct CNAME match or multiple matching signals receives high confidence; weaker single evidence receives medium confidence.

A records are displayed for context but are not compared with current provider IP ranges.

Interpreting results

A match is evidence of a DNS relationship, not proof that every request is accelerated or proxied by that provider. Multiple matches can reflect layered services or mixed DNS history.

No match means no built-in fingerprint was recognized, not that the site definitely has no CDN.

Common mistakes

  • Checking only the apex domain when the website actually serves from www or another hostname.
  • Treating a provider nameserver as proof that the specific record is proxy-enabled.
  • Assuming medium or high heuristic confidence is a security or performance audit.

Limitations, privacy, and acceptable use

Custom hostnames, direct IP delivery, providers outside the pattern list, or chains longer than the followed hop can evade detection. Cached Google DNS results may lag recent changes.

The queried hostname is sent to Google DNS-over-HTTPS. Use this public-data check for legitimate troubleshooting and research, not as authorization to probe or attack third-party systems.

FAQ

How does the CDN Detector identify a provider?

It queries CNAME, NS, and A records, follows one extra CNAME hop, and matches CNAME or nameserver text against a built-in list of recognizable provider fingerprints.

Which providers can the detector recognize?

The current fingerprints include Cloudflare, Fastly, Amazon CloudFront, Akamai, Google Cloud CDN or Firebase, Azure CDN or Front Door, BunnyCDN, KeyCDN, StackPath or MaxCDN, Imperva, Sucuri, DDoS-Guard, Netlify, Vercel, and GitHub Pages.

What do high and medium confidence mean?

High confidence is assigned when a CNAME directly matches a provider pattern or multiple pieces of DNS evidence match. A single nameserver-style signal generally produces medium confidence.

Why does the result say no CDN detected?

The domain may not use a recognized CDN, may hide it behind custom DNS names, may use only direct IP addresses, or may use a provider absent from the built-in patterns.

Does a Cloudflare nameserver prove traffic is proxied?

No. Cloudflare can host authoritative DNS while individual records remain DNS-only. A nameserver match is evidence, not proof that the tested hostname is passing through the CDN proxy.

Are A-record IP ranges checked?

No. The page displays returned A addresses, but the current detector does not compare them with provider-owned IP range databases.

Why might more than one provider be listed?

A DNS chain or delegation can contain fingerprints from several platforms, and hosting or edge services can be layered. Review the evidence shown for each match rather than assuming all matches serve the same role.

Which DNS resolver is used?

The implementation uses Google DNS-over-HTTPS. Results can reflect resolver caching and may lag behind recent DNS changes until TTLs expire.

Does this inspect HTTP headers or page content?

No. Detection is based on public DNS records only. It does not fetch the website, inspect response headers, test performance, or verify CDN configuration.

What is acceptable use for CDN detection?

Use it for legitimate troubleshooting, migration checks, and public technology research. Do not treat heuristic results as authorization to probe or attack third-party infrastructure.