DNS-Based Technology Detection: Why Your CDN Can’t Hide

Most technology detection tools work by fetching a webpage and scanning its HTML, headers, and JavaScript for fingerprints. But what happens when the site blocks your request? Returns a CAPTCHA? Times out?

You get nothing. Zero technologies detected.

Unless you look at DNS. CNAME records are public, always available, and reveal exactly what CDN, PaaS, and cloud provider a site uses — regardless of whether their web server cooperates.

This article explains how DNS-based detection works, why it’s harder to hide than you think, and how DetectZeStack uses it alongside three other detection layers to deliver results even for the most locked-down sites.

The Four Detection Layers

DetectZeStack doesn’t rely on a single detection method. Each layer has different strengths and different confidence levels:

When all four layers work, you get the most complete picture. But the key insight is that layers 3 and 4 — DNS and TLS — work even when layers 1 and 2 fail. That’s what makes partial results possible.

How DNS CNAME Detection Works

When a company uses a CDN or PaaS provider, they typically create a CNAME record pointing their domain to the provider’s infrastructure. This is a fundamental part of how DNS works — it’s not optional configuration, it’s how traffic routing happens.

$ dig example.com CNAME +short
example.com.cdn.cloudflare.net.

$ dig shop.example.com CNAME +short
shops.myshopify.com.

These CNAME targets are public DNS records. Anyone can query them. And each one is a technology fingerprint:

• *.cdn.cloudflare.net → Cloudflare CDN
• *.myshopify.com → Shopify
• *.netlify.app → Netlify
• *.azurewebsites.net → Microsoft Azure

Even if a site returns a 403, a CAPTCHA, or nothing at all to HTTP requests, its DNS records still tell you who’s hosting it.

Sample DNS Signatures

DetectZeStack matches against 100+ CNAME patterns. Here are some examples across different categories:

CDN Providers

PaaS & Hosting

E-commerce & SaaS Platforms

Why You Can’t Hide Your CNAME

Some site operators try to obscure their technology stack by removing X-Powered-By headers, minifying JavaScript, or blocking automated requests. But hiding your CNAME is much harder because:

1. It’s required for routing — If you use Cloudflare, your DNS has to point to Cloudflare. That’s how the traffic gets there. You can’t use the service without the DNS record.
2. DNS is public by design — The entire DNS system is built on public resolution. Any recursive resolver can query your records.
3. Proxy partially obscures but doesn’t hide — Cloudflare’s “proxy” mode (orange cloud) masks the CNAME target behind Cloudflare’s anycast IPs. However, the authoritative nameservers (*.ns.cloudflare.com) are still visible in NS records, and HTTP responses include the cf-ray header. Full proxy hides the origin server, but Cloudflare itself is still detectable.

The only way to truly hide your CDN is to not use one. For most companies, the performance and security benefits of a CDN far outweigh any desire to hide it.

Partial Results in Practice

When a site blocks HTTP requests but DNS analysis succeeds, DetectZeStack returns a scan_depth: "partial" response. Here’s a comparison of full vs. partial results:

Full Scan (HTTP + DNS + TLS)

{
  "technologies": [
    {"name": "React", "confidence": 100},
    {"name": "Next.js", "confidence": 100},
    {"name": "Google Analytics", "confidence": 100},
    {"name": "Cloudflare", "confidence": 80},
    {"name": "Vercel", "confidence": 80}
  ],
  "scan_depth": "full"
}

Partial Scan (DNS + TLS only)

{
  "technologies": [
    {"name": "Cloudflare", "confidence": 80},
    {"name": "Vercel", "confidence": 80}
  ],
  "scan_depth": "partial"
}

The partial scan gives you fewer technologies, but the ones it finds — CDN and hosting provider — are often the most valuable for competitive intelligence and infrastructure analysis.

DNS Timeout and Performance

DNS lookups are fast. Our timeout is set to 2 seconds, but most resolve in under 100ms. The CNAME resolution runs concurrently with the HTTP analysis, so it adds no latency to the happy path.

When HTTP analysis fails (timeout, 403, CAPTCHA), the DNS results are already available — there’s no additional delay for partial results. The user gets the fastest possible response regardless of whether the target site cooperates.

Practical Applications

• Competitive intelligence — Scan competitors to see their infrastructure choices, even if they block scrapers
• Security assessment — Identify CDN and cloud providers as part of an external attack surface analysis
• Migration detection — Monitor DNS changes to detect when a company switches cloud providers
• Vendor analysis — Verify that a vendor actually uses the infrastructure they claim (e.g., “We use AWS” — does their DNS confirm it?)

The key takeaway: technology detection shouldn’t depend on whether a web server cooperates. DNS gives you a reliable, always-available signal layer that complements traditional HTTP-based fingerprinting.