Reading a WHOIS record: what actually matters for investigations

Pull the record for github.com right now and you get a small lesson in what modern WHOIS is and isn’t. The registrant email is a dead end: a link to domains.markmonitor.com/whois/github.com, a proxy form, no address behind it. But the record is far from empty. It was registered on 2007-10-09, carries three EPP locks (clientDeleteProhibited, clientTransferProhibited, clientUpdateProhibited), and its nameservers split across two providers, NSONE (dns1.p08.nsone.net) and AWS Route 53 (ns-421.awsdns-52.com). The organization even survived: Registrant Organization: GitHub, Inc. is still printed in the clear.

That single record kills two lazy assumptions at once. One, that redaction wiped out WHOIS. Two, that everything’s redacted. Neither is true. The contact channel is dead, the operational fields are intact, and whether the org name shows up at all depends on the domain. Reading a record well is knowing which fields to trust and which to skip.

The fields that still tell you something

Creation date is arguably the single most useful field left. github.com at 2007 versus a domain registered three days ago and already hosting a login page: two completely different risk profiles, and the field costs you nothing to read. Freshly created domains skew heavily toward phishing and fraud because operators burn and replace them. Check the age first, always.

The updated (or “last changed”) field is where things get interesting on old domains. github.com’s last change was 2024-09-07. A recent update on a long-lived domain can mean a transfer, a nameserver swap, or a change of control. On its own it’s just a timestamp. Line it up with a hosting move or a fresh certificate and it starts describing an event.

Expiration date is a cheap read on commitment. wikipedia.org, registered in 2001, sits paid-out to 2027. A domain registered for the bare one-year minimum and nothing more is easier to treat as disposable. It proves nothing, but it’s a reasonable prior.

The registrar rarely names the operator, and you’ll notice it repeats: github.com, wikipedia.org, and reddit.com all sit at MarkMonitor, a registrar built for corporate brand protection. That tells you something about the class of owner, not the identity. On its own the registrar is weak. Combined with other signals it adds context, and certain registrars do cluster with certain kinds of operators for price, privacy defaults, or how they handle abuse reports.

Nameservers are where WHOIS quietly stays useful. They’re almost never redacted, and they expose operational choices. wikipedia.org runs its own DNS on ns0.wikimedia.org through ns2.wikimedia.org, which ties it straight into the rest of the Wikimedia estate. github.com’s dual NSONE-plus-Route-53 setup reads as deliberate redundancy, an infrastructure decision made by someone who cared. Default registrar nameservers tell you the opposite: the operator didn’t bother, which is its own kind of signal.

You can watch this happen against a real record. Submit a domain, poll the job, and the result carries the WHOIS and RDAP fields it read, each one scored, with the redacted ones flagged instead of silently dropped. Swap YOUR_KEY for a key from your dashboard.

curl -X POST https://api.whoisgeni.us/analyze \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "github.com"}'
# -> poll the returned job_id:
curl https://api.whoisgeni.us/jobs/JOB_ID -H "X-API-Key: YOUR_KEY"

{
  "status": "completed",
  "domain": "github.com",
  "scoring_result": {
    "entities": [
      { "name": "GitHub", "display_name": "GitHub, Inc.", "entity_type": "organization", "confidence": 0.90 }
    ],
    "signals": [
      { "signal_type": "whois", "field": "registrant_org",  "raw_value": "GitHub, Inc.",            "redacted": false },
      { "signal_type": "whois", "field": "registrar",       "raw_value": "MarkMonitor Inc.",        "redacted": false },
      { "signal_type": "rdap",  "field": "status",          "raw_value": "clientTransferProhibited","redacted": false },
      { "signal_type": "whois", "field": "registrant_name", "raw_value": null,                      "redacted": true }
    ]
  }
}

The redacted registrant_name comes back flagged rather than dropped, and the operational fields (organization, registrar, EPP status) come through intact. That is the same read you’d do by hand, turned into structured output. (Example response, live values vary.)

