What Is an RDAP Record?

An RDAP record is a structured set of registration data about an Internet resource such as an IPv4 address range, IPv6 prefix or Autonomous System Number (ASN).

For an IP address, an RDAP response can contain information such as:

• the registered address range;
• IP version;
• registry-specific resource identifier;
• network name;
• registration type or status;
• related organizations and contacts;
• registration and update events;
• parent resource information; and
• links to related registry data.

RDAP stands for Registration Data Access Protocol. It provides a standardized, web-based method for accessing Internet registration data and returns information in structured JSON format.

The IETF defines RDAP query formats in RFC 9082 and the corresponding JSON response structures in RFC 9083.

For network operators, however, the important skill is not simply knowing what RDAP stands for.

It is knowing how to interpret the record correctly—and what conclusions should not be drawn from it.

What Can an RDAP Record Tell You?

An RDAP lookup can help answer questions such as:

• Which IP range contains this address?
• Which Regional Internet Registry is providing the registration information?
• What identifier is associated with the network record?
• Which organization-related entities appear in the data?
• What technical, administrative or abuse contacts are available?
• When was the resource record registered or last changed?
• Does the registry provide a parent resource?
• Are there important notices or remarks attached to the response?

This makes RDAP useful for:

• Internet number resource audits;
• network troubleshooting;
• IPv4 transfer due diligence;
• corporate mergers and acquisitions;
• security investigations;
• resource inventory management; and
• checking whether internal records agree with external registry data.

NRS recommends including registry records such as WHOIS and RDAP as one layer of a wider Internet number resource audit.

The important word is one layer.

An RDAP record is not a complete description of everything happening with an IP prefix.

RDAP vs. WHOIS: What Is the Difference?

RDAP and WHOIS both provide access to Internet registration information, but RDAP was designed to provide a more standardized and machine-readable model.

RIPE NCC describes RDAP as an alternative to WHOIS that uses HTTPS and a RESTful web-services model, while APNIC highlights standardized queries, responses and inter-registry redirection as major advantages.

For automated network-resource management, these characteristics can make RDAP particularly useful.

But a structured format does not mean every field has the same operational meaning in every situation.

You still need to interpret the data in context.

How to Look Up an IP Address with RDAP

An RDAP IP query normally follows a structure similar to:

/ip/{IP-address}

or:

/ip/{CIDR-prefix}

For example, a registry RDAP service might accept:

/ip/192.0.2.1

or:

/ip/192.0.2.0/24

The response is typically JSON.

You do not necessarily need to know in advance which RIR administers an address.

IANA maintains RDAP bootstrap registries that map IP address ranges to the appropriate RDAP service. This helps RDAP clients locate authoritative registration-data services.

You can also use the lookup interfaces provided by Regional Internet Registries.

For example, RIPE NCC documents queries using:

https://rdap.db.ripe.net/ip/{address}

while APNIC provides an RDAP service for IPv4, IPv6 and ASN queries.

Example of an RDAP IP Record

A simplified RDAP response might look like this:

{
  "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": "ZZ",
  "status": [
    "active"
  ],
  "entities": [
    {
      "handle": "EXAMPLE-ORG",
      "roles": [
        "registrant"
      ]
    },
    {
      "handle": "EXAMPLE-ABUSE",
      "roles": [
        "abuse"
      ]
    }
  ],
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2020-01-01T00:00:00Z"
    },
    {
      "eventAction": "last changed",
      "eventDate": "2026-01-15T00:00:00Z"
    }
  ]
}

This is an illustrative example, not a live registry record.

Let’s break down the important fields.

1. objectClassName

Example:

"objectClassName": "ip network"

This tells you what type of RDAP object you are looking at.

For an IP-address query, RFC 9083 defines the relevant object class as:

ip network

Other RDAP object classes can include:

• autnum for Autonomous System Numbers;
• entity for organizations, contacts or related entities;
• domain for domain-related data; and
• nameserver for nameserver information.

If your goal is to investigate an IP prefix, confirming that the response is an ip network object is a useful first check.

2. startAddress and endAddress

Example:

"startAddress": "192.0.2.0",
"endAddress": "192.0.2.255"

These fields define the IP address range covered by the network registration.

This is one of the most important parts of the response.

If you searched for a single IP address, RDAP may return the network range containing that address rather than treating the individual address as a separate registry object.

For example:

Queried IP: 192.0.2.45

Returned range: 192.0.2.0 – 192.0.2.255

That tells you the registration data applies to the wider network block containing the queried address.

For audits, always record the range, not only the single address that triggered the search.

3. ipVersion

Example:

"ipVersion": "v4"

This identifies whether the network is IPv4 or IPv6.

Typical values are:

• v4 — IPv4
• v6 — IPv6

This field is straightforward but useful when processing many records automatically.

4. handle

Example:

"handle": "NET-192-0-2-0-1"

The handle is a registry-specific identifier for the network registration.

Think of it as a record identifier rather than the IP address itself.

It can be useful when:

• cross-referencing related records;
• tracking registry objects;
• documenting an audit;
• following links returned in the RDAP response; or
• comparing historical data.

A handle should not automatically be interpreted as an ownership certificate.

Its main purpose is to uniquely identify the relevant registry object within the registration system.

5. name

Example:

"name": "EXAMPLE-NET"

The name field is an identifier associated with the network registration.

It may help humans recognize the resource more easily.

However, do not assume the network name is the same thing as the current legal company name.

Organizations change names.

Networks are acquired.

Historical labels may remain in technical systems.

When performing serious due diligence, compare the network name with:

• entity records;
• organization information;
• corporate documentation; and
• other available registry data.

6. type

Example:

"type": "DIRECT ALLOCATION"

RFC 9083 describes type as an RIR-specific classification of the network under that registry’s registration model.

That phrase is important.

Values may vary between registries and should be interpreted according to the relevant RIR’s terminology and policies.

A type field might provide information relating to how a network resource is classified, but you should not assume every RIR uses identical values or definitions.

For an audit, record the value first.

Interpret its policy meaning separately.

7. country

Example:

"country": "ZZ"

This field deserves special caution.

A country value appearing in registration data should not automatically be treated as authoritative evidence of where every server or user of the IP range is physically located.

Registry information and IP geolocation solve different problems.

An address registered with an organization associated with one country may be:

• routed in another country;
• used by customers internationally;
• announced from multiple locations;
• used in a cloud environment; or
• classified differently by commercial GeoIP databases.

Therefore:

RDAP country data is registry information, not a substitute for real-time network location or commercial GeoIP analysis.

This distinction is important for security, compliance and due-diligence teams.

8. status

Example:

"status": [
  "active"
]

The status field describes the state of the RDAP registration object according to the applicable RDAP definitions and registry implementation.

This is another field that is easy to overinterpret.

An active registration status does not automatically mean:

• the prefix is currently announced in BGP;
• the route is reachable;
• a particular ASN is authorized to originate it;
• a valid ROA exists;
• reverse DNS is configured; or
• the addresses are actively serving production traffic.

This is one of the most important concepts when reading RDAP.

Registry state and routing state are different layers.

NRS’s Internet number resource guidance specifically recommends verifying registration, routing, RPKI, IRR and DNS separately rather than treating one database as a complete network source of truth.

9. parentHandle

You may also see:

"parentHandle": "PARENT-NET"

This identifies the parent network registration.

Internet number resources are hierarchical.

A smaller resource may exist within a larger allocation or registration.

Understanding the parent relationship can help when investigating:

• downstream assignments;
• customer networks;
• resource history;
• organizational relationships; and
• which registry object sits above the current record.

If you are conducting due diligence, following the parent relationship can sometimes reveal useful context that is not obvious from the first lookup.

10. entities

The entities array is one of the most important—and sometimes most confusing—parts of an RDAP response.

Example:

"entities": [
  {
    "handle": "EXAMPLE-ORG",
    "roles": [
      "registrant"
    ]
  }
]

An entity can represent an organization, person, role or other registry-related contact object.

RFC 9083 allows an entity to contain information such as:

• a unique handle;
• contact information;
• roles;
• related entities;
• events;
• remarks; and
• links.

The important field inside an entity is often roles.

11. roles

Possible roles can include values such as:

• registrant;
• administrative;
• technical;
• abuse;
• noc;
• billing; and
• other standardized or registry-supported roles.

For example:

"roles": [
  "abuse"
]

suggests that the entity is associated with an abuse-contact role.

A technical contact may instead appear as:

"roles": [
  "technical"
]

When reviewing a resource, ask:

Is the organization-related entity recognizable?

Are administrative contacts current?

Is there an appropriate technical contact?

Is the abuse-contact path usable?

For business-critical resources, outdated entities can create practical problems during troubleshooting, transfers, security incidents and account recovery.

12. vcardArray

Entity objects may include a vcardArray.

This can contain structured contact information, including fields such as:

• organization name;
• individual or role name;
• address;
• email;
• telephone number; and
• related contact details.

Do not assume every RDAP response will expose every possible contact field.

Data availability can depend on:

• registry implementation;
• privacy policies;
• access rights;
• redaction;
• resource type; and
• applicable rules.

If important information appears absent, check the remarks and notices sections before assuming the registry has no additional data.

13. events

Example:

"events": [
  {
    "eventAction": "registration",
    "eventDate": "2020-01-01T00:00:00Z"
  },
  {
    "eventAction": "last changed",
    "eventDate": "2026-01-15T00:00:00Z"
  }
]

Events provide timestamps associated with the RDAP object.

Common events can include:

• registration;
• last changed;
• expiration;
• deletion; or
• other supported event actions.

For IP-resource audits, the most useful values are often:

Registration date

and

Last changed date

A recent last changed event is not automatically suspicious.

It may reflect:

• a contact update;
• organizational changes;
• registry maintenance;
• a transfer;
• record correction; or
• another administrative event.

Likewise, an old date does not automatically mean the resource has been abandoned.

Dates are clues.

They need context.

14. remarks

remarks provide additional information associated with the object.

For example:

"remarks": [
  {
    "description": [
      "Additional registration information."
    ]
  }
]

Remarks may explain:

• special characteristics of the record;
• restrictions;
• redactions;
• historical context;
• registry-specific information; or
• other details that do not fit into standard fields.

During due diligence, do not skip the remarks simply because they appear near the bottom of the JSON.

They may contain information important to interpreting the rest of the record.

15. notices

notices are similar to remarks but generally apply to the overall RDAP response.

They may contain information concerning:

• terms of use;
• privacy;
• copyright;
• data redaction;
• query limits; or
• interpretation of the response.

RFC 9083 distinguishes notices from remarks by placing notices at the top level of an RDAP response.

For automated systems, notices should not simply be discarded.

They may explain why information is missing or how the returned data should be interpreted.

16. links

An RDAP record can contain links to related resources.

Example:

"links": [
  {
    "rel": "self",
    "href": "https://example.net/rdap/ip/192.0.2.0/24"
  }
]

Links can point to:

• the current object;
• parent objects;
• related entities;
• alternate representations; or
• other relevant registry resources.

The relationship type—such as self or up—helps explain what the link represents.

These links are particularly useful when building tools that automatically follow relationships between registry objects.

A Quick RDAP Reading Checklist

When reviewing an IP-address RDAP record manually, use this order:

This provides a good first-pass analysis.

But it should not be the end of the investigation.

What an RDAP Record Cannot Tell You by Itself

This is the most important part of reading RDAP correctly.

A registration record provides registry information.

It should not automatically be treated as a complete representation of operational, commercial or legal reality.

RDAP Does Not Prove That a Prefix Is Currently Routed

An IP range can appear in RDAP even if it is not currently visible in the global BGP routing table.

To verify routing, check routing data separately.

Questions include:

• Is the prefix currently announced?
• Which ASN originates it?
• Is the announcement stable?
• Is the expected prefix length being announced?

RDAP Does Not Prove Routing Authorization

An organization appearing in a registry record does not automatically tell you whether a particular ASN is authorized to announce that prefix.

For routing authorization, examine additional layers such as:

• RPKI;
• Route Origin Authorizations;
• IRR route objects;
• applicable LOAs; and
• actual BGP announcements.

Registry registration and routing authorization are related, but they are not interchangeable.

RDAP Does Not Prove Legal Ownership

An RDAP entry can be important evidence regarding registration and resource administration.

But it should not automatically be interpreted as a universal legal title record.

Questions involving legal or contractual rights may require examination of:

• agreements;
• transfer documentation;
• corporate records;
• registry policies;
• resource history;
• applicable law; and
• competent legal decisions where relevant.

The safest approach is to describe RDAP as registration information, not as a complete legal determination.

RDAP Does Not Prove Physical Location

As discussed earlier, the country field should not automatically be treated as GeoIP.

To investigate physical or operational location, additional evidence may be needed.

RDAP Does Not Tell You IP Reputation

An RDAP record does not tell you whether an address has:

• spam history;
• blacklist listings;
• malware history;
• poor email reputation;
• historical abuse; or
• commercial reputation problems.

Those require separate reputation checks.

RDAP Does Not Tell You Whether Reverse DNS Is Correct

Reverse DNS should also be verified independently.

This can be especially important for:

• email infrastructure;
• hosting providers;
• enterprise services; and
• security operations.

Think in Layers, Not One Database

A useful way to evaluate an Internet number resource is to separate its different operational layers:

Registry
Is the registration information accurate?

Routing
Is the prefix actually being announced as expected?

Authorization
Does RPKI, IRR or other documentation support the intended origin ASN?

DNS
Is reverse DNS configured appropriately?

Security
Are relevant RPKI objects and access controls current?

Reputation
Does the address range carry operational reputation issues?

Documentation
Can the organization explain how it obtained and administers the resource?

Continuity
Would the network remain manageable if staff, providers, infrastructure or organizational circumstances changed?

This layered approach reflects a core principle of good Internet number resource management:

No single database field should be expected to describe the entire operational state of an IP resource.

For organizations building an internal inventory, NRS’s guide to maintaining a network source of truth provides a broader framework for keeping technical and administrative data aligned.

How to Use RDAP During an IP Resource Audit

For an audit, RDAP works best as part of a repeatable process.

Step 1: Build an Inventory

Start with every important:

• IPv4 prefix;
• IPv6 prefix; and
• ASN.

Avoid relying only on IP addresses currently visible in firewall or router configurations.

Include resources that may be:

• reserved;
• temporarily unused;
• delegated;
• associated with legacy infrastructure; or
• held for continuity purposes.

Step 2: Run RDAP Queries

Retrieve the registration record for each resource.

Record at minimum:

• address range;
• registry;
• handle;
• network name;
• type;
• status;
• organization-related entities;
• administrative contacts;
• technical contacts;
• abuse contacts;
• registration date; and
• last-change date.

Step 3: Compare RDAP with Internal Records

Ask:

• Does the organization name make sense?
• Are the contacts still employed or authorized?
• Does the range match the company’s inventory?
• Do internal records explain the resource’s history?
• Is the relevant registry account still accessible?

A discrepancy does not automatically mean something is wrong.

It means the discrepancy should be understood.

Step 4: Verify Routing Separately

Check:

• BGP origin ASN;
• announced prefix;
• route visibility;
• expected upstream relationships; and
• unexpected announcements.

Do not mark a resource as operationally healthy based only on a successful RDAP lookup.

Step 5: Verify RPKI and Routing Authorization

Review:

• ROA existence;
• origin ASN;
• prefix;
• maximum length;
• RPKI validation status; and
• relevant IRR information.

This is particularly important after routing migrations or ASN changes.

Step 6: Review DNS and Operational Dependencies

Check whether the resource is tied to:

• reverse DNS;
• APIs;
• customer allowlists;
• VPN systems;
• firewall rules;
• SaaS integrations;
• payment platforms;
• email infrastructure; or
• compliance documentation.

The more dependencies exist, the more important accurate resource administration becomes.

Step 7: Document Exceptions

If RDAP and operational reality do not appear to align, document:

• what differs;
• why it differs;
• who is responsible;
• whether corrective action is needed; and
• what continuity risk exists.

This is more useful than assuming either the internal system or registry database must automatically be correct.

RDAP and IPv4 Transfer Due Diligence

RDAP becomes particularly useful when an IPv4 block is being considered for transfer or another significant transaction.

Before relying on a resource, a prospective participant may want to understand:

• which RIR administers the block;
• what range is actually registered;
• which entities appear in registration data;
• whether the network has parent relationships;
• when the record was last changed;
• whether remarks or notices contain important context; and
• whether the information aligns with transaction documentation.

But RDAP should be only one part of transfer due diligence.

The wider review may also include:

• applicable RIR procedures;
• transfer documentation;
• routing history;
• RPKI;
• IRR;
• reverse DNS;
• IP reputation;
• corporate information; and
• operational deployment planning.

LARUS discusses the operational consequences of stale registration information in its guide to outdated WHOIS and RDAP records during IPv4 transfers.

Why Accurate RDAP Records Matter for Network Continuity

Registration data may appear administrative until something changes.

Consider a network where:

• the only technical contact left the company three years ago;
• the organization changed its legal name;
• no one knows who controls the registry account;
• the IP block is embedded in hundreds of customer allowlists; and
• a major infrastructure migration is about to begin.

Suddenly, registry accuracy is not just a documentation issue.

It is a continuity issue.

Important Internet number resources should therefore have:

• current registry records;
• controlled account access;
• internal ownership of administrative responsibilities;
• documented resource history;
• routing and RPKI visibility; and
• recovery procedures.

NRS examines these dependencies more broadly in Understanding Registry-Layer Risk for Enterprise Networks.

The goal is not to treat the registry as the whole network.

It is to ensure the registry layer remains an accurate, dependable part of the network’s wider operational picture.

The Bigger Principle: Registry Data Should Be Read in Context

RDAP is valuable precisely because it provides structured, standardized access to registry data.

But good network governance requires resisting the temptation to turn one source of information into the entire truth.

An RDAP record can tell you:

what the registry currently records.

BGP can tell you:

what is being routed.

RPKI can help tell you:

whether a route origin matches a published authorization.

DNS can tell you:

how naming and reverse delegation are configured.

Corporate and transaction records may help explain:

the organizational history surrounding the resource.

Together, these layers provide a much more reliable picture.

This distinction is particularly important as IPv4 resources become deeply embedded in production networks.

Accurate registry records matter.

So does accurate routing information.

So does security data.

So does operational continuity.

The best Internet number resource management connects these layers rather than confusing one for another.

Final Thoughts

RDAP makes Internet registration data easier to access and process.

For an IP address, the most useful fields commonly include:

• startAddress;
• endAddress;
• ipVersion;
• handle;
• name;
• type;
• status;
• entities;
• roles;
• events;
• remarks;
• notices; and
• links.

Learning to read those fields helps network operators understand how an Internet number resource appears in the registry system.

But the most important lesson is what comes next.

Do not confuse registration with routing.

Do not confuse a country field with GeoIP.

Do not confuse an entity record with a complete legal determination.

Do not assume an active record proves operational use.

Instead, use RDAP as one part of a broader resource-management process that includes registry accuracy, routing, authorization, security, documentation and continuity.

For organizations that depend on IPv4, IPv6 or ASNs, NRS recommends periodically reviewing the complete resource picture—not only whether an address exists in a database, but whether the records surrounding that resource remain accurate, understandable and aligned with the network that actually depends on it.

Frequently Asked Questions

What is an RDAP record?

An RDAP record is structured registration data returned using the Registration Data Access Protocol. For an IP network, it can include the registered address range, resource identifier, status, related entities, contacts, events and other registry information.

What does RDAP stand for?

RDAP stands for Registration Data Access Protocol.

Can RDAP look up an IPv4 address?

Yes. RDAP supports queries for individual IPv4 addresses, IPv6 addresses and CIDR network ranges. It can also be used for Autonomous System Number queries.

Is RDAP better than WHOIS?

RDAP provides several technical advantages, including standardized queries, structured JSON responses, HTTPS-based access and redirection between authoritative services. WHOIS remains familiar to many operators, but RDAP is generally easier for structured and automated processing.

What does handle mean in an RDAP record?

The handle is a registry-specific unique identifier for the RDAP object. It identifies the registration record and can be useful for cross-referencing related data.

What does status: active mean in RDAP?

It describes the status of the registration object. It should not automatically be interpreted as proof that the prefix is currently routed, reachable or authorized through RPKI.