Looking Up IPv4 Blocks with WHOIS and RDAP

Registration data tells you who holds a block, who to contact about it, and whether a listing you have been shown is real. Both protocols carry the same data; RDAP is easier to parse and WHOIS is easier to type.

Query the right registry

Five RIRs hold IPv4 space, split by region: ARIN (North America), RIPE NCC (Europe, Middle East, Central Asia), APNIC (Asia-Pacific), LACNIC (Latin America and Caribbean), AFRINIC (Africa).

Querying without specifying a server usually works, because most whois clients follow referrals:

whois 198.51.100.1

To query a specific registry:

whois -h whois.ripe.net 193.0.6.139
whois -h whois.arin.net 199.71.0.1
whois -h whois.apnic.net 202.12.29.0

If the response says the block is administered by another registry, follow it. Space moves between regions through transfers, and the region a block was originally issued in does not determine where its record lives now.

Read the record

A RIPE inetnum object, trimmed to the fields that matter:

inetnum:        193.0.6.0 - 193.0.6.255
netname:        RIPE-NCC
descr:          RIPE Network Coordination Centre
country:        NL
admin-c:        BRD-RIPE
tech-c:         OPS4-RIPE
status:         ASSIGNED PA
mnt-by:         RIPE-NCC-MNT

The equivalent from ARIN uses different field names for the same concepts — NetRange, NetName, NetType, OrgName — which is the main reason RDAP exists.

Status is the field to read first. It tells you what kind of object you are looking at, and therefore who is responsible for the space.

The practical consequence: an ALLOCATED PA or Direct Allocation object describes a block the holder distributes to customers, so the party actually using a specific address is described by a more specific object, not this one.

Query over RDAP

RDAP returns JSON over HTTPS. Same data, structured.

curl -s https://rdap.arin.net/registry/ip/199.71.0.1 | jq .
curl -s https://rdap.db.ripe.net/ip/193.0.6.139 | jq .

If you do not know the registry, the bootstrap service resolves it:

curl -sL https://rdap.org/ip/198.51.100.1 | jq '.handle, .name, .country'

The bootstrap data itself is published by IANA at https://data.iana.org/rdap/ipv4.json, which is worth fetching directly if you are building anything that queries at volume.

Pulling out the abuse contact:

curl -sL https://rdap.org/ip/193.0.6.139 \
  | jq -r '.. | objects | select(.roles? and (.roles | index("abuse"))) | .vcardArray'

Entity roles in RDAP are explicit — registrant, technical, abuse, administrative — which is why it is the right choice for anything automated. Parsing WHOIS means writing a parser per registry and rewriting it when output formats change.

Both protocols rate-limit. Query in bulk and you will be throttled or blocked; registries publish bulk data files for that use case.

Resolve answers that look contradictory

Several objects cover the same address. A /16 allocation, a /22 sub-allocation inside it, and a /24 assignment inside that can all match one address. All three are correct. The most specific one describes the actual assignment and holds the contact you want; the covering objects describe who delegated it.

The record is in an unexpected region. Transfers move blocks between registries. ARIN’s ERX records also relocated a large amount of early space to the RIRs that took over those regions, so a block issued in the 1990s may sit in a database that did not exist at the time.

Legacy blocks look wrong. Space issued before the RIR system carries LEGACY status and often decades-old contact data. The organisation named may no longer exist. These records are where most listing fraud starts, because the apparent holder cannot contradict a claim.

The record and the routing disagree. Registration says who holds the block; BGP says who announces it. They differ legitimately when space is leased or delegated, and illegitimately when a block has been hijacked. Check the IRR route object and RPKI validity to see which.

Find the contact that will respond

Work from most specific to least. The assignment object’s contact is the operator; the allocation object’s contact is their upstream, who will forward your message at best.

• Abuse — abuse-c in RIPE and APNIC, pointing to a role object with abuse-mailbox; an abuse POC in ARIN. This is the address for reports of malicious traffic.
• Technical — tech-c, for operational questions such as routing and filtering.
• Administrative — admin-c, for questions about the registration itself.

Registries require abuse contacts to be maintained, and an unreachable one is a finding during a registry check — which is worth knowing from the other side too, when auditing your own records. See utilization and RIR audits.

Verifying a block before you buy it

Registration lookup is the first check on any block you are offered.

1. Confirm the holder exists and is who the seller claims. A mismatch between the seller and the registered holder needs an explanation before anything else proceeds.
2. Check the status. Legacy and PI space transfer under different rules from PA space, and PA space assigned from a provider’s allocation is generally not transferable at all.
3. Check the object age and maintainer. A record modified recently by a maintainer with no history is worth questioning.
4. Confirm it is not reserved. Cross-check against reserved and bogon ranges.
5. Check reputation and current routing separately. Registration data says nothing about blocklists or whether the block is announced by someone else today.

None of this replaces a broker’s due diligence, but it catches obvious problems in a few minutes. IPv4 services covers what a full transfer involves.

Related

• How to get an ASN — the other registry resource you will need
• Reserved and bogon ranges — what to cross-check against
• Utilization and RIR audits — maintaining your own records
• Glossary — registry terminology