What's the difference between the tech-stack layer and the infrastructure layer?

Best move: read the tech stack from the page, and read the infrastructure from DNS, the network, and the TLS handshake.

Why it works: they answer different questions from different evidence. One tells you what the site is built with. The other tells you where it runs and how it routes traffic and mail.

Key takeaways

• The tech-stack layer reads application code from the page. The infrastructure layer reads DNS, network, TLS, and mail routing.
• Tech-stack evidence comes from crawling HTML and JavaScript. Infrastructure evidence comes from DNS resolution, an ASN lookup, and the TLS handshake.
• The infrastructure layer needs no JavaScript rendering. DNS, ASN, and TLS answer without the page ever executing.
• Infrastructure is harder to hide than the tech stack, because DNS records and TLS certificates are public by design.
• Bassethound returns both layers correlated in one dossier, so a Shopify front end and a Shopify-hosted origin confirm each other.

What does the tech-stack layer detect?

Application-level technology: frameworks, CMS, analytics, tag managers, chat widgets, payment processors, and ecommerce platforms. Each detection carries five fields: category, version, confidence, how_detected, and evidence. The source is the crawled page. Bassethound matches signatures against script names, markup patterns, global JavaScript variables, meta generators, and cookie names, then attaches the exact string that triggered the match.

This is the commoditized layer. BuiltWith, Wappalyzer, and TheirStack mirror it cheaply, and so does anyone with a signature database and a fetcher. That is why it is not the headline. Single-layer detection is a solved, crowded problem.

Be honest about the ceiling. A fully server-rendered component or a reverse proxy can erase its own front-end signature, and a fast static crawl will miss it. Bassethound renders JavaScript when the signals call for it, and when the crawl still cannot reach a detection, the dossier says so rather than guessing. The tech-stack layer is a strong lead generator and a weak sole authority. It earns its value by sitting next to four other layers, not by standing alone.

What does the infrastructure layer detect?

The plumbing. IP address, ASN, hosting organization, CDN, nameservers, MX records, email provider, and the DNS TXT vendors a domain has authorized. It resolves the email-auth posture as booleans: SPF present, DKIM present, DMARC present. It reads the TLS certificate end to end: issuer, subject alternative names, expiry, and days_remaining.

None of this comes from the page. It comes from DNS resolution, an ASN and WHOIS lookup, and the TLS handshake itself. That difference in evidence source is the whole point. The infrastructure layer answers “where does this live and how does it route,” while the tech-stack layer answers “what is this built with.”

Because the evidence is DNS and network state rather than rendered HTML, this layer resolves on the keyless fast profile in a second or two, with no browser required. It also holds up when the front end is opaque. A site can proxy away its framework, but it cannot serve mail without publishing MX records, and it cannot serve HTTPS without presenting a certificate you can read. Those facts are structural, and the infrastructure layer reads them straight.

Why keep them as two separate layers instead of one blob?

Because they fail differently and they earn confidence differently. Tech-stack signatures degrade under server-side rendering and proxying. Infrastructure facts degrade almost never, because DNS and TLS are public by design. Fuse them into one flat “stack” view and you blur a high-confidence certificate fact into the same bucket as a low-confidence widget guess, and lose the ability to weight them.

Separation also makes correlation legible. Keep the layers distinct and you can ask cross-layer questions. Does the detected ecommerce platform match the origin host, or is the store proxied through something else? Does the marketing analytics vendor match the email provider, or do sales and marketing run on different rails? Does the CDN in the infrastructure layer explain a missing origin signature in the tech-stack layer? Those reads only exist when each layer stands on its own first.

This is the fusion thesis in miniature. An agent could fire two separate MCP calls, one for tech and one for DNS, and stitch them itself. It would pay two round trips and still have to align the results. Bassethound returns both already correlated, in one call, from one crawl. Correlation is the product, not a convenience.

Which layer is harder to hide, and why does that matter?

The infrastructure layer. A domain owner controls what the page reveals, but not what DNS and TLS reveal. You can render your framework server-side, strip your generator meta tag, and route everything through a CDN, and your tech-stack signature goes quiet. You cannot receive mail without publishing MX records that name your provider, and you cannot terminate HTTPS without presenting a certificate whose issuer and SANs anyone can read.

That asymmetry matters for how you weight a dossier. When you score an ICP signal, the infrastructure layer is the sturdier floor. It tells you the hosting org, the CDN, the email provider, and the certificate hygiene even when the application code is opaque. The tech-stack layer adds resolution on top of that floor when the front end is readable.

So treat the two as a floor and a ceiling. Infrastructure gives you facts that are cheap to verify and expensive to fake. Tech stack gives you richer application detail when the page cooperates. Neither is the answer alone. The read you want lives in the correlation between them, which is why Bassethound ships them as distinct, aligned layers in one response.

Bassethound perspective

Most tools pick a side. BuiltWith and Wappalyzer own the tech-stack layer. Censys, IPinfo, and DomainTools own the infrastructure side. Each is good at its one axis, and each leaves you to be the integrator, running two vendors and reconciling two schemas before you learn anything a human could not have guessed.

Our conviction is that the boundary between these layers is where the signal lives, not a seam to paper over. The tech stack tells you the story a company chose to tell in its markup. The infrastructure tells you the truth its DNS and certificates cannot hide. Read one without the other and you get marketing or plumbing, never the whole animal. Read them together, correlated, and a Shopify front end confirmed by a Shopify origin means more than either fact alone, while a slick front end on bargain hosting with no DMARC tells its own story.

That is why fusion is the moat. An agent can fan out to five single-layer MCPs, but it pays for every round trip and still has to align the results by hand. Bassethound sniffs once and returns the correlation.

Sources

• MDN HTTP headers reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• IETF RFC 7208, Sender Policy Framework (SPF): https://datatracker.ietf.org/doc/html/rfc7208
• IETF RFC 7489, DMARC: https://datatracker.ietf.org/doc/html/rfc7489
• Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org