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.