who-owns-this-domain

Who owns this domain

Registration data tells you who bought the name; DNS tells you who runs the service. They are frequently different parties, and conflating them is the mistake that wrecks attribution. Everything here is passive except where flagged — but note that dig aimed at the target's own nameservers lands in the target's query logs, so resolve through a public recursive resolver or passive DNS when you care about being quiet.

Which source first

WHOIS versus RDAP

WHOIS is a plaintext protocol on TCP/43 with no schema. Every registry emits a different field layout, clients follow registry-to-registrar referrals inconsistently, and rate limiting is silent — you get truncation or a block, not an error you can parse.

RDAP is the same registration data over HTTPS as JSON, with real HTTP semantics: 404 for no such object, 429 when you are throttled, and per-object endpoints for domains, nameservers, entities, IPs, and AS numbers. Query it through the bootstrap redirector or the registry directly:

curl -s https://rdap.org/domain/example.com | jq .
curl -s https://rdap.org/ip/203.0.113.10 | jq '.name, .handle, .country'
curl -s https://rdap.org/autnum/64500 | jq '.name, .entities'

Read these fields:

• events — registration, expiration, last changed, transfer. A

transfer event long after registration means the current registrar's records start there; anything older lives only in historical WHOIS.

• entities[].roles — registrant, technical, abuse, registrar. The

registrar entity carries its IANA ID in publicIds.

• status — EPP codes. clientTransferProhibited is routine. clientHold

means the registrar pulled the domain from DNS (nonpayment or an abuse complaint). serverHold means the registry did — usually legal or law-enforcement action. redemptionPeriod and pendingDelete mean it is expiring and about to become available.

• nameservers and secureDNS — operator fingerprint plus DNSSEC posture.

Some servers also return a machine-readable list of which fields were redacted, which is more useful than guessing from REDACTED FOR PRIVACY strings.

For .com and .net the registry is thin: it returns only registrar, dates, status, and nameservers. The contact block, such as it is, comes from the registrar's own server. Query both when they disagree — the registry is authoritative on dates and transfers, the registrar on contacts.

What redaction actually removes

Under current gTLD registration-data policy, registrant name, street, phone and email are usually stripped and replaced with a forwarding address or a web form. What survives and still pivots hard: registrar of record and its IANA ID, the reseller field when present, creation/update/expiry/transfer dates, nameservers, DNSSEC status, EPP status codes, registrant state/province and country (many registrars keep these), registrant organization (some keep it for legal entities, on the argument that a company name is not personal data), and the registrar abuse contact, which is never redacted and is the correct route for reports.

Distinguish the registrar of record (the ICANN-accredited party, e.g. Tucows, PDR, Namecheap) from the reseller that actually sold the domain, and both from a privacy service, which appears in the registrant field under its own corporate name and jurisdiction. The privacy service's identity is itself a lead: it tells you which registrar ecosystem you are in and where a disclosure request would have to go.

The DNS pass

dig +short example.com A; dig +short example.com NS
dig example.com MX +noall +answer
dig example.com SOA +noall +answer          # RNAME mailbox, serial often YYYYMMDDnn
dig example.com TXT +short                  # SPF and verification tokens
dig _dmarc.example.com TXT +short
dig google._domainkey.example.com TXT +short
dig example.com CAA +short
dig -x 203.0.113.10 +short

Do not build a workflow on ANY — most authoritative servers now answer it with a minimal or synthetic response instead of the full record set.

Every record type leaks something different: the interpretation table is in reference/dns-record-types.md and the mapping from SPF include hosts, DKIM selectors and TXT tokens to named vendors is in reference/vendor-fingerprints.md. The short version: TXT is a public inventory of the org's SaaS estate, MX names the mail security vendor, DMARC rua names their DMARC-reporting vendor, and CAA names the CA they standardized on.

IP, ASN, and what shared hosting costs you

whois -h whois.cymru.com " -v 203.0.113.10"        # ASN, prefix, country, AS name
whois -h whois.radb.net -- '-i origin AS64500'     # prefixes routed by that AS

The RIR record gives the netblock holder. If that is a hosting provider or cloud region you have learned nothing about ownership — a shared IP couples a domain to thousands of unrelated tenants, so "same IP" is worthless as attribution evidence. It becomes evidence when the RIR record shows a reassignment or sub-allocation to a named customer, or when the block is small and the org name is the target's.

