RFC 9910
Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search
RFC 9910: Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search 🎀
okay so bestie, this RFC is written by T. Harrison (APNIC) and J. Singh (ARIN) 🫶. It's a Standards Track document ✨, published January 2026, and it's giving "we noticed a gap and we fixed it" 💅. It doesn't obsolete or update any other documents, so it's a clean new addition to the RDAP family 🌸.
Also, the ISSN is 2070-1721 and the RFC number is 9910, so save those for your bibliography 🍓.
Abstract ✨
okay so RDAP is what Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) use to let you look up their registration info 🦋. The core RDAP specs have basic search, BUT it's only for domains, nameservers, and entities. Meanwhile the RIRs' old WHOIS services could search by IP addresses, IP prefixes, and Autonomous System Numbers (ASNs), and RDAP just... couldn't 😭. This document adds those search options so RDAP can finally keep up 👑.
Status of This Memo ✨
This is an Internet Standards Track document 💜.
It's a product of the Internet Engineering Task Force (IETF) 🧚. It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 💅. If you want more on Internet Standards, check Section 2 of RFC 7841 🌈.
Info about the current status, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9910 🔥.
Copyright Notice ✨
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved 🫶.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Please read those carefully, because they describe your rights and restrictions 💀. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License 🙈.
Table of Contents 🧚
1. Introduction
1.1. Conventions Used in This Document
2. Basic Searches
2.1. Path Segments
2.2. IP Network Search
2.3. Autonomous System Number Search
3. Relation Searches
3.1. Path Segments
3.2. Relation Search
3.2.1. Definitions
3.2.2. Relations
3.2.2.1. Single-Result Searches
3.2.2.2. Multiple-Result Searches
3.3. Status
3.4. Link Relations
4. Responding to Searches
4.1. Single-Result Searches
4.2. Multiple-Result Searches
5. Reverse Search
6. RDAP Conformance
7. Operational Considerations
8. Privacy Considerations
9. Security Considerations
10. IANA Considerations
10.1. RDAP Extensions Registry
10.1.1. rirSearch1
10.1.2. ips
10.1.3. autnums
10.1.4. ipSearchResults
10.1.5. autnumSearchResults
10.2. Link Relations Registry
10.2.1. rdap-up
10.2.2. rdap-down
10.2.3. rdap-top
10.2.4. rdap-bottom
10.2.5. rdap-active
10.3. RDAP Reverse Search Registry
10.3.1. fn
10.3.2. handle
10.3.3. email
10.3.4. role
10.4. RDAP Reverse Search Mapping Registry
10.4.1. fn
10.4.2. handle
10.4.3. email
10.4.4. role
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🦋
1.1. Conventions Used in This Document 💖
okay so this is the boring-but-important bit 🙈. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, like here 📚.
Indentation and whitespace in examples are just there to show how elements relate, and they're not required features of this spec 🌸. The ... in examples is shorthand for stuff defined outside this document, or for bits that are too long to show 🧚.
2. Basic Searches 💅
2.1. Path Segments ✨
These are the new resource type path segments for basic search, which are similar to the searches in [RFC9082] and [RFC9083] 🎀:
ips: identifies an IP network search that uses a pattern to match one of a set of IP network attributes.autnums: identifies an autonomous system number search that uses a pattern to match one of a set of autonomous system number attributes.
A search pattern matches a value if it equals the string representation of the value, OR if it matches the value under the asterisk (*, ASCII value 0x2A) partial string matching from Section 4.1 of [RFC9082] 💜. Usually * can only match trailing characters, and it can only appear once in a search. Check that previously mentioned section for the full behaviour 🔥.
Section 4.1 of [RFC9082] talks about using a trailing domain label suffix in a partial string search 🦋. Servers don't need to support that for the basic searches in this document, since those searches don't involve domain name members 🫶.
2.2. IP Network Search 🌈
Syntax:
ips?handle=<handle search pattern>
ips?name=<name search pattern>Searching IP network information (see Section 5.4 of [RFC9083]) by handle uses this form:
ips?handle=XXXXXXXX is a search pattern for an IP network identifier, and its syntax depends on the registration provider 🍓. For example, this URL finds IP networks whose handles match the NET-199* pattern:
https://example.com/rdap/ips?handle=NET-199*Searching IP network information (see Section 5.4 of [RFC9083]) by name uses this form:
ips?name=XXXXXXXX is a search pattern for an IP network identifier that the registration holder assigned to the network registration 💖. For example, this URL finds IP networks whose names match NET-EXAMPLE-*:
https://example.com/rdap/ips?name=NET-EXAMPLE-*2.3. Autonomous System Number Search 🧚
Syntax:
autnums?handle=<handle search pattern>
autnums?name=<name search pattern>Searching autonomous system number information (see Section 5.5 of [RFC9083]) by handle uses this form:
autnums?handle=XXXXXXXX is a search pattern for an autonomous system number identifier, and its syntax depends on the registration provider ✨. For example, this URL finds autonomous system numbers whose handles match the AS1* pattern:
https://example.com/rdap/autnums?handle=AS1*Searching autonomous system number information (see Section 5.5 of [RFC9083]) by name uses this form:
autnums?name=XXXXXXXX is a search pattern for an autonomous system number identifier that the registration holder assigned to the autonomous system number registration 🌸. For example, this URL finds autonomous system numbers whose names match ASN-EXAMPLE-*:
https://example.com/rdap/autnums?name=ASN-EXAMPLE-*3. Relation Searches 🦋
okay so this section is where it gets spicy 🔥. It defines searches and link relations for finding objects, and sets of objects, based on where they sit in a hierarchy 👑.
3.1. Path Segments 💜
The variables used in the path segments in this section are:
<relation>: a relation type, as defined in Section 3.2.2 of this document.<IP address>: an IP address, as defined in Section 3.1.1 of [RFC9082].<CIDR prefix>: the first address of a Classless Inter-Domain Routing (CIDR) block, as defined in Section 3.1.1 of [RFC9082].<CIDR length>: the prefix length for a CIDR block, as defined in Section 3.1.1 of [RFC9082].<domain name>: a fully qualified domain name, as defined in Section 3.1.3 of [RFC9082].<autonomous system number or range>: an autonomous system number, as defined in Section 3.1.2 of [RFC9082], or two such numbers separated by a single hyphen (-, ASCII value 0x2D), where the second number is greater than the first.<resource type search path segment>: a search path segment that corresponds to an Internet Number Resource (INR) object class (that is, an IP network address or range, an autonomous system number or number range, or a reverse domain name) 🌈.<object value>: a value used to identify an object for a relation search relative to that object. It's one of<IP address>, a<CIDR prefix>and<CIDR length>pair,<domain name>, or<autonomous system number or range>, depending on the kind of search 🎀.<status>: an object status value, as defined in Section 4.6 of [RFC9083] 🧚.
These are the new resource type path segments for relation search, which are similar to the searches in [RFC9082] and [RFC9083] ✨:
ips/rirSearch1/<relation>/<IP address>: identifies an IP network search that uses a relation and an IP address to match a set of IP networks 💖.ips/rirSearch1/<relation>/<CIDR prefix>/<CIDR length>: identifies an IP network search that uses a relation and an IP address range to match a set of IP networks 🍓.autnums/rirSearch1/<relation>/<autonomous system number or range>: identifies an autonomous system number search that uses a relation and a single ASN or an ASN range to match a set of ASN objects 🌸.domains/rirSearch1/<relation>/<domain name>: identifies a reverse domain search that uses a relation and a reverse domain name to match a set of reverse domains 🔥.
3.2. Relation Search 👑
Syntax:
<resource type search path segment>/rirSearch1/<relation>/<object value>[?status=<status>]The relation searches in this document all rely on the syntax above, and each one works the same way for each object class 🫶.
The rirSearch1 path segment goes into the relation search URLs to give those searches a single namespace, and so that other searches can be defined underneath the top-level resource type search path segments 🦋.
To be continued in Part 2 🎀 — keep an eye out, bestie! 💜
3.2.1. Definitions
okay so every INR object value can have a "parent" object and one or more "child" objects 💖 The parent is the next-least-specific object that exists in the relevant registry, and the children are the next-most-specific objects that exist in the relevant registry. Let's say there's a registry with these IP network objects:
+--------------+
| 192.0.2.0/24 |
+--------------+
/ \
+--------------+ +----------------+
| 192.0.2.0/25 | | 192.0.2.128/25 |
+--------------+ +----------------+
/ / \
+--------------+ +----------------+ +----------------+
| 192.0.2.0/28 | | 192.0.2.128/26 | | 192.0.2.192/26 |
+--------------+ +----------------+ +----------------+
/
+--------------+
| 192.0.2.0/32 |
+--------------+Figure 1: Example Registry Objects
so for this example registry, here's how the parent/child relationships shake out 💅
+==================+================+
| INR object value | Parent object |
+==================+================+
| 192.0.2.0/32 | 192.0.2.0/28 |
+------------------+----------------+
| 192.0.2.0/28 | 192.0.2.0/25 |
+------------------+----------------+
| 192.0.2.64/26 | 192.0.2.0/25 |
+------------------+----------------+
| 192.0.2.128/26 | 192.0.2.128/25 |
+------------------+----------------+
| 192.0.2.192/26 | 192.0.2.128/25 |
+------------------+----------------+
| 192.0.2.0/25 | 192.0.2.0/24 |
+------------------+----------------+
| 192.0.2.128/25 | 192.0.2.0/24 |
+------------------+----------------+
| 192.0.2.0/24 | N/A |
+------------------+----------------+Table 1: Parent Objects
+==================+================================+
| INR object value | Child objects |
+==================+================================+
| 192.0.2.0/24 | 192.0.2.0/25, 192.0.2.128/25 |
+------------------+--------------------------------+
| 192.0.2.0/25 | 192.0.2.0/28 |
+------------------+--------------------------------+
| 192.0.2.128/25 | 192.0.2.128/26, 192.0.2.192/26 |
+------------------+--------------------------------+
| 192.0.2.64/26 | N/A |
+------------------+--------------------------------+
| 192.0.2.128/26 | N/A |
+------------------+--------------------------------+
| 192.0.2.192/26 | N/A |
+------------------+--------------------------------+
| 192.0.2.0/28 | 192.0.2.0/32 |
+------------------+--------------------------------+
| 192.0.2.0/32 | N/A |
+------------------+--------------------------------+Table 2: Child Objects
(btw, INR object values don't have to match registry objects, bc users can send in whatever object values they want as input to the searches defined in this document 🫶)
Similarly to the parent/child stuff, each INR object value may have a "top" object, which is the least-specific covering object that exists in the registry 🌸 It can also have one or more "bottom" objects, which are the most-specific objects that entirely cover the INR object value when you take them together. Using the registry from above, the top and bottom object relationships are:
+==================+==============+
| INR object value | Top object |
+==================+==============+
| 192.0.2.0/32 | 192.0.2.0/24 |
+------------------+--------------+
| 192.0.2.0/28 | 192.0.2.0/24 |
+------------------+--------------+
| 192.0.2.64/26 | 192.0.2.0/24 |
+------------------+--------------+
| 192.0.2.128/26 | 192.0.2.0/24 |
+------------------+--------------+
| 192.0.2.192/26 | 192.0.2.0/24 |
+------------------+--------------+
| 192.0.2.0/25 | 192.0.2.0/24 |
+------------------+--------------+
| 192.0.2.128/25 | 192.0.2.0/24 |
+------------------+--------------+
| 192.0.2.0/24 | N/A |
+------------------+--------------+Table 3: Top Objects
+==================+===========================================+
| INR object value | Bottom objects |
+==================+===========================================+
| 192.0.2.0/24 | 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32, |
| | 192.0.2.128/26, 192.0.2.192/26 |
+------------------+-------------------------------------------+
| 192.0.2.0/25 | 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32 |
+------------------+-------------------------------------------+
| 192.0.2.128/25 | 192.0.2.128/26, 192.0.2.192/26 |
+------------------+-------------------------------------------+
| 192.0.2.64/26 | N/A |
+------------------+-------------------------------------------+
| 192.0.2.128/26 | N/A |
+------------------+-------------------------------------------+
| 192.0.2.192/26 | N/A |
+------------------+-------------------------------------------+
| 192.0.2.0/28 | 192.0.2.0/28, 192.0.2.0/32 |
+------------------+-------------------------------------------+
| 192.0.2.0/31 | 192.0.2.0/28, 192.0.2.0/32 |
+------------------+-------------------------------------------+
| 192.0.2.0/32 | N/A |
+------------------+-------------------------------------------+Table 4: Bottom Objects
if there are no more-specific objects for a given INR object value, its set of bottom objects is going to be empty 🥺 192.0.2.0/32 is an example of that situation.
the bottom objects for a given INR object value aren't necessarily disjoint, so don't freak out if they overlap 😭 For example, 192.0.2.0/28's bottom objects are 192.0.2.0/28 and 192.0.2.0/32. 192.0.2.0/32 is included because it's one of the most-specific objects (aka an object at the bottom of the object hierarchy) for 192.0.2.0/28. Meanwhile, 192.0.2.0/28 itself is included because it's the most-specific object for the other addresses in the range (aka everything aside from 192.0.2.0/32). iconic, right?
the bottom objects for a given INR object value may include an object that's less specific than that INR object value 👀 For example, 192.0.2.0/31 is an INR object value that has a more-specific object, which is 192.0.2.0/32. So the set of bottom objects must include at least that object. The most-specific object that covers the residual (aka 192.0.2.1/32) is 192.0.2.0/28, so that gets included in the results too.
3.2.2. Relations
3.2.2.1. Single-Result Searches
3.2.2.1.1. "rdap-up"
if the server gets a search containing the relation value "rdap-up", it will return the parent object for the specified INR object value, as though that object had been requested directly 💅 If no such object exists, it will respond with an HTTP 404 (Not Found) [RFC9110] status code.
3.2.2.1.2. "rdap-top"
same energy, but with top objects 🦋 If the server gets a search containing the relation value "rdap-top", it will return the top object for the specified INR object value, as though that object had been requested directly. If no such object exists, it will respond with an HTTP 404 (Not Found) [RFC9110] status code.
3.2.2.2. Multiple-Result Searches
3.2.2.2.1. "rdap-down"
if the server gets a search containing the relation value "rdap-down", it will return the child objects for the specified INR object value ✨ If no such objects exist, it will return an empty search response. Per the definitions section, this includes only immediate child objects, so no grandkids 🧚
3.2.2.2.2. "rdap-bottom"
and last but not least, if the server gets a search containing the relation value "rdap-bottom", it will return the bottom objects for the specified INR object value 🌈 If no such objects exist, it will return an empty search response.
3.3. Status
if the "status" argument is provided, response processing proceeds as though every object without the specified status had been removed from the database first 🎀 For example, say the registry objects from Section 3.2.1 have these statuses:
+================+==========+
| Object | Status |
+================+==========+
| 192.0.2.0/25 | active |
+----------------+----------+
| 192.0.2.128/25 | inactive |
+----------------+----------+
| 192.0.2.128/26 | active |
+----------------+----------+
| 192.0.2.192/26 | active |
+----------------+----------+Table 5: Statuses
then a server that gets a "rdap-down" search request with the INR object value 192.0.2.0/24 and a "status" argument of "active" would return the objects 192.0.2.0/25, 192.0.2.128/26, and 192.0.2.192/26 💖
status filtering is super useful when the client is trying to find the delegation from an RIR to an RIR account holder 👑 If the client uses the "rdap-top" relation with a "status" of "active", the delegation from IANA to the RIR gets ignored, and the client gets the delegation from the RIR to the account holder in the response instead. no cap, that's clever.
By default, any valid status value may be used for status filtering. Server operators MAY opt not to support "status" filtering for the "rdap-down" and "rdap-bottom" link relations. In that case, the server responds with an HTTP 501 (Not Implemented) [RFC9110] response code if it gets such a request. Server operators MAY also opt not to support "status" filtering for values other than "active" for the "rdap-up" and "rdap-top" link relations. In that case, the server responds with an HTTP 501 (Not Implemented) [RFC9110] response code if it gets such a request 🙈
While any valid status value may be used for status filtering, a given RDAP server may only make use of a small number of those status values for INR objects. For example, a status value like "client hold" would typically only be used by a DNR for a forward domain name object 🍓
3.4. Link Relations 🔗
Okay bestie, every relation from Section 3.2.2 gets its own link relation 💖 that you can drop on a link object inside another RDAP object. When the server builds these link objects, it MUST point the link target at the matching search URL, or at a URL that gives back the same response the matching search would give at the time of the request 🎀. Here's an elided IPv4 example, and it's giving super organized vibes 🌸:
{
"startAddress": "192.0.2.0",
"endAddress": "192.0.2.127",
...
"links": [
...,
{
"value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-up",
"href": ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25",
"type": "application/rdap+json"
},
{
"value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-down",
"href": ".../rdap/ips/rirSearch1/rdap-down/192.0.2.0/25",
"type": "application/rdap+json"
},
{
"value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-top",
"href": ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25",
"type": "application/rdap+json"
},
{
"value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-bottom",
"href": ".../rdap/ips/rirSearch1/rdap-bottom/192.0.2.0/25",
"type": "application/rdap+json"
}
]
}Figure 2: Example Links in an IPv4 Response
Now the IPv6 version, same energy 🧚:
{
"startAddress": "2001:db8:a::",
"endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
...
"links": [
...,
{
"value": "https://example.com/rdap/ip/2001:db8:a::/48",
"rel": "rdap-up",
"href": ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48",
"type": "application/rdap+json"
},
{
"value": "https://example.com/rdap/ip/2001:db8:a::/48",
"rel": "rdap-down",
"href": ".../rdap/ips/rirSearch1/rdap-down/2001:db8:a::/48",
"type": "application/rdap+json"
},
{
"value": "https://example.com/rdap/ip/2001:db8:a::/48",
"rel": "rdap-top",
"href": ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48",
"type": "application/rdap+json"
},
{
"value": "https://example.com/rdap/ip/2001:db8:a::/48",
"rel": "rdap-bottom",
"href": ".../rdap/ips/rirSearch1/rdap-bottom/2001:db8:a::/48",
"type": "application/rdap+json"
}
]
}Figure 3: Example Links in an IPv6 Response
One extra link relation, "rdap-active", exists for flagging a search with a "status" of "active" 🦋. No other status link relations are defined 🙅, because the only known use cases for status filtering are the "rdap-up" and "rdap-top" relations paired with the "active" status. Here's the IPv4 example 💅:
{
"startAddress": "192.0.2.0",
"endAddress": "192.0.2.127",
...
"links": [
...,
{
"value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-up rdap-active",
"href":
".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25?status=active",
"type": "application/rdap+json"
},
{
"value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-top rdap-active",
"href":
".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25?status=active",
"type": "application/rdap+json"
}
]
}Figure 4: Example Status Links in an IPv4 Response
And the IPv6 status version 🌈:
{
"startAddress": "2001:db8:a::",
"endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
...
"links": [
...,
{
"value": "https://example.com/rdap/ip/2001:db8:a::/48",
"rel": "rdap-up rdap-active",
"href":
".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active",
"type": "application/rdap+json"
},
{
"value": "https://example.com/rdap/ip/2001:db8:a::/48",
"rel": "rdap-top rdap-active",
"href":
".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active",
"type": "application/rdap+json"
}
]
}Figure 5: Example Status Links in an IPv6 Response
Heads up:"rdap-active"only works as a link relation inside a link object. It can NOT be used as a value for<relation>in the relation search URL from Section 3.2 🙅♀️. Section 3.3 has all the juicy details on status filtering for relation search URLs.
Here's a fun one 🧠. The "rdap-top" and "rdap-up" link relations each resolve to either a single object or an HTTP 404 (Not Found) [RFC9110] response. That means a server can use a lookup URL (see Section 3.1 of [RFC9082]) in the "href" attribute of the link object instead. Here's an IPv4 example doing exactly that ✨:
{
"startAddress": "192.0.2.0",
"endAddress": "192.0.2.127",
...
"links": [
...,
{
"value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-up",
"href": "https://example.com/rdap/ip/192.0.2.0/24",
"type": "application/rdap+json"
}
]
}Figure 6: Example Single-Result Links in an IPv4 Response
And the IPv6 one 🦋:
{
"startAddress": "2001:db8:a::",
"endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
...
"links": [
...,
{
"value": "https://example.com/rdap/ip/2001:db8:a::/48",
"rel": "rdap-up",
"href": "https://example.com/rdap/ip/2001:db8::/32",
"type": "application/rdap+json"
}
]
}Figure 7: Example Single-Result Links in an IPv6 Response
Using these link relations in responses is OPTIONAL 🫶. And bestie, the absence of a link for a specific relation does NOT automatically mean the matching search will come back empty 🙈. Don't read into it!
4. Responding to Searches 🔍
4.1. Single-Result Searches
The "rdap-up" and "rdap-top" relations are single-result searches 🎯. When the server processes one of these and there's a result, it returns that object just like you'd get by requesting it directly with a lookup URL (see Section 3.1 of [RFC9082]). If there's no result, the server returns an HTTP 404 (Not Found) [RFC9110] response code 💀.
4.2. Multiple-Result Searches
The "rdap-down" and "rdap-bottom" relations are multiple-result searches 📚. Just like [RFC9083], responses for these take the form of an array of object instances, where each instance is an appropriate object class for the search. So a search beginning with /ips gives you an array of IP network object instances, and a search beginning with /autnums gives you an array of autonomous system number object instances 🧁. The IP network object class is defined in Section 5.4 of [RFC9083], and the autonomous system number object class is defined in Section 5.5 of [RFC9083]. The object instance arrays live inside the response object 🎀.
The array names go like this:
- for
/ipssearches, the array isipSearchResults; and - for
/autnumssearches, the array isautnumSearchResults.
Here's an elided IPv4 network search response 🌸:
{
"rdapConformance": [ "rdap_level_0", "rirSearch1",
"ips", "ipSearchResults", ... ],
...
"ipSearchResults": [
{
"objectClassName": "ip network",
"handle": "XXXX-RIR",
"startAddress": "192.0.2.0",
"endAddress": "192.0.2.127",
...
},
{
"objectClassName": "ip network",
"handle": "YYYY-RIR",
"startAddress": "192.0.2.0",
"endAddress": "192.0.2.255",
...
}
]
}Figure 8: IPv4 Network Search Response
And the IPv6 network search response 🧚:
{
"rdapConformance": [ "rdap_level_0", "rirSearch1",
"ips", "ipSearchResults", ... ],
...
"ipSearchResults": [
{
"objectClassName": "ip network",
"handle": "XXXX-RIR",
"startAddress": "2001:db8:a::",
"endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
...
},
{
"objectClassName": "ip network",
"handle": "YYYY-RIR",
"startAddress": "2001:db8::",
"endAddress": "2001:db8:ffff:ffff:ffff:ffff:ffff:ffff",
...
}
]
}Figure 9: IPv6 Network Search Response
And finally, an elided response to an autonomous system number search 💜:
{
"rdapConformance": [ "rdap_level_0", "rirSearch1",
"autnums", "autnumSearchResults", ... ],
...
"autnumSearchResults": [
{
"objectClassName": "autnum",
"handle": "XXXX-RIR",
"startAutnum": 64496,
"endAutnum": 64496,
...
},
{
"objectClassName": "autnum",
"handle": "YYYY-RIR",
"startAutnum": "64497",
"endAutnum": "64497",
...
}
]
}Figure 10: ASN Search Response
Responses for relation searches on reverse domain objects look exactly like a standard domain search response, per [RFC9083] 🌈.
If the server can process the search but there are no results, it returns an HTTP 404 (Not Found) [RFC9110] response code, and the body contains an empty results array 🫧.
5. Reverse Search 🕵️♀️
RDAP reverse search is defined by [RFC9536]. That doc limits reverse search to domains, nameservers, and entities, but this document extends it to cover IP networks and autonomous system numbers too 🙌.
If a server gets a reverse search query with a searchable resource type (per the definition of that term in [RFC9536]) of "ips", then the reverse search runs on the IP network objects in its data store. Same deal for a searchable resource type of "autnums", which runs on the autonomous system number objects in its data store 💖.
Also, Section 10 notes that new registrations for IP network and autonomous system number searches have been made in the "RDAP Reverse Search" and "RDAP Reverse Search Mapping" IANA registries 📋✨.
6. RDAP Conformance 🎀
Okay bestie, so a server that supports the stuff in this doc MUST add extra string literals to the rdapConformance array in its responses, following these rules:
- 🌸 any response that includes an IP network basic search link, an IP network relation search link, or an IP network reverse search link includes the
rirSearch1andipsliterals; - 💖 any response for an IP network basic search request, an IP network relation search request, or an IP network reverse search request includes the
rirSearch1,ips, andipSearchResultsliterals; - ✨ any response that includes an ASN basic search link, an ASN relation search link, or an ASN reverse search link includes the
rirSearch1andautnumsliterals; - 🦋 any response for an ASN basic search request, an ASN relation search request, or an ASN reverse search request includes the
rirSearch1,autnums, andautnumSearchResultsliterals; - 🧚 any response that includes a domain relation search link includes the
rirSearch1literal; - 🍓 any response for a domain relation search request includes the
rirSearch1literal; and - 👑 a response to a
/helprequest includes therirSearch1,ips,ipSearchResults,autnums, andautnumSearchResultsliterals.
Responses won't usually include every single rdapConformance literal in this doc, but that does not mean a server only gets to support part of the functionality here. Main character energy, all of it 💅
The ips, autnums, ipSearchResults, and autnumSearchResults extension identifiers are in here because of the requirements and recommendations in [RFC7480], [RFC9082], and [RFC9083]. Those rules say an RDAP extension identifier has to be used as a prefix in new path segments and JSON members that the extension introduces, and these strings get used that way in the basic searches defined here. Using them as path segments also keeps the basic searches for the core RDAP object classes consistent, which is so iconic 🫶
Like the other core object classes (entity, domain, and nameserver), other documents can define extra reverse searches with IP networks and ASNs as the searchable resource type, as long as they register them in the IANA RDAP reverse search registries. But a given extension identifier has to match one single extension, so any document that uses IP networks or ASNs as the searchable resource type also has to implement the functionality described here 🔥
The 1 in rirSearch1 means this is version 1 of the RIR search extension. New versions will use different extension identifiers. The rest of the identifiers in this doc don't get a version suffix, partly because a suffix would make them less consistent with the matching functionality for the other core object classes, and partly because that functionality is very unlikely to change 🌈
7. Operational Considerations 🌈
When you're using a link object for a single-result search, a server may replace a search URL with a lookup URL. The reason is that the lookup URL behaves the same as the search URL does at the time the response is generated. One difference between the two is that with a lookup URL, the server is effectively performing the search on behalf of the client as at the time of response generation. ✨
If the relevant database state doesn't change between when the original response is generated and when the client resolves the link relation target, then the search URL and the lookup URL lead to the same result. But if the relevant database state does change, the lookup URL may lead to a different result from the search URL. Server operators should consider which type of URL will work better for their clients when they implement this specification 👑
Where this doc includes HTTP reason phrases, that's purely for the benefit of the reader. It is not a sign that those phrases need to be used as-is in responses 💀
8. Privacy Considerations 🙈
The search functionality in this doc may affect the privacy of entities in the registry (and elsewhere) in various ways. See [RFC6973] for a general treatment of privacy in protocol specs, and [RFC7481] for specific discussion about privacy threats to the registration data RDAP provides. Server operators should be aware of the tradeoffs that come with implementing this functionality 🫣
Lots of jurisdictions have laws or regulations that restrict the use of "Personal Data", per the definition in [RFC6973]. Given that, server operators should check whether the regulatory environment they operate in lets them implement the functionality defined here 😭
9. Security Considerations 🔥
This is serious bestie, so pay attention 🚨 [RFC7481] describes security requirements and considerations for RDAP generally. Guidance on the use of TLS has also changed since that document was published, so see [RFC8446] and [BCP195] for further detail.
[RFC9082] includes security considerations relating to object retrieval in RDAP. Those considerations are relevant here as well, so don't skip them 💜
10. IANA Considerations 📋
10.1. RDAP Extensions Registry 🌸
IANA has registered the following values in the "RDAP Extensions" registry https://www.iana.org/assignments/rdap-extensions.
10.1.1. rirSearch1
Extension Identifier: rirSearch1
Registry operator: Any
Specification: RFC 9910
Contact: IETF <iesg@ietf.org>
Intended Usage: This extension identifier is used for INR-specific
search operations.10.1.2. ips
Extension Identifier: ips
Registry operator: Any
Specification: RFC 9910
Contact: IETF <iesg@ietf.org>
Intended Usage: This extension identifier is used for INR-specific
search operations.10.1.3. autnums
Extension Identifier: autnums
Registry operator: Any
Specification: RFC 9910
Contact: IETF <iesg@ietf.org>
Intended Usage: This extension identifier is used for INR-specific
search operations.10.1.4. ipSearchResults
Extension Identifier: ipSearchResults
Registry operator: Any
Specification: RFC 9910
Contact: IETF <iesg@ietf.org>
Intended Usage: This extension identifier is used for INR-specific
search operations.10.1.5. autnumSearchResults
Extension Identifier: autnumSearchResults
Registry operator: Any
Specification: RFC 9910
Contact: IETF <iesg@ietf.org>
Intended Usage: This extension identifier is used for INR-specific
search operations.10.2. Link Relations Registry 🦋
IANA has registered the following values in the "Link Relations" registry https://www.iana.org/assignments/link-relations.
10.2.1. rdap-up
Relation Name: rdap-up
Description: Refers to an RDAP parent object in a hierarchy of
objects.
Reference: RFC 991010.2.2. rdap-down
Relation Name: rdap-down
Description: Refers to a set of RDAP child objects in a hierarchy of
objects.
Reference: RFC 991010.2.3. rdap-top
Relation Name: rdap-top
Description: Refers to the topmost RDAP parent object in a hierarchy
of objects.
Reference: RFC 991010.2.4. rdap-bottom
Relation Name: rdap-bottom
Description: Refers to the set of child RDAP objects that do not
themselves have child objects, in a hierarchy of objects.
Reference: RFC 991010.2.5. rdap-active
Relation Name: rdap-active
Description: The target is for an RDAP RIR search that filters for
the status "active".
Reference: RFC 991010.3. RDAP Reverse Search Registry 🧚
IANA has registered the following entries in the "RDAP Reverse Search" registry https://www.iana.org/assignments/rdap-reverse-search/.
10.3.1. fn
Property: fn
Description: The server supports the IP/autnum search based on the
full name (a.k.a. formatted name) of an associated entity.
Searchable Resource Type: ips, autnums
Related Resource Type: entity
Registrant: IETF
Contact Information: iesg@ietf.org
Reference: RFC 991010.3.2. handle
Property: handle
Description: The server supports the IP/autnum search based on the
handle of an associated entity.
Searchable Resource Type: ips, autnums
Related Resource Type: entity
Registrant: IETF
Contact Information: iesg@ietf.org
Reference: RFC 991010.3.3. email
Property: email
Description: The server supports the IP/autnum search based on the
email address of an associated entity.
Searchable Resource Type: ips, autnums
Related Resource Type: entity
Registrant: IETF
Contact Information: iesg@ietf.org
Reference: RFC 991010.3.4. role
Property: role
Description: The server supports the IP/autnum search based on the
role of an associated entity.
Searchable Resource Type: ips, autnums
Related Resource Type: entity
Registrant: IETF
Contact Information: iesg@ietf.org
Reference: RFC 991010.4. RDAP Reverse Search Mapping Registry 🍓
IANA has registered the following entries in the "RDAP Reverse Search Mapping" registry https://www.iana.org/assignments/rdap-reverse-search-mapping.
10.4.1. fn
Property: fn
Property Path: $.entities[*].vcardArray[1][?(@[0]=='fn')][3]
Searchable Resource Type: ips, autnums
Related Resource Type: entity
Registrant: IETF
Contact Information: iesg@ietf.org
Reference: RFC 991010.4.2. handle
Property: handle
Property Path: $.entities[*].handle
Searchable Resource Type: ips, autnums
Related Resource Type: entity
Registrant: IETF
Contact Information: iesg@ietf.org
Reference: RFC 991010.4.3. email
Property: email
Property Path: $.entities[*].vcardArray[1][?(@[0]=='email')][3]
Searchable Resource Type: ips, autnums
Related Resource Type: entity
Registrant: IETF
Contact Information: iesg@ietf.org
Reference: RFC 991010.4.4. role
Property: role
Property Path: $.entities[*].roles
Searchable Resource Type: ips, autnums
Related Resource Type: entity
Registrant: IETF
Contact Information: iesg@ietf.org
Reference: RFC 991011. References 📚
11.1. Normative References
okay bestie, these are the docs this spec leans on so hard that you NEED to read them too 📚🫶 ngl they're the foundation, no cap
The first one is a whole Best Current Practice 🔒 It's about TLS, and at the time of writing it has these two RFCs in it:
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9536] Loffredo, M. and M. Martinelli, "Registration Data Access
Protocol (RDAP) Reverse Search", RFC 9536,
DOI 10.17487/RFC9536, April 2024,
<https://www.rfc-editor.org/info/rfc9536>.11.2. Informative References
these ones are the extra reading 🌸 not required to build the thing, but SO worth a look if you're curious about the history and the privacy side of things 👀
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.Acknowledgements 🫶
the authors wanted to give a huge shoutout to Mario Loffredo, Andy Newton, Antoin Verschuren, James Gould, Scott Hollenbeck, Orie Steele, Russ Housley, John Levine, Stewart Bryant, Mark Nottingham, Mohamed Boucadair, Deb Cooley, Éric Vyncke, and Roman Danyliw 💜 for reviewing the document and sharing their comments. the main character energy of this group is unmatched ✨
Authors' Addresses 💌
Tom Harrison
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Email: tomh@apnic.net
Jasdip Singh
American Registry for Internet Numbers
PO Box 232290
Centreville, VA 20120
United States of America
Email: jasdips@arin.net📦 where this page comes from
- ietf: rfc9910 2026-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms