How to tell if two domains are run by the same operator

Run a WHOIS-plus-DNS lookup on shodan.io and censys.io on the same afternoon and you get a strange result. Both resolve into Cloudflare’s network: the same ASN (AS13335), the same TLS termination, edge IPs sitting right next to each other in 104.18.0.0/15. On the shape of their infrastructure alone, they look like the same shop.

They aren’t. Shodan and Censys are competitors: two separate companies running two separate internet-wide scanning engines. They share nothing but a CDN that a large slice of the internet also sits behind. A naive correlation (match on shared network, shared nameserver, neighboring IPs) links them anyway, and does it with a straight face. That is the whole problem in one example. The distance between sharing infrastructure and sharing an owner is where domain correlation succeeds or embarrasses you.

Here is how we close that distance, and where it still goes wrong.

Registrant data is mostly a dead end now

The obvious move is to match two domains by who registered them. On the domains actually worth investigating, that move is dead. ICANN wound down public WHOIS, GDPR redacted registrant contact details for anyone in scope, and the field where a name used to sit now reads “REDACTED FOR PRIVACY” or “Privacy Protect, LLC.” That same placeholder appears on millions of unrelated domains. Correlating on it isn’t just weak. It manufactures false positives that look confident.

A few exceptions are still worth a first glance, because when they land they land hard:

• Non-redacted registrant details on corporate domains, older registrations, and a number of ccTLDs that never adopted blanket redaction.
• A shared registrant email across a portfolio. Two domains both listing admin@acmeholdings.example is a direct line.
• Reverse-registrant lookups: given one confirmed identity, you can sometimes pull the whole set of domains behind it.

Check them, take the win if it’s there, and don’t expect it. The hard cases, the ones you’d actually open an investigation for, won’t hand you a registrant. You need signals that outlive privacy protection.

Stop asking who registered it. Ask how it’s run.

A live domain is doing work. It points DNS somewhere, terminates TLS, serves content, routes mail, and usually wires up analytics and ads. Every one of those is a choice the operator made, and people reuse their choices: the same nameservers, the same analytics account, the same page template they already know works. Reuse is the signal. It survives redaction because it lives in the domain’s operation, not its registration record.

Where operators actually overlap

Roughly strongest to weakest:

1. Ownership-level identifiers. Analytics and tag-manager account IDs, ad-network publisher IDs, and other account-scoped tokens sitting in the page source. These point at a billing account, a person paying a bill, not a shared server. A match here is close to a fingerprint.
2. Certificate and hostname structure. Shared TLS certificate subjects or SAN patterns, and consistent host-naming conventions (ns1.acmeholdings.example, mail.acmeholdings.example) that reveal one hand at the keyboard.
3. Mail and DNS configuration. Matching MX setups, custom nameservers, and DNS record layouts that reflect a specific way of doing things.
4. Origin infrastructure. The real host behind the CDN: origin IP, hosting provider, network (ASN), once you resolve past the proxy layer.
5. Content and structural fingerprints. Reused templates, boilerplate, favicons, page structure.

No single row is proof. The work is in combining them, and in being honest about which rows are cheap coincidences.

Shared infrastructure is not shared ownership

Back to Shodan and Censys. They collide on rows 4 and 5, same CDN and neighboring edge IPs, and share nothing on rows 1 through 3. That is the exact profile of a coincidence, and it’s the mistake that sinks most naive correlation: reading coincidental infrastructure as common ownership.

Two domains can share an IP because they’re behind the same CDN edge along with a million strangers. They can share a nameserver because they both took a popular registrar’s default DNS. They can share an ASN because they’re both on the same cloud. None of that means one operator. It means they made the same cheap, popular choice that half the internet also made.

The rule we hold to:

Popular, shared infrastructure is weak evidence. Account-scoped, operator-specific identifiers are strong evidence.

So when signals are weighed, “everyone uses it” has to count for far less than “you specifically configured this,” or every unrelated site on a big cloud provider falsely clusters into one giant blob. Corroborate across independent signals, and never on shared infrastructure alone. One shared analytics account plus a matching origin network is a real lead. Two domains that merely sit behind the same CDN are not.

That bias has a cost, and it’s worth stating plainly. A careful operator who uses different registrars, different clouds, and no shared analytics can run two domains that genuinely trace back to them and still look unrelated to us. We would rather return “no strong link” than invent one. We miss the disciplined operators to avoid smearing the innocent ones. Know that’s the trade you’re making, in either direction.

Run it yourself

Correlation is two calls: submit the domains, then poll the job for the result. Swap YOUR_KEY for a key from your dashboard and this runs against your own account as written.

# 1 — submit the domains
curl -X POST https://api.whoisgeni.us/correlate \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domains": ["google.com", "youtube.com", "shodan.io"]}'
# -> { "job_id": "corr_a1b2c3d4e5f6", "status": "pending" }

# 2 — poll the job until status is "completed"
curl https://api.whoisgeni.us/correlate/corr_a1b2c3d4e5f6 \
  -H "X-API-Key: YOUR_KEY"

The finished job hands back the clusters, the per-pair scores, and the shared signals behind each one. google.com and youtube.com cluster on operator-specific signals; shodan.io shares none of them and stays unclustered. (Example response, live values vary.)

{
  "data": {
    "correlation_id": "corr_a1b2c3d4e5f6",
    "status": "completed",
    "domain_count": 3,
    "result": {
      "clusters": [
        {
          "cluster_id": "clst_1",
          "confidence": 0.91,
          "domains": ["google.com", "youtube.com"],
          "shared_signals": [
            { "signal_type": "registrar", "value": "MarkMonitor Inc.", "domains_sharing": 2, "all_domains": true },
            { "signal_type": "ssl_subject_org", "value": "Google LLC", "domains_sharing": 2, "all_domains": true }
          ]
        }
      ],
      "unclustered_domains": ["shodan.io"],
      "pairwise": [
        { "domain_a": "google.com", "domain_b": "youtube.com", "correlation": 0.91, "shared_signals": ["registrar", "ssl_subject_org"] },
        { "domain_a": "google.com", "domain_b": "shodan.io", "correlation": 0.03, "shared_signals": [] }
      ]
    },
    "error": null
  }
}

A workflow that survives a second look

1. Resolve past the proxy first. Get to the origin, the real host behind any CDN or privacy layer, before you compare anything. Comparing edge IPs is how you “prove” Shodan and Censys are siblings.
2. Collect signals by category for both domains: registration, certificates, DNS and mail, origin network, embedded identifiers.
3. Match within a category, then across. Tag every overlap as operator-specific or shared/popular as you go.
4. Discount the coincidences. Anything a large number of unrelated domains would also share gets down-weighted, hard.
5. Require independent corroboration. No clustering on a single signal, and never on a purely infrastructural one.
6. Keep the evidence: which signals matched, and how strong each was.

Step 6 carries more weight than it looks. A correlation you can’t explain is a correlation you can’t defend, whether the audience is an incident report, a UDRP filing, or a five-minute argument with a skeptical colleague who thinks you’re pattern-matching on nothing.

Doing this at portfolio scale

Two domains by hand is tedious but fine. A portfolio of hundreds is a different animal: resolving every origin past its CDN, pulling signals in every category, weighting each one consistently, and keeping the evidence trail for all of it. At that point it stops being a manual job and starts being a pipeline.

That pipeline is what WhoisGenius is. It resolves origins behind CDNs, fuses the signal categories above, counts account-scoped identifiers for more than coincidental infrastructure, and hands back a per-signal breakdown of why two domains did, or pointedly did not, correlate.

Start free with 75 credits and run your first correlation. No credit card.