Supply-Chain Dependency Mapping

A third-party-risk questionnaire asks which providers shopify.com depends on, and where one outage takes an entire function down with it. The vendor list in a contract system records what was bought; the zone records what actually answers, and those are not the same document.

Do I sign this domain off as concentrated only in mail, and what would tell me I am wrong?

Not "how many providers does it use". The provider count is an input to that question, and on this domain it is the input that points the wrong way.

• Whether a listed dependency carries anything. NAMESERVER_FOR, MAIL_FOR and SPF_INCLUDE are published records: delegation and authorization, never delivery. This domain authorizes three external senders; nothing says a message ever went through one.
• What runs behind the CDN. whisper.origins returned ten candidate addresses on 2026-08-09, every one at confidence 0.0948 by the links_to method alone, and the step's confidence bar drops all ten. The real origin is not established here — whisper.origins().
• Who the registrar is, by name. The ownership dependency comes back as iana:292, and the node's only other property is the type label REGISTRAR. That is an identifier, not a company.
• How much of the estate was read. shopify.com holds zero RESOLVES_TO edges of its own, so every hosting row comes from its subdomains: 171 of 22,358 known subdomains hold an address, and the step reads a 40-address sample of those. That is Coverage, not a census.

Measured 2026-08-09. DNS is delegated to three registrable apexes: foundationdns.com, .org and .net, one nameserver each. Mail is one provider, google.com, across five exchangers. Three external senders are authorized — google.com, sendgrid.net, zendesk.com — and DKIM signing names one vendor, google. The 40 sampled addresses route to three networks: AS13335 CLOUDFLARENET with 33, AS40934 FORTINET with 5, AS15169 GOOGLE with 2. Across a wider sample of 190 subdomain delegations, 135 land on AS13335 and 27 on AS40934.

The concentration reading those counts produce flags exactly one thing: all inbound mail on one provider. DNS at three and hosting at three do not trip it. No step returns a threat verdict, so nothing in this run says whether any provider is listed anywhere.

The physical section came back empty, and empty is where to stop and re-read the query rather than the world. Its step binds a variable inside a bounded subquery and re-binds the same name outside it; the re-bound nodes serialize with an empty name and every pattern comprehension on them returns nothing. Rename the outer variable and the identical walk returns five rows: Cloudflare at 1,503 facilities and 356 exchanges, Google at 1,042 and 177, Fortinet at 226 and 29, Google Cloud at 7 and 2, Amazon at 0 and 0. Zero rows is never a verdict. Here it was a variable name.

Three apexes read as three DNS providers. The hostnames behind them do not: gold.foundationdns.com, gold.foundationdns.org, gold.foundationdns.net, one label wearing three TLDs.

whisper.identify on all three returns Cloudflare, category cdn, roles DNS_OPERATOR, ORIGIN_AS, CDN. Their nine addresses route to one network, AS13335 CLOUDFLARENET, nine of nine. That is the same network carrying 33 of the 40 sampled addresses in the hosting row.

DNS and hosting are one company. The map counts them as separate functions with three providers each because the fold that makes providers comparable is the registrable apex, and an apex is not an operator. The run already calls the procedure that closes this, on the target, where it returns no vendor name at all; pointed at the providers it answers in one call — whisper.identify().

Four results would overturn the paragraph above, and each is a query rather than an opinion.

• whisper.identify returning a different operator for any of the three nameservers. All three returned Cloudflare; a run that splits them ends the single-operator reading.
• A nameserver address routing to something other than AS13335. Nine of nine routed there, and one exception makes DNS genuinely multi-network.
• A fourth nameserver on the zone, from a second operator. The graph holds three NAMESERVER_FOR edges and all three are gold.foundationdns.*.
• whisper.origins clearing its confidence bar on a non-Cloudflare origin network, which would make Cloudflare a front rather than the host.

The nameserver and routing legs are runnable on Posture Audits and BGP & RPKI.

The external supply chain of shopify.com concentrates on two vendors, not six. Cloudflare operates DNS and carries 33 of the 40 sampled addresses. Google receives all inbound mail, signs DKIM, and appears again as an authorized sender. Fortinet, SendGrid and Zendesk are real dependencies and small ones here. The single point of failure is not "mail" alone — it is Cloudflare across two functions the map reports separately.

Attack that at three joints, each named so you can test it:

• the operator fold rests on whisper.identify, which is a vendor attribution and not a contract;
• the hosting share rests on a 40-address sample of 171 resolving subdomains, so a different sample can move it;
• the physical row exists only because a step's zero rows were re-read as a defect in the query, which anyone can dispute by running both forms.

A dependency map with a falsification list can be argued with. One without it can only be believed.