Digital Infrastructure Mapping

A supplier review lands with one line under critical vendors: github.com. The reviewer wants the estate behind that name — what the owner runs, and who else is inside the boundary.

Do I sign this off as one supplier, and what would tell me I am wrong?

Not "who owns github.com". A registrant lookup answers that in one call, and on this domain it answers github hostmaster — a string, not an owner, and nowhere near an estate.

• Which hostnames on an owned address belong to the owner. 140.82.121.3 carries 21 resolving hostnames, among them torad.cfd, vip-banana.cdn661.com and codeweaver.guru. Address attribution counts them as co-tenants for exactly that reason: no edge records who pointed them there.
• The owner of a host under a private suffix. Apex resolution follows the Public Suffix List, so raw.githubusercontent.com collapses to itself, and that node holds zero REGISTERED_BY and zero HAS_EMAIL edges. Seed githubusercontent.com instead and both come back, which is what the naming and lookup helpers are for.
• Whether the announced prefixes are protected. The RPKI step counts ROA_AUTHORIZES_ORIGIN edges, five of them on AS36459, and never checks that each of the 26 announced prefixes falls inside one.
• How much of the estate was reachable at all. That is the coverage qualifier, and it is the first thing to read rather than a footnote — Coverage.

No step in this run calls a scoring procedure, and none is wanted here. What comes back is an attribution with its evidence attached, and the useful part is that the run answers "who" three separate ways and the three do not agree.

whisper.identify returns the atlas operator: Github, category saas, host class multi_tenant_user_content. WHOIS returns the registrant string github hostmaster, which SAME_ORG_AS folds onto GitHub, Inc.; the apex in fact carries two organization strings, github hostmaster and github,, and both fold onto that one node. The network layer returns four addresses on two networks, AS36459 (GITHUB) and AS8075 (Microsoft Corporation).

A host with no registrant returns a row of nulls, the way raw.githubusercontent.com does. It never returns an empty result set: zero rows is never a verdict.

The registrant email is the pivot, and no amount of name matching finds it. hostmaster@github.com is attached to 231 hostnames, and the ones that matter are the ones with no "github" in them: speakerdeck.asia, npmjs.app, probot.app, hubot.app, octoc.at, brickworkapp.com, codeconf.com and ghub.com, alongside defensive misspellings such as gitgub.com, gisthub.com, git-hub.com and choosealicence.com.

An estate assembled from the supplier's name carries none of those. The edge that finds them runs one hop out of the apex and back — Pivoting examples.

Ask which networks actually carry the estate, because that is what "one supplier" rests on.

github.com publishes 36,131 subdomains. 232 of them resolve through to a routing ASN, and seven networks carry those: AS36459 (GitHub) 178, Fortinet 33, Fastly 17, Microsoft 7, Cloudflare 2, Amazon 1, MailChimp 1. The figures sum past 232 because one host can resolve onto more than one network. The workflow's own tally counts edges rather than distinct hosts and moved between two consecutive runs (228, then 227), so read the per-network rows and not the total.

Delegation says the same thing one layer earlier. The apex's nameservers are awsdns and nsone.net hosts, neither run by the owner; mail goes to aspmx.l.google.com and github-com.mail.protection.outlook.com; and eight SPF_INCLUDE edges authorize third parties — _spf.salesforce.com, mail.zendesk.com, mktomail.com, servers.mcsv.net among them — to send as github.com. whisper.identify lists DNS_OPERATOR among the roles while NAMESERVER_FOR names two DNS vendors. Read the edges, not the role.

Both queries, with output, sit on Compliance evidence and Posture audits.

github.com attributes to GitHub, Inc. behind two WHOIS strings, and the estate is 231 registered hostnames, 36,131 published subdomains, 26 prefixes announced by AS36459, and presence at 45 facilities and 3 exchanges. The vendor boundary is not where the name stops — six networks the owner does not run carry part of the namespace, and DNS, mail and SPF are delegated outward. "One supplier" is the wrong unit for the review.

Four things would change that, and each is a query:

• a second unmasked registrant contact on the apex, which would split the estate — this one has exactly one;
• a masked registrant, which yields the flag and no estate: cloudflare.com carries domains@cloudflare.com next to noreply@data-protected.net, and a domain carrying only the second has nothing to pivot on;
• a later run of the hosting tally, since network membership churns and a moved subdomain re-ranks the vendors;
• an origin behind the fronts. whisper.origins returned ten candidates for this seed and the run published none: the two strongest sat at confidence 0.4499, under the step's own bar, both in IANA special-purpose space (198.18.1.190, 192.0.2.2) with no routing ASN attached. Where the service runs behind Fastly and Cloudflare is not established here.