An IP address can lead you to the registry record for a network range, but it rarely leads straight to the person or system you are investigating. The public record may identify an internet service provider, university, enterprise, government, cloud platform, or downstream customer. It can also provide technical and abuse contacts. That is useful evidence, provided you do not turn the registered holder into an unsupported claim about the server's physical location, the current route, or the user behind an event.
People still call this an IP WHOIS lookup because TCP port 43 WHOIS was the original access method. RDAP is now the better programmatic interface. It returns defined JSON objects over HTTPS and can discover the correct service from IANA bootstrap data. WHOIS and RDAP expose registration data from the same broad number-resource system, but their transport and response formats differ.
How internet number registration works
IANA coordinates the global IPv4, IPv6, and autonomous system number spaces. It allocates large number-resource blocks to five Regional Internet Registries. AFRINIC serves Africa, APNIC serves the Asia-Pacific region, ARIN serves Canada, the United States, and parts of the Caribbean, LACNIC serves Latin America and parts of the Caribbean, and the RIPE NCC serves Europe, the Middle East, and Central Asia. Each RIR applies policies developed by its regional community.
The registration chain can continue through a national registry, local internet registry, ISP, hosting provider, or other network operator. A more-specific reassignment may identify a downstream organization, but not every small customer assignment is public. ARIN, for example, says that some small ISP reassignments and privatized residential customers are absent from its public registry. The upstream provider may be the most specific public contact available.
Legacy registrations add another layer. Some address space was assigned before the modern RIR system. Those records can be broad, old, or later divided. A common outdated example says MIT holds all of 18.0.0.0/8. ARIN's live records on 10 July 2026 show MIT registered for 18.0.0.0 through 18.31.255.255, which is 18.0.0.0/11. ARIN shows the larger 18.32.0.0 through 18.255.255.255 range registered to Amazon. A historical allocation label is not a substitute for a current authoritative lookup.
IPv4 exhaustion also does not mean every new registration comes from a simple sale. IANA's unallocated IPv4 supply is exhausted, but RIR policies still cover transfers, returns, recovered space, reserved pools, waiting lists, and limited final allocations. The details differ by region and change over time. For an operational decision, use the current RIR record and policy rather than a fixed exhaustion date or a claim that one RIR is the only source with space.
WHOIS and RDAP are access methods, not different ownership systems
Legacy WHOIS is defined in RFC 3912. A client sends a text query over TCP and receives an unstructured text response. RIRs use different object models and field names, so a parser written for one service may not work on another. WHOIS referrals can point from IANA to the responsible RIR and from a broad allocation to a more-specific record.
RDAP is a family of standards. RFC 7480 defines HTTP transport, RFC 7482 defines the query paths, and RFC 7483 defines JSON responses. RFC 9224 covers authoritative service discovery. For an IP query, the response can contain a start address, end address, handle, name, type, country code when supplied, events, links, notices, and entities with roles such as registrant, technical, administrative, or abuse.
curl -s 'https://domscan.net/v1/rdap?type=ip&query=8.8.8.8' \
-H 'X-API-Key: YOUR_KEY' | jq '{status, rdap: .rdap}'The type parameter matters. DomScan's RDAP API treats an untyped query as a domain by default, so an IP address or CIDR requires type=ip. Autonomous system queries use type=autnum. The browser RDAP form currently focuses on domains, while the API supports all three object types. The response keeps the raw RDAP object inside DomScan's response envelope and adds lookup and entity summaries. It does not rewrite every RIR response into a fictional universal ownership record.
Reading a network RDAP record
Start with the range. startAddress and endAddress show the registered network block containing the queried address. A CIDR representation may also be present or can be derived when the range aligns to a prefix. The range answers which registration object is most specific in the service response. It does not prove that every address in the block is used by the same application, tenant, or physical site.
Next read the handle, name, type, parent handle, and events. The handle is the registry's identifier for the network object. The name is a registry label, not necessarily a legal company name. The parent links the object to a broader allocation. Event dates can record registration or last-change activity, but a recent update may reflect administrative maintenance rather than a new operator.
Entities provide the organization and contacts associated with the record. Read their roles before using them. An abuse contact is the operational destination for a report, while a registrant entity represents the holder recorded by the registry. A technical contact may maintain the record without operating the service you observed. Contact data can also be stale or indirect, so an unanswered mailbox does not invalidate the range itself.
As a date-stamped example, ARIN's authoritative RDAP response for 8.8.8.8 on 10 July 2026 returns the range 8.8.8.0 through 8.8.8.255, handle NET-8-8-8-0-2, name GOGL, and a registrant entity with handle GOGL. That supports the statement that ARIN registers this /24 to Google's organization record. It does not tell you which Google service produced a packet, where the serving machine was located, or who used the address at a particular time.
What the registry record does not prove
- It does not provide authoritative BGP routing information or prove which autonomous system originated the route at the event time.
- It does not guarantee the physical location of a server, user, or network. A postal contact address is not a geolocation measurement.
- It does not establish data residency. A global provider can register a block in one jurisdiction and use addresses across many regions.
- It does not identify a cloud, VPN, CDN, hosting, or ISP customer unless a more-specific public reassignment names that customer.
- It does not identify an individual behind carrier-grade NAT, a shared proxy, or a dynamically assigned residential address.
- It does not establish malicious intent. A registered provider can host both legitimate and abusive customers.
ARIN states these limits directly. Its public registry does not contain routing information, and ARIN cannot guarantee that the address in a resource record is the network's physical location. Investigators who need a subscriber must usually identify the correct ISP or downstream provider, preserve the relevant timestamp and port information, and follow the appropriate legal or abuse process.
Registration, routing, geolocation, and reverse DNS are separate signals
A registry record answers who is recorded as holding or administering a number-resource range. BGP observations answer which autonomous system announced a prefix from a particular vantage point and time. RPKI and validated Internet Routing Registry data can help evaluate whether an origin is authorized. These sources can agree, but they are not interchangeable. Route leaks and hijacks are precisely the cases where registration and observed routing can diverge.
IP geolocation is another inference layer. Commercial and community datasets estimate country, region, city, network, or usage type from routing, provider, measurement, and registration signals. Accuracy varies by field and address. DomScan IP Lookup uses a geolocation and network provider plus DomScan enrichment, security classification, and forward-confirmed reverse DNS. It does not return the authoritative RIR RDAP allocation object or its abuse contacts.
PTR data is operator-supplied naming metadata. A reverse DNS result such as mail.example.net can help identify how an address is intended to be used. Forward-confirmed reverse DNS checks whether the PTR name resolves back to the address. Even a successful confirmation does not prove the legal holder, tenant, or person behind traffic. Treat it as one consistency signal.
Cloud, CDN, VPN, and shared address limits
A public cloud address normally returns the cloud provider or an upstream network record. The registry cannot reveal the customer account renting a virtual machine. A CDN address identifies shared edge infrastructure, not the origin server for every website using that edge. A VPN exit identifies the registered network or hosting provider, not the subscriber. An abuse report should include the source address, exact UTC time, destination, protocol, ports, and supporting logs so the provider can search its private records.
Carrier-grade NAT creates the same attribution problem at larger scale. Many subscribers can share one public address. The public registry points to the carrier, while subscriber attribution may require the carrier's time-sensitive mapping of address, source port, and timestamp. A bare IP without time and port data may be insufficient even for the provider that operated the NAT.
A practical investigation workflow
- Preserve the original evidence, including the full IP address, UTC timestamp, source and destination ports, protocol, request data, and log source.
- Confirm that the address is public and globally routable. Private, documentation, loopback, link-local, multicast, and other special-purpose ranges need different handling.
- Query RDAP with type=ip and record the returned range, handle, entities, roles, notices, links, and event dates.
- Use DomScan IP Lookup or another independent source for geolocation, ASN, datacenter, proxy, security, and FCrDNS context, while labeling those fields as enrichment.
- Check time-relevant routing or RPKI evidence if the announcing network matters. Do not infer the route solely from the registration holder.
- Send a focused report to the abuse contact or provider workflow. State the observed behavior and evidence rather than accusing the registered organization of intent.
For a whitelist or vendor review, ask the vendor to document the specific prefixes and service relationship. A matching RIR holder can support the review, but it cannot prove a shared cloud address belongs exclusively to that vendor. For data-residency work, use provider contracts, deployment configuration, logs, and verified architecture. Country fields in registration or geolocation data are not compliance evidence on their own.
Reverse IP and bulk access
Reverse IP is not part of an RIR registration record. A reverse IP dataset tries to associate hostnames with an address using prior DNS observations, certificates, crawling, or other sources. DomScan's /v1/reverse/ip endpoint is deprecated and searches only passive cache entries created by prior DomScan lookups. It is not internet-wide, does not enumerate every hosted domain, and cannot reveal a CDN customer's origin server.
Do not build bulk collection around guessed anonymous rate limits. RIRs publish their own terms and access policies, and those policies can change. ARIN offers Bulk Whois data through an application and agreement for approved uses. RDAP also supports HTTP status codes, authentication, and service-specific rate controls. Respect notices in the response and use registry-provided bulk access when your volume requires it.
Where DomScan fits
Use GET /v1/rdap with type=ip when you need the authoritative registration object discovered through RDAP. Use IP Lookup when you need a separate enrichment view with geolocation, ASN, security flags, datacenter classification, and FCrDNS. The Reverse DNS reference explains PTR context. Each result answers a different question, and none identifies an individual user by itself.
Independent references: IANA Number Resources describes the five-RIR allocation system. IANA's abuse guidance explains how to find the responsible registry. ARIN's public registry FAQ lists both available fields and important omissions. RFC 3912, RFC 7480, RFC 7482, and RFC 7483 define the access protocols.