PTRs are set by whoever controls the IP, not the domain owner. Clouds generate them mechanically from the address, which tells you only the platform. Colocation and enterprise blocks often carry customer names, and walking the PTRs of a /24 around a known host can hand you the org's whole rack.

Historical WHOIS and passive DNS

This is where the real pivots are. Redaction started at a point in time, so databases that captured records before it still hold names, emails and phone numbers; passive DNS keeps every observed answer, so you get IPs and hostnames the zone no longer serves. Ask three questions: what did the registrant field say before it went private, what other domains share that registrant email or name (reverse WHOIS), and what IPs has this name resolved to over time. DomainTools, SecurityTrails, WhoisXML, Validin, Silent Push and VirusTotal's domain reports carry some mix of the two — most gate the useful depth behind a paid key.

Zone transfers and zone walking

dig AXFR example.com @ns1.example.com asks a nameserver for the whole zone. It is an interactive TCP request to target-controlled infrastructure, it is logged, and it is out of scope for passive work — only inside an authorized engagement, and expect a refusal. A zone signed with NSEC rather than NSEC3 can likewise be walked to enumerate every name, and NSEC3 hashes can be cracked offline; both need direct queries to the authoritative servers. Treat both as active and use find-hidden-subdomains when you need to stay passive.

Where this goes wrong

• Registrant is a placeholder. Bulk registrars, resellers, privacy services

and corporate registrars all write their own details into contact fields. A matching registrant string across domains can mean one owner or one reseller.

• Dates lie about age. Expired-and-reregistered domains reset their creation

date at the registry, so a long archive history plus a recent creation date means the name changed hands through a drop.

• Cached and cloaked DNS. Answers are TTL-scoped snapshots, and providers

serve different records by geography, by resolver, and via split-horizon views you will never see. One resolver is one vantage point.

• SPF and TXT records rot. Present in SPF means "was configured", not "in use

now"; verification tokens are almost never cleaned up at all.

• MX and NS are outsourced. They identify the vendor. They become an

ownership signal only when the specific assigned nameserver pair or mail tenant label recurs across domains.

• Parked domains show registrar DNS and a marketplace IP. No owner

infrastructure to find. Squatters copy the target's SPF and MX wholesale to look legitimate, so mirrored records are not a relationship.

Confidence grading

• Confirmed — the registry or RIR states it directly and it is not a contact

field: creation date, registrar, EPP status, nameservers, netblock holder. Or: an unredacted registrant corroborated by a second independent source (a corporate filing, a historical snapshot, an archived page).

• Probable — a distinctive shared fingerprint across domains: the same

assigned nameserver pair, the same mail tenant label, the same DKIM key, the same CAA accounturi, the same unusual TXT token. Same operator, probably same owner.

• Unconfirmed — shared IP on shared hosting, shared registrar, shared public

DNS provider, or a registrant string that could be a reseller. Also anything from a historical database you have not seen the raw record for.

Always record the lookup timestamp and which server answered. A WHOIS record without a retrieval time is not evidence.

Worked example

Target: northwind-logistics.example, referred by a fraud team.

RDAP: created eleven months ago, registrar Namecheap, registrant redacted but country PA, status clientTransferProhibited, nameservers a Cloudflare pair (dana, rex). Young, cheap, proxied, origin hidden.

DNS: no MX at all, which kills the "they invoice from this domain" theory outright. TXT holds one google-site-verification token and an SPF record whose only include is a transactional-email vendor. DMARC is p=none with no rua, so there is no reporting vendor to pivot to. Dead end on the mail side.

Historical WHOIS is the break: a snapshot from two months after registration, pre-privacy-service, carries a Gmail address and a name. Reverse WHOIS on that address returns six more domains, four sharing the same dana/rex pair — and Cloudflare assigns that pair per account, so this is one operator, not chance.

Grade: registrant identity probable (one snapshot, corroborated by the nameserver cluster, not yet by a filing). Seven-domain cluster confirmed as one operator.

Pivots

Legal and ToS notes

Bulk WHOIS access is contractually restricted: registries and registrars forbid using it for marketing or for building redistributable databases, and enforce with rate limits and blocks. RDAP supports differentiated access, where a vetted authenticated requester sees more than an anonymous one — that vetting exists precisely so personal data cannot be bulk-collected anonymously. Pre-redaction registrant data pulled from a historical database is still personal data under GDPR: you need a lawful basis, and the minimization rules in ../../ETHICS.md apply. AXFR without written authorization can constitute unauthorized access.