Status codes get skipped constantly, and they shouldn’t. The EPP codes describe the domain’s lifecycle and lock state. github.com’s three client*Prohibited locks are set by the registrar and mean the domain is actively protected against deletion, transfer, and update. Other codes in the family carry heavier meaning: serverHold means the domain isn’t in the zone and won’t resolve, redemptionPeriod means it lapsed and is in the grace window before it drops. A domain that’s locked down hard and one that’s quietly falling out of the zone are telling you very different stories, and both are right there in the status list.

The fields that are mostly noise now

Contact data is where investigators waste the most time. cloudflare.com is the clean example: its registrant name, organization, street, city, postal code, and phone all read DATA REDACTED, and that same placeholder sits on millions of unrelated domains. A few notes on the contact block:

• Registrant name and organization are redacted on most in-scope domains, but not all. When a real org shows through, as with GitHub, take it. When it’s DATA REDACTED or REDACTED FOR PRIVACY, it’s worthless for correlation because everyone shares it.
• A non-proxy contact email is worth a lookup. A privacy-service or registrar-form email is not weak evidence, it’s zero evidence, and treating it as a lead just burns an afternoon.
• Phone and postal address follow the same rule. Real and present, useful. Redacted or registrar-generic, skip it.

The trap is anchoring on these fields because they’re what WHOIS used to be about. Glance, note whether anything’s real, move on if it isn’t.

WHOIS vs. RDAP

If you’re still scraping free-text WHOIS, move to RDAP wherever it exists. RDAP is the structured JSON successor: consistent field names, standardized status handling, and no parsing of registrar-specific text layouts that break the moment a registrar reformats its output. One practical difference you’ll hit immediately is status vocabulary. Legacy WHOIS prints clientTransferProhibited; RDAP hands you "client transfer prohibited" as a normalized string. Same lock, different spelling, and your tooling has to know both.

RDAP isn’t universal yet. A handful of TLDs, and plenty of ccTLDs, still only answer over legacy WHOIS or expose thinner data, so you’ll keep a WHOIS fallback around. But RDAP should be the default path, not the exception.

What redaction actually removes

GDPR redacts personal contact data. It does not touch the domain’s operational reality, and that distinction is the whole mental shift. Creation and update dates are structural. Nameservers are operational. Status codes are lifecycle metadata. DNS records, certificates, and hosting live entirely outside WHOIS and aren’t redacted by it at all. A redacted record isn’t a dead end. It’s a record with the contact block removed and everything that matters for attribution left standing.

Reading through the redaction

Historical WHOIS is the one angle that sees through redaction rather than around it. A domain that’s redacted today may have been wide open in 2016, before GDPR enforcement or before a privacy service got switched on. A registrant name that was public back then doesn’t un-happen because the current record hides it, and archived registration data sometimes still holds it.

The honest caveat is that this only works when the history exists. Plenty of domains were registered private from day one, or predate any archive that captured them, and then there’s nothing behind the curtain to recover. Historical WHOIS is a strong move when the record is there and simply silence when it isn’t.

One more failure mode worth naming, because it catches careful people: the creation date can lie. A domain that dropped and got re-registered, or was transferred between registrars, can present a date that looks either fresher or older than the actual continuity of control. wikipedia.org is the well-behaved case, keeping its 2001 registration date straight through a 2012 transfer. Others reset. When a creation date is load-bearing in your assessment, corroborate it against passive DNS or certificate history before you lean on it.

A two-minute triage pass

Read any record in this order and you’ll separate “worth a look” from “move on” faster than staring at the redacted registrant line ever will. How old is it, and did anything change recently? Whose nameservers, custom or default? What lifecycle state do the status codes show? Is any contact data actually real? And what did the domain look like historically, if that record exists at all?

WHOIS alone rarely closes an investigation now. Read correctly, it’s a sharp first filter and nothing more. The questions it can’t answer, who actually operates a domain and whether it ties to others, are exactly the ones that need signals from outside the registration record.

WhoisGenius pulls WHOIS and RDAP alongside DNS, certificates, hosting, and historical records into one scored view, so the operational fields that survive redaction get read together instead of one lookup at a time. Start free with 75 credits and run your first record. No credit card.