WHOIS vs RDAP: how to read an IP registration record
Running a whois is the first thing everyone does with an unfamiliar address, and reading the answer well is rarer than it should be. The record comes back as a wall of keys in one of several registry dialects, most of the lines do not matter, three or four matter a great deal, and the whole thing is self-reported. Here is what WHOIS and RDAP actually are, which fields to read, and where the record stops being evidence.
Two protocols, one record
WHOIS is the old way: a plain-text query over port 43, answered in whatever key-value dialect the registry behind it prefers. It has no schema, no standard field names and no built-in way to find the right server, which is why the same lookup gives you inetnum at one registry and NetRange at another, and why tools pile heuristics on top to make sense of it.
RDAP is the same registry data served properly: a standardised, JSON-based protocol the registries adopted in the mid-2010s, with defined fields, defined contact roles, and a bootstrap mechanism that routes a query to whichever of the five regional registries, ARIN, RIPE NCC, APNIC, LACNIC or AFRINIC, actually holds the record. Same facts, machine readable shape. When a tool gives you clean, consistent registration data across regions, RDAP is doing the work; when you want the registry's own raw wording, the whois-style key-value view is still worth reading, which is why a good report keeps both.
The identity fields
The first thing the record answers is what block you are actually looking at: the range or CIDR the registration covers, which is regularly larger than the address you queried, plus the block's name, its handle, and its registered country.
Two of these deserve more scepticism than they get. The netname is a label the holder typed, not a classification: a block named CUSTOMER-HOSTING-01 tells you what somebody chose to call it, nothing more. And the country is the registration country, which is not necessarily where the addresses are used, a distinction that matters more every year as space is leased across borders and geolocation chases the difference. The allocation status carries the registry's own vocabulary for how the block was issued, an allocation to a provider or an assignment to an end user. It goes by different names: status at RIPE NCC and APNIC, NetType at ARIN, and type in RDAP, where status means something else and usually just says active. Read it in the registry's terms rather than guessing across dialects.
The dates, which matter most
If you read only one thing beyond the holder, read the dates. A record carries two: when the block was first registered with the registry, and when the record last changed. They are the record's only built-in history, and they change decisions.
A registration from the 1990s under a holder that has not changed in twenty years is a boring record, and boring is what good looks like. A last-changed date from a few weeks ago on otherwise old space means somebody recently edited the record, and the interesting question is who and why: a routine contact update reads very differently from a change that coincides with the block being transferred or newly announced. The record itself will not tell you which; it only shows the current state, which is exactly why the date is a prompt to go read the block's history rather than a fact that settles anything on its own.
The contacts
The contact most lookups are really for is the abuse contact, the mailbox that is supposed to answer when addresses in the block misbehave. RDAP gives contacts defined roles, registrant, administrative, technical, abuse, so the abuse mailbox is findable without guessing which of five email addresses in a text blob is the right one.
Read the contacts for coherence as much as for the addresses themselves. Contacts that match the holder, resolve to a real organisation and have survived a few years are a quiet good sign. A record whose contacts changed recently, point at a free mailbox provider, or differ oddly from the holder's name is not proof of anything, but it is one more thing that does not line up, and reading records is largely the business of counting those.
Parents, allocations and assignments
Registrations nest. A registry allocates a large block to a provider; the provider assigns smaller pieces to customers; each level can have its own record with its own holder and contacts. The record you land on is one level of that hierarchy, and the parent chain above it is part of the answer: a small assignment inside a hosting provider's allocation is a different object from a direct registry allocation of the same size, with a different party responsible for it.
Getting the level right is also how you avoid the most common attribution mistake: blaming a whole provider for something one customer's assignment did, or the reverse. The covering block for the exact address, its parent, and who holds each is precisely the question an investigation needs answered before any conclusion about who is responsible.
What a record can and cannot prove
Everything above comes with one caveat that outranks the rest: registration data is self-reported. The netname, the description, the contacts, even the organisation name are typed in by the holder and edited at will. Registries validate some things sometimes; they do not audit prose.
So treat the record as testimony, not as measurement. It is excellent evidence about intent and diligence: a tidy, stable, coherent record is the signature of an operator who maintains things, and a stale or incoherent one is a signal in itself, which is why network research starts here. It proves nothing about behaviour. What the addresses have actually been doing lives in routing history, reputation readings and measurements, and the useful habit is reading the record beside those rather than instead of them. A lookup that shows the registration, the raw whois lines verbatim, and the block's dated history on one page exists precisely so the testimony and the evidence can disagree in front of you, which is the moment a record becomes genuinely informative.
Look up any address or prefix on the front page to read its registration beside its routing and reputation history, with the raw whois lines kept verbatim. The report names the source and date behind each fact, and says plainly when nobody has checked something.