How to Read an IP Address RDAP Response

An IP address RDAP response describes the most-specific registered network containing the address you queried. It can identify the returned range, the Regional Internet Registry that supplied the record, organizations and contacts associated with the registration, and the record’s place in a larger allocation hierarchy.

It does not describe the device currently using the address. It is also not, by itself, a geolocation, routing or attribution result.

This guide focuses only on the RDAP ip network object. For domain fields such as nameservers, registrar statuses and DNSSEC, use the separate guide to reading a domain RDAP response. To retrieve the JSON from a terminal first, see how to query an RDAP server with cURL.

Quick answer: Confirm that objectClassName is ip network, then check whether the queried address falls between startAddress and endAddress. Use cidr0_cidrs when present for CIDR notation, parentHandle and links for allocation context, and entities with their roles to identify registrants and abuse contacts. Treat country, status and organization names as registration metadata, not proof of physical location, active routing or responsibility for traffic.

The fields to check first

Question	Field or section
What kind of object was returned?	objectClassName
Which registered range contains the address?	startAddress and endAddress
Is it IPv4 or IPv6?	ipVersion
How is the range expressed as prefixes?	cidr0_cidrs, when the cidr0 extension is used
What identifies the registration?	handle and name
What kind of registration is it?	type
Is there a larger enclosing registration?	parentHandle and links
Which organizations and contacts are associated?	entities and roles
When did the registry record change?	events
What qualifications apply?	notices, remarks and rdapConformance

RFC 9083 allows many registration-data members to be omitted under server policy. The NRO RDAP profile used by RIR services applies stronger requirements to core network fields and cidr0 support, but clients should still tolerate policy-based omissions, older responses and non-RIR implementations. Registration structure, authorization and supported extensions all affect the final shape.

A simplified IP-network response

The following example is illustrative and intentionally shortened. It uses the documentation-only 192.0.2.0/24 range and fictional identifiers and contact details.

{
  "rdapConformance": [
    "rdap_level_0",
    "cidr0"
  ],
  "objectClassName": "ip network",
  "handle": "NET-192-0-2-0-1",
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.255",
  "ipVersion": "v4",
  "name": "EXAMPLE-NET",
  "type": "DIRECT ALLOCATION",
  "country": "US",
  "parentHandle": "NET-192-0-0-0-0",
  "cidr0_cidrs": [
    {
      "v4prefix": "192.0.2.0",
      "length": 24
    }
  ],
  "status": [
    "active"
  ],
  "entities": [
    {
      "objectClassName": "entity",
      "handle": "ORG-EXAMPLE",
      "roles": ["registrant"],
      "vcardArray": [
        "vcard",
        [
          ["version", {}, "text", "4.0"],
          ["fn", {}, "text", "Example Network Operator"]
        ]
      ],
      "entities": [
        {
          "objectClassName": "entity",
          "handle": "ABUSE-EXAMPLE",
          "roles": ["abuse"],
          "vcardArray": [
            "vcard",
            [
              ["version", {}, "text", "4.0"],
              ["fn", {}, "text", "Abuse Desk"],
              ["email", {}, "text", "abuse@example.test"]
            ]
          ]
        }
      ]
    }
  ],
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2020-01-15T00:00:00Z"
    },
    {
      "eventAction": "last changed",
      "eventDate": "2026-06-10T12:30:00Z"
    }
  ],
  "links": [
    {
      "value": "https://rdap.example.test/ip/192.0.2.42",
      "rel": "self",
      "href": "https://rdap.example.test/ip/192.0.2.0",
      "type": "application/rdap+json"
    }
  ]
}

If the request was for 192.0.2.42, this response says that the registration system matched it to the range from 192.0.2.0 through 192.0.2.255. The response is about that network registration as a whole.

Why one address returns a network

The standardized IP lookup path accepts either an individual address or a CIDR prefix:

ip/{IP address}
ip/{CIDR prefix}/{prefix length}

An address can sit inside several levels of registration. A large block may be allocated to an RIR member, with a smaller block assigned or reallocated to a customer beneath it. RFC 9082 defines the lookup target as the most-specific, or smallest, registered network that completely contains the query.

That is why querying one address commonly returns hundreds or thousands of addresses. The response is not claiming that every address in the range belongs to one device or performs the same function. It identifies the closest matching registration object known to that service.

For a CIDR query, the result must completely encompass the submitted prefix. A more-specific registration that covers only part of the requested prefix is not a complete match for that query.

Confirm the object type and source

Start with objectClassName. For a successful IP-network lookup, the top-level value should be:

"objectClassName": "ip network"

This distinguishes the result from a domain, entity or Autonomous System Number object. It also tells a parser which object-specific members to expect.

Next, record the service that returned the response. RDAP clients discover authoritative services through IANA’s separate IPv4 and IPv6 bootstrap registries. Those registries route broad address allocations to the appropriate RIR service.

Do not infer the authoritative RIR from the response’s country field. Use the bootstrap result, redirect chain and final response URL as retrieval provenance. Retain a self link when present, but verify that its authority is consistent with the responding service instead of assuming the link is authoritative. Keep the retrieval time when preserving evidence.

Read startAddress and endAddress as a range

The two most important network-specific members are:

• startAddress: the first address in the registered range
• endAddress: the last address in the registered range

Verify that the address you queried falls inclusively between them. This catches wrong endpoints, stale client state and responses accidentally associated with another request.

For IPv4, the values use dotted-decimal notation. IPv6 responses use textual IPv6 addresses and generally follow the compressed representation recommended by RFC 5952. Compare addresses numerically after parsing them; do not compare IPv6 strings lexicographically because equivalent addresses can have different textual forms.

The returned range may not align with one CIDR prefix. RDAP models a network with explicit start and end addresses because some registrations are “off-bit” ranges that require more than one CIDR block to represent exactly.

Use cidr0_cidrs when it is present

The registered cidr0 extension adds cidr0_cidrs, an array that expresses the returned range as one or more CIDR prefixes. Its use is announced in rdapConformance:

{
  "rdapConformance": ["rdap_level_0", "cidr0"],
  "cidr0_cidrs": [
    {
      "v4prefix": "192.0.2.0",
      "length": 24
    }
  ]
}

IPv4 entries use v4prefix; IPv6 entries use v6prefix. In both cases, length is the prefix length.

Treat the array as a complete set, not as a list from which to select the first item. An off-bit registration can need several entries. Outside profiles that require cidr0, a base RDAP response can expose its network boundaries without cidr0_cidrs. A client that needs CIDR notation can calculate an exact minimal decomposition from startAddress and endAddress, but it must not assume the range is one prefix.

The extension identifier and structure are registered in the IANA RDAP Extensions registry and defined in the NRO’s CIDR Expressions in RDAP specification.

Interpret handle, name, type and ipVersion

These fields identify and classify the registration:

• handle is a registry-unique identifier for the network object. It is useful when correlating records from the same service, but it is not a universal Internet-wide ID.
• name is the registry’s label for the network. It may resemble an organization or service name, but clients should not use it as the sole organization identifier.
• type describes the kind of network registration. Its vocabulary can reflect RIR policy and data models, so values should be displayed as supplied rather than forced into one universal enum.
• ipVersion is normally v4 or v6 and should agree with both address boundaries.

Examples of type values encountered in live services include labels for allocations, assignments and provider-aggregatable space. Their exact wording is not consistent enough to infer the same contractual relationship from every RIR response.

Treat country as registration metadata

When supplied, country is a two-letter country code associated with the network record. It is not a precise IP geolocation result.

An address can be announced globally, used through anycast, assigned to infrastructure in another jurisdiction, carried through a VPN or used by a customer somewhere else. Registry policy and the history of the allocation can also affect which country code appears.

Use a dedicated, appropriately licensed geolocation source when physical or commercial geolocation is required, and state the uncertainty of that source. Do not silently convert RDAP’s country value into a city, user location or legal jurisdiction.

Some responses announce the geofeed1 extension and provide a link with the geofeed relationship defined by RFC 9877. That link points to a separate operator-published geolocation feed. It still requires independent retrieval and validation, and it does not establish the location of an individual device.

Follow the allocation hierarchy

parentHandle identifies a larger registration that encloses the current network. It provides context for delegated address space:

parent allocation
  -> member or provider allocation
    -> customer assignment

The most-specific result is normally the best starting point for operational investigation, but the parent can explain which upstream organization or RIR member received the larger block.

Look for a link whose relationship indicates an enclosing resource. A service may use the generic up relation or the RIR-specific rdap-up relation standardized by RFC 9910. That specification also defines rdap-down, rdap-top and rdap-bottom for other directions through an RIR hierarchy. These links are optional, so their absence does not prove that no parent or child registration exists.

Do not construct a parent URL by guessing from the handle: entity and network handles are registry-specific, and not every service exposes hierarchy through identical links.

A parent record is not automatically the correct abuse destination. Use the entities and roles on the most-specific record first, then follow authoritative links or parent context when the response lacks a usable contact.

Identify organizations by entity role

The entities array contains organizations, groups or individuals associated with the network. Select them by their roles, never by array position.

Roles commonly useful in an IP-network response include:

• registrant: the entity associated with the registration
• administrative: an administrative contact
• technical: a technical or operational contact
• abuse: the contact designated for abuse reports

An entity can contain more entities. For example, a registrant organization may contain separate technical and abuse contacts. Other services return an abuse entity directly in the network’s top-level entities array. A robust client therefore needs to traverse nested entities instead of examining only one level.

Contact information is often represented in vcardArray, the jCard form of vCard. Read properties by name, such as fn, org, email and tel; do not depend on a fixed order. The domain-response guide has a detailed explanation of how to read vcardArray.

Find and use the abuse contact carefully

To locate an abuse contact:

1. Walk the network’s entities recursively.
2. Find entities whose roles array contains abuse.
3. Read their jCard email, telephone and organization properties.
4. Check the entity’s remarks and links for the operator’s preferred reporting method.
5. Preserve the network handle, queried address, timestamps and relevant logs in the report.

An abuse contact is a reporting destination. Its presence does not prove that the entity sent, authorized or knew about the traffic under investigation. Addresses can be reassigned, shared through carrier-grade NAT, used by cloud customers, relayed by proxies or spoofed in protocols that permit source-address spoofing.

Follow the operator’s stated reporting process and disclose only the evidence needed to investigate the incident. Registration data can include personal or operational contact information and should not be republished without a legitimate reason.

Read events as registry events

Each item in events combines an eventAction with an eventDate. Common actions include:

• registration: when the object was registered in that registration system
• last changed: when the registration data was last changed
• last update of RDAP database: when the service’s RDAP data was refreshed

These timestamps describe the registry record. They do not show when an address first carried traffic, when a route was announced, when a server was deployed or when an incident occurred.

Select events by eventAction, not by their position. Dates use an Internet date-and-time format and can include a UTC Z suffix or an explicit offset.

Do not equate active with routed or reachable

The status array describes the state of the registered object. An active network record does not prove that:

• the prefix is currently visible in BGP;
• the queried address responds to traffic;
• reverse DNS exists;
• a particular organization is currently using every address; or
• the prefix has a valid Route Origin Validation state under RPKI.

Those questions require separate sources: BGP route collectors, Route Origin Authorizations and validation state, DNS queries, network measurements or the operator’s own telemetry.

Interpret every returned status and preserve unknown values. Registered status meanings are maintained in the IANA RDAP JSON Values registry, but their operational significance still depends on the object and registry policy.

Read notices, remarks, links and extensions

These sections qualify the rest of the result:

• notices apply to the service or complete response. They can contain terms of use, filtering statements, inaccuracy-reporting instructions and rate-limit information.
• remarks apply to the object containing them. They can explain the purpose of the range, contact policy, missing data or truncation.
• links connect the object to canonical, parent, related or alternate resources. Interpret links by rel and type, not by array position.
• rdapConformance identifies the base specification and extensions used to build the response.

Clients should ignore extension members they do not understand rather than reject the complete response. At the same time, do not assign meaning to an extension field until its identifier and specification are known.

A self link is useful for identifying the object’s RDAP representation, but it remains an assertion in the response. Verify its authority against the responding service before using it as a cache key; RFC 9083 warns against caching an object when the self link’s authority differs from the server that returned it. An alternate link may point to another representation, including a registry’s older WHOIS-oriented API. It should not be assumed to contain the same fields or access policy as the RDAP response.

Expect differences among RIR services

ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC all serve Internet number registration data, but compliant responses do not have to be visually identical.

Differences can include:

• entity nesting and which roles are exposed;
• the wording used in type;
• whether country, parentHandle or optional events appear;
• which links describe hierarchy or related records;
• contact publication and redaction policy;
• registered extensions announced in rdapConformance; and
• service-specific notices and remarks.

Build parsers around the object model, not one RIR’s sample. Tolerate missing optional members, process arrays without assuming order, recurse through entities and preserve unknown extensions for later inspection.

What an IP RDAP response cannot tell you

An IP-network response is registration evidence. On its own, it cannot establish:

• A device’s physical location. The country code is not precise geolocation.
• The current route origin. Registration and BGP routing are separate systems.
• Whether the prefix is routed. An active registration can exist without a visible route.
• The current end user. Providers can dynamically assign, share or reallocate addresses.
• The hostname. Reverse DNS requires a separate PTR query and may still be absent or misleading.
• Who generated specific traffic. Registration identifies associated parties and contacts, not the actor behind an event.
• Legal ownership. RIR records describe registration and allocation relationships; legal rights can require additional evidence and jurisdiction-specific analysis.

For an investigation, correlate RDAP with timestamped network logs, BGP data, RPKI validation, DNS, application records and information supplied by the relevant operator. Keep the retrieval time because registrations and contacts can change.

A practical reading order

Use this sequence when reviewing an IP response:

1. Record the queried address, final RDAP URL and retrieval time.
2. Confirm objectClassName is ip network.
3. Verify the address falls between startAddress and endAddress.
4. Read every entry in cidr0_cidrs when the extension is present.
5. Record the network handle, name, type and ipVersion.
6. Use parentHandle and authoritative links to understand allocation context.
7. Traverse entities recursively and select them by role.
8. Read events by action and statuses as registration state.
9. Review notices, remarks and rdapConformance for qualifications.
10. Correlate routing, geolocation, DNS and traffic claims with separate sources.

This reduces a large response to four operational questions: Which registered range matched? Where does it sit in the allocation hierarchy? Which contacts are associated with it? What does the record not prove?

Frequently asked questions

Does RDAP show who owns an IP address?

RDAP shows the organizations and contacts associated with a network registration. “Owner” can imply legal title or current operational control, neither of which should be inferred from one field. Describe the returned entity by its role and preserve the registry source.

Why did one IP address return an entire network?

IP addresses are registered in ranges. The RDAP lookup returns the most-specific registered network that completely contains the queried address, so startAddress and endAddress usually cover more than one address.

Is the country field an IP geolocation result?

No. It is registration metadata supplied under the registry’s data model and policy. It does not reliably identify the physical location of a device, user or packet source.

Can RDAP tell me which ASN is currently announcing the address?

Not portably from the base IP-network object. Some services publish extensions or related data, but current route origin is a routing question. Check live BGP data and validate relevant RPKI information separately, then use the guide to reading an ASN RDAP response to interpret the registration for the resulting AS number.

What if cidr0_cidrs is missing?

Use startAddress and endAddress, which express the network boundaries in the base object. If another system requires prefixes, calculate an exact CIDR decomposition rather than assuming the range is one block.

Why is the abuse contact nested inside another entity?

RDAP permits entities to contain entities. An organization associated as the registrant can contain contacts with administrative, technical or abuse roles. Traverse the entity tree and identify each object by roles.

Are IPv4 and IPv6 responses interpreted differently?

The reading process is the same. The address syntax, ipVersion value and v4prefix or v6prefix member differ, but both object types describe explicit start and end boundaries, entities, events, links and other shared RDAP structures.

Read a live IP response

Run an IP address lookup and compare the compact result with the raw RDAP JSON. Start with the returned range, then inspect the entity hierarchy, events, notices and extensions.

The formal IP-network object is defined in RFC 9083, and IP query behavior is defined in RFC 9082. IANA publishes the authoritative IPv4 and IPv6 RDAP bootstrap registries.