Browser Extensions Miss Your Infrastructure Layer: Why DNS and TLS Detection Matter

Every tech detection browser extension—WhatRuns, Wappalyzer, BuiltWith—works the same way: it runs JavaScript on the page you're viewing and analyzes what it finds. This approach detects frontend frameworks, analytics tools, and CMS platforms reliably. But it completely misses the infrastructure layer: CDN providers, hosting platforms, certificate authorities, and email services.

DNS records and TLS certificates reveal this infrastructure. They're publicly accessible, but invisible to browser extensions. Here's what they miss and why it matters.

What Browser Extensions Detect

Browser extensions analyze the rendered page using several techniques:

• JavaScript globals — checking for window.jQuery, window.React, window.__NEXT_DATA__
• DOM patterns — looking for specific HTML elements, class names, or data attributes
• HTTP headers — reading X-Powered-By, Server, and similar response headers visible to the browser
• Meta tags — parsing <meta name="generator"> and other metadata
• CSS patterns — identifying framework-specific class naming conventions

This covers a lot of ground. If a website uses React, WordPress, Google Analytics, or Tailwind CSS, browser extensions will generally detect it. These technologies leave clear signatures in the page's HTML, JavaScript, and HTTP responses.

What They Miss

Browser extensions operate inside the browser's sandbox. They have no access to DNS resolution or TLS certificate details. This means entire categories of technology go undetected:

CDN providers (DNS CNAME)

When a site uses Cloudflare, CloudFront, or Fastly as its CDN, the evidence is in DNS CNAME records—not in the HTML. A CNAME record for www.example.com pointing to d1234.cloudfront.net tells you the site uses Amazon CloudFront. Browser extensions can sometimes guess a CDN from HTTP headers, but DNS CNAME detection is definitive and works even when headers are stripped.

Hosting platforms (DNS CNAME)

Netlify, Vercel, GitHub Pages, Heroku, and other hosting platforms are identified through CNAME records. A record pointing to example.netlify.app or cname.vercel-dns.com reveals the hosting provider. Browser extensions can't see this.

Certificate authorities (TLS inspection)

The TLS certificate chain reveals which certificate authority issued the site's SSL certificate—Let's Encrypt, DigiCert, Sectigo, or others. This is an infrastructure decision that tells you something about the organization's security posture and budget. Free CAs like Let's Encrypt are common among smaller sites and PaaS platforms; paid CAs like DigiCert are more common in enterprise environments.

Email infrastructure (MX records)

MX records reveal email providers: Google Workspace, Microsoft 365, Proton Mail, or custom mail servers. This is valuable for sales teams doing prospecting—knowing a company uses Google Workspace vs. Microsoft 365 signals technology preferences and budget.

Real Example: stripe.com

Here's what DetectZeStack returns when scanning stripe.com. This is actual API output, not fabricated data:

{
  "url": "https://stripe.com",
  "domain": "stripe.com",
  "technologies": [
    {
      "name": "Amazon S3",
      "categories": ["CDN"],
      "confidence": 100
    },
    {
      "name": "Amazon Web Services",
      "categories": ["PaaS"],
      "confidence": 100
    },
    {
      "name": "DigiCert",
      "categories": ["SSL/TLS certificate authority"],
      "confidence": 70
    },
    {
      "name": "HSTS",
      "categories": ["Security"],
      "confidence": 100
    },
    {
      "name": "Nginx",
      "categories": ["Web servers", "Reverse proxies"],
      "confidence": 100,
      "cpe": "cpe:2.3:a:f5:nginx:*:*:*:*:*:*:*:*"
    }
  ]
}

A browser extension visiting stripe.com would detect Nginx (from the Server header) and HSTS (from the Strict-Transport-Security header). That's it—two technologies.

DetectZeStack also identifies:

• Amazon S3 and Amazon Web Services — detected via DNS CNAME records, invisible to browser extensions
• DigiCert — detected via TLS certificate inspection, identifying the certificate authority
• Nginx CPE identifier — cpe:2.3:a:f5:nginx:*, ready for NVD vulnerability lookups

That's the infrastructure layer: cloud provider, CDN, and certificate authority—none of which appear in the page's HTML or JavaScript.

The 111 DNS CNAME Signatures

DetectZeStack's DNS detection layer includes 111 CNAME pattern signatures covering:

These signatures are checked by resolving DNS records for the target domain. No HTTP request to the website is needed for this layer—DNS records are public and resolve in milliseconds.

Why This Matters

For security teams

CPE-based vulnerability mapping only works if you can see the full technology stack. If you miss the CDN, web server, or hosting platform, you're missing potential attack surfaces. DetectZeStack includes CPE identifiers like cpe:2.3:a:f5:nginx:* so you can query the NVD directly. With 48,185 CVEs published in 2025 alone, knowing what you're running is step one of any vulnerability assessment.

For sales and market research

Technographic data is most valuable when it covers the full stack. Knowing that a prospect uses React is useful; knowing they also use AWS, Cloudflare, and DigiCert tells you about their infrastructure budget and maturity. DNS and TLS data add the signals that browser extensions miss.

Quick Start

Get an API key from RapidAPI (free, no credit card) and try it:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=stripe.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" | jq '.'

The response JSON includes all detected technologies. Look for the categories field to identify which layer each detection came from—technologies in "CDN", "PaaS", and "SSL/TLS certificate authority" categories are typically DNS or TLS detections that browser extensions would miss.

Read more: DNS-Based Technology Detection deep dive | DetectZeStack vs WhatRuns | Wappalyzer Open-Source Alternatives