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
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
| You hold | Reach for | Why |
|---|
| A domain, nothing else | RDAP, then registrar WHOIS | Structured, gives dates + registrar + status in one hit |
| Redacted WHOIS | Historical WHOIS + passive DNS | Redaction is not retroactive across archives |
| A domain you suspect is one of many | Nameserver pair + MX + reverse WHOIS | Infrastructure reuse outlives contact privacy |
| An IP | IP RDAP at the RIR, then ASN lookup | Tells you the netblock holder, not the site owner |
| A ccTLD | The registry's own WHOIS/web service | ccTLDs ignore gTLD policy; coverage swings wildly |
| A brand-new domain | Creation date + registrar + NS | Age plus a bulk-friendly registrar is the phishing tell |
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:
bash
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:
- — , , , . A
event long after registration means the current registrar's
records start there; anything older lives only in historical WHOIS.
- — , , , . The
registrar entity carries its IANA ID in .
- — EPP codes. is routine.
means the registrar pulled the domain from DNS (nonpayment or an abuse
complaint). means the registry did — usually legal or
law-enforcement action. and mean it is
expiring and about to become available.
- and — 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
strings.
For
and
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
bash
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
— 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
names their DMARC-reporting vendor, and CAA names
the CA they standardized on.
IP, ASN, and what shared hosting costs you
bash
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
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 , 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
, status
, nameservers a Cloudflare pair
(
,
). Young, cheap, proxied, origin hidden.
DNS: no MX at all, which kills the "they invoice from this domain" theory
outright. TXT holds one
token and an SPF record whose
only include is a transactional-email vendor. DMARC is
with no
, 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
/
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
| New selector | Goes to |
|---|
| Subdomains, siblings on shared certs | |
| IPs, netblocks, ASNs | |
| Registrant email, mail vendor, forwarding address | |
| Registrant org, privacy-service jurisdiction | , |
| Registrant phone from a pre-redaction snapshot | |
| Historical content at recovered IPs and hostnames | |
| Indexed files on discovered hostnames | |
| A cluster of domains, IPs and registrants to lay out | |
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.