Supply-Chain Dependency Mapping
Maps every external provider a domain depends on — nameservers, mail exchangers, third-party email senders (SPF), CDN and hosting networks, registrar and DKIM vendors — by reading each layer of the graph and keeping only providers whose registrable apex differs from the target’s own. Each dependency is grouped by function and the flow flags single-vendor concentration: one DNS operator, one mail provider or one hosting network is a single point of failure whose outage takes the whole function down. The mirror of Digital Infrastructure Mapping: that flow maps what an entity owns, this maps what it depends on.
How it uses the graph
Traverses the DNS, email, BGP, WHOIS, physical layers of the graph, in 11 steps:
Attributing the domain to its operator…
Resolving the registrable apex (eTLD+1)…
Finding the external nameserver operators…
Finding the external mail exchangers…
Reading the domain registrar…
Mapping the networks the addresses sit on…
Reading the third-party SPF senders…
Peeling back any CDN front to the real origin…
Reading the DKIM signing vendors…
Grouping the subdomain estate by the network it delegates into…
Mapping the physical facilities the hosting networks sit in…
Why each step runs
- 01Operator (atlas). whisper.identify names who operates the domain itself — the vendor, its category and derived roles. It is the anchor the external dependencies hang off: everything run by a DIFFERENT apex is a supply-chain dependency.
- 02Registrable apex. whisper.psl.tldPlusOne collapses a host to its registrable domain via the Public Suffix List — the reference apex every provider is classified against. A provider whose apex matches this is self-hosted; a provider whose apex differs is an external dependency.
- 03DNS providers. The nameservers that answer for the domain (NAMESERVER_FOR, reverse), folded to their operator apex and kept only where that apex differs from the domain's own — the third-party managed-DNS vendors. DNS root servers are filtered. One operator answering for the whole zone is a single point of failure.
- 04Mail providers. The mail exchangers accepting inbound mail for the domain (MAIL_FOR, reverse), folded to their operator apex and kept only where external — the mail provider (Google Workspace, Microsoft 365, …). A single mail operator handling all inbound is a concentration risk.
- 05Registrar. The registrar the domain is registered through (HAS_REGISTRAR) — the ownership-layer dependency that controls the domain's very existence. Registrar lock and transfer-control policy live here.
- 06Hosting networks. The networks (ASNs) that route the domain's addresses — its own IPs and a sample of its subdomains (RESOLVES_TO → ANNOUNCED_BY → ROUTES), with the ASN name and registrant org. This is the compute/CDN hosting dependency. A single dominant network is a hosting single point of failure.
- 07Authorized email senders. The third-party senders the domain authorizes to send mail on its behalf (SPF_INCLUDE), folded to their operator apex and kept only where external — SendGrid, Zendesk, Salesforce, Mailchimp and the like. Each is a delegated-trust email-delivery dependency.
- 08De-CDN origin. whisper.origins de-fronts a CDN to the real origin IP and ASN behind it (high-confidence origins only; the bar adapts to the score scale). The origin network is the actual hosting dependency the CDN hides — the provider the service truly runs on.
- 09DKIM signing vendors. The vendors that DKIM-sign mail for the domain (DKIM_SIGNED_BY → VENDOR) — the cryptographic email-authentication dependency. A pattern-comprehension keeps it to one row whether or not the edge is populated.
- 10SaaS subdomain delegations. Which external networks the subdomain estate actually delegates into: sample the resolving subdomains (CHILD_OF → RESOLVES_TO → ROUTES) and tally by ASN. Subdomains pointing into AWS, Google Cloud, Fastly, Zendesk and the like are SaaS/cloud dependencies woven through the namespace.
- 11Physical dependency. The datacenter facilities (AS_PRESENT_AT) and internet exchanges (IX_MEMBER) the hosting networks are physically present at — the deepest supply-chain layer. Sparse: only networks with PeeringDB coverage report it.