RFC 7482

Registration Data Access Protocol (RDAP) Query Format

📅 published March 2015, from ietf

RFC 7482: Registration Data Access Protocol (RDAP) Query Format 🦋

okay bestie, this one is RFC 7482 and it's giving query format for RDAP 💅✨ It's a Standards Track document, so it's an actual IETF spec and not just vibes. It came out in March 2015 and has ISSN 2070-1721. The authors are A. Newton from ARIN and S. Hollenbeck from Verisign Labs 🌸 The header doesn't list anything it obsoletes or updates, so there's no drama there 🙈

Abstract 📜

okay so this doc describes uniform patterns for building HTTP URLs that you can use to grab registration info from registries 🔍 That covers both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs), and you do it with "RESTful" web access patterns 💖 These patterns are the query syntax for the Registration Data Access Protocol (RDAP) 🧚

Status of This Memo 📋

this one is an Internet Standards Track document 🎀

this document is a product of the Internet Engineering Task Force (IETF) 🦋 It represents the consensus of the IETF community, received public review, and got approved for publication by the Internet Engineering Steering Group (IESG) 👑 If you want more about Internet Standards, check Section 2 of RFC 5741 🍓

info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7482 ✨

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date 📜 Please actually read those, bestie, because they explain your rights and restrictions for this document 🙈 Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License 💅

Table of Contents 📖

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
    2.1.  Acronyms and Abbreviations  . . . . . . . . . . . . . . .   4
3.  Path Segment Specification  . . . . . . . . . . . . . . . . .   4
  3.1.  Lookup Path Segment Specification . . . . . . . . . . . .   5
    3.1.1.  IP Network Path Segment Specification . . . . . . . .   6
    3.1.2.  Autonomous System Path Segment Specification  . . . .   7
    3.1.3.  Domain Path Segment Specification . . . . . . . . . .   7
    3.1.4.  Nameserver Path Segment Specification . . . . . . . .   8
    3.1.5.  Entity Path Segment Specification . . . . . . . . . .   9
    3.1.6.  Help Path Segment Specification . . . . . . . . . . .   9
  3.2.  Search Path Segment Specification . . . . . . . . . . . .   9
    3.2.1.  Domain Search . . . . . . . . . . . . . . . . . . . .  10
    3.2.2.  Nameserver Search . . . . . . . . . . . . . . . . . .  11
    3.2.3.  Entity Search . . . . . . . . . . . . . . . . . . . .  12
4.  Query Processing  . . . . . . . . . . . . . . . . . . . . . .  13
  4.1.  Partial String Searching  . . . . . . . . . . . . . . . .  13
  4.2.  Associated Records  . . . . . . . . . . . . . . . . . . .  14
5.  Extensibility . . . . . . . . . . . . . . . . . . . . . . . .  14
6.  Internationalization Considerations . . . . . . . . . . . . .  15
  6.1.  Character Encoding Considerations . . . . . . . . . . . .  15
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  19
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction ✨

this doc is a spec for querying registration data using a RESTful web service and uniform query patterns 💖 The service runs on the Hypertext Transfer Protocol (HTTP) [RFC7230] and the conventions in [RFC7480] 🦋 These uniform patterns define the query syntax for RDAP 🧚

RDAP is meant to fix some known problems with the WHOIS protocol [RFC3912] that people have noticed over time 😭 Those problems are:

  • lack of standardized command structures;
  • lack of standardized output and error structures;
  • lack of support for internationalization and localization; and
  • lack of support for user identification, authentication, and access control.

the patterns here don't cover every method that WHOIS and the other RESTful web services used by the RIRs and DNRs have 🙈 They're meant to let you query:

  • networks by IP address;
  • Autonomous System (AS) numbers by number;
  • reverse DNS metadata by domain;
  • nameservers by name;
  • registrars by name; and
  • entities (such as contacts) by identifier.

servers are free to support only a subset of these features depending on local requirements 🌸 Servers MUST return an HTTP 501 (Not Implemented) [RFC7231] response to tell clients about unsupported query types 💅 Registries are also expected to keep running WHOIS and/or other RESTful web services for their own needs and their constituencies, and the info you get through these patterns may point you to those services 🫶

future IETF standards may add more patterns for more query types 🔮 Section 5 has a simple pattern namespacing scheme for custom extensions, so they won't mess with the patterns in this doc or the ones in future standards 👑

WHOIS services are generally read-only 📖 So URL [RFC3986] patterns in this doc only apply to the HTTP [RFC7231] GET and HEAD methods 🎀

this doc doesn't describe the results or entities you get back from running these URLs with an HTTP GET 🙈 Those are covered in [RFC7483] 🦋

resource management, provisioning, and update functions are out of scope too 🚫 Registries each have their own (very different) ways of doing those, so a uniform approach probably isn't needed for interoperability 💀

HTTP already has mechanisms for servers to authenticate clients and for clients to authenticate servers (authorization schemes can be built on top), so this doc doesn't describe those mechanisms 🔐 Policy, provisioning, and processing of authentication and authorization are also out of scope, since deployments have to make their own choices based on local criteria 🧚 Supported authentication mechanisms are in [RFC7481] 💖

2. Conventions Used in This Document 📐

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🌈

2.1. Acronyms and Abbreviations 🔤

  • IDN: Internationalized Domain Name
  • IDNA: Internationalized Domain Names in Applications, a protocol for the handling of IDNs.
  • DNR: Domain Name Registry
  • NFC: Unicode Normalization Form C [Unicode-UAX15]
  • NFKC: Unicode Normalization Form KC [Unicode-UAX15]
  • RDAP: Registration Data Access Protocol
  • REST: Representational State Transfer. The term was first described in a doctoral dissertation [REST].
  • RESTful: An adjective that describes a service using HTTP and the principles of REST.
  • RIR: Regional Internet Registry

3. Path Segment Specification 🧩

the base URLs for building RDAP queries live in an IANA registry described in [RFC7484] 🗂️ To make a query, you grab the right base URL from the registry and tack on a path segment from either Section 3.1 or Section 3.2 💖 A registry or other provider usually gives you a base URL that identifies the protocol, host, and port, and the full URL gets resolved against it, as per Section 5 of RFC 3986 [RFC3986] ✨ For example, if the base URL is https://example.com/rdap/, every RDAP query URL starts with https://example.com/rdap/ 🦋

the bootstrap registry doesn't have info for query objects that aren't part of a global namespace, like entities and help 🙈 So you need a base URL for an associated object to build a complete query 🎀

for entities, you get a base URL for the service (domain, address, etc.) tied to that entity 🧚 You build the query URL by sticking the base URL onto the entity path segment from Section 3.1.5 or 3.2.3 🌸

for help, you get a base URL for whatever service (domain, address, etc.) you need more info about 🫶 You build the query URL by sticking the base URL onto the help path segment from Section 3.1.6 🍓

3.1. Lookup Path Segment Specification 🔍

you can check if an object exists (or not) without getting RDAP-encoded results by using the HTTP HEAD method, as described in Section 4.1 of [RFC7480] 👀

the resource type path segments for exact match lookup are:

  • 'ip': Used to identify IP networks and associated data referenced using either an IPv4 or IPv6 address.
  • 'autnum': Used to identify Autonomous System number registrations and associated data referenced using an asplain Autonomous System number.
  • 'domain': Used to identify reverse DNS (RIR) or domain name (DNR) information and associated data referenced using a fully qualified domain name.
  • 'nameserver': Used to identify a nameserver information query using a host name.
  • 'entity': Used to identify an entity information query using a string identifier.

3.1.1. IP Network Path Segment Specification

Syntax: ip/<IP address> or ip/<CIDR prefix>/<CIDR length> 🦋

Okay so queries for IP networks look like /ip/XXX/... or /ip/XXX/YY/... 💖 The bit after ip is either an IPv4 dotted decimal address or an IPv6 [RFC5952] address (that's the XXX part), or an IPv4 or IPv6 Classless Inter-domain Routing (CIDR) [RFC4632] address block (that's XXX/YY). The vibe is that a plain address can be thought of as a CIDR block with a bitmask length of 32 for IPv4 and 128 for IPv6 ✨ Now here's the tea 🫖: one specific address or CIDR block can fall inside several IP networks stacked in a hierarchy. So this query targets the "most-specific" one, aka the smallest IP network that completely encompasses it. Main character energy for the smallest network 👑

The IPv4 and IPv6 address formats allowed here are described in Section 3.2.2 of RFC 3986 [RFC3986] as the IPv4address and IPv6address ABNF definitions 🌸 Any valid IPv6 text address format [RFC4291] works. That includes IPv6 addresses written with or without compressed zeros, and IPv6 addresses that contain embedded IPv4 addresses 🧚 The rules for writing a text representation of an IPv6 address [RFC5952] are RECOMMENDED 🎀 However, the zone_id [RFC4007] is not appropriate in this context, so the matching syntax extension in RFC 6874 [RFC6874] MUST NOT be used 🙈 Servers are supposed to ignore it if they can. Not them, but also not your problem 💅

For example, this URL finds info for the most specific network containing 192.0.2.0:

https://example.com/rdap/ip/192.0.2.0

This one finds info for the most specific network containing 192.0.2.0/24:

https://example.com/rdap/ip/192.0.2.0/24

And this one finds info for the most specific network containing 2001:db8::0:

https://example.com/rdap/ip/2001:db8::0

3.1.2. Autonomous System Path Segment Specification

Syntax: autnum/<autonomous system number> 🍓

Queries about Autonomous System number registrations look like /autnum/XXX/..., where XXX is an asplain Autonomous System number [RFC5396]. Some registries register Autonomous System numbers one at a time, while others register whole blocks of them 🌈 Here's the semantics bit: if a number falls inside a range of registered blocks, the query targets the block registration. Individual number registrations are treated as a block with a size of 1. Iconic 🔥

For example, this URL finds info describing Autonomous System number 12, which is a number inside a range of registered blocks:

https://example.com/rdap/autnum/12

This one finds info describing 4-byte Autonomous System number 65538:

https://example.com/rdap/autnum/65538

3.1.3. Domain Path Segment Specification

Syntax: domain/<domain name> 🌸

Domain queries look like /domain/XXXX/..., where XXXX is a fully qualified (relative to the root) domain name, as specified in [RFC0952] and [RFC1123] 💖 That's either in the in-addr.arpa or ip6.arpa zones (for RIRs), or a fully qualified domain name in a zone run by the server operator (for DNRs). Internationalized Domain Names (IDNs) in either A-label or U-label format [RFC5890] are valid too ✨ For U-label character encoding info, go see Section 6.1 🦋

Okay now the lowkey important rule 🚨 IDNs SHOULD NOT be a mixture of A-labels and U-labels. Like, the internationalized labels in one IDN SHOULD be all A-labels or all U-labels, not a messy blend 💀 Why does this matter? An RDAP client might build a query string from several independent data sources, and it might not be able to convert between A-labels and U-labels. So if an RDAP server gets a query string that's a mix of both, it MAY convert all the U-labels to A-labels, do IDNA processing, and then go for an exact-match lookup 🫶 In that case, the response might not match what the query source sent in. Or the server MAY refuse to process the query altogether. Your choice, server 👑

The server MAY do the match using either the A-label or U-label form. Using one consistent form for every label is likely to be more reliable 🧚

This URL finds info describing the zone serving the network 192.0.2/24:

https://example.com/rdap/domain/2.0.192.in-addr.arpa

This one finds info describing the zone serving the network 2001:db8:1::/48:

https://example.com/rdap/domain/1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

This one finds info for the blah.example.com domain name:

https://example.com/rdap/domain/blah.example.com

And this one finds info for the xn--fo-5ja.example IDN:

https://example.com/rdap/domain/xn--fo-5ja.example

3.1.4. Nameserver Path Segment Specification

Syntax: nameserver/<nameserver name> 🎀

The <nameserver name> parameter is a fully qualified host name, as specified in [RFC0952] and [RFC1123] 💅 Internationalized names in either A-label or U-label format [RFC5890] are valid nameserver names too. IDN processing for nameserver names uses the domain name processing instructions from Section 3.1.3 🦋 For U-label character encoding, see Section 6.1 ✨

This URL finds info for the ns1.example.com nameserver:

https://example.com/rdap/nameserver/ns1.example.com

And this one finds info for the ns1.xn--fo-5ja.example nameserver:

https://example.com/rdap/nameserver/ns1.xn--fo-5ja.example

3.1.5. Entity Path Segment Specification

Syntax: entity/<handle> 🌈

The <handle> parameter is an entity identifier (like a contact, registrant, or registrar) whose syntax is specific to the registration provider 🧚 For example, for some DNRs, contact identifiers are specified in [RFC5730] and [RFC5733] 💜

This URL finds info for the entity associated with handle XXXX:

https://example.com/rdap/entity/XXXX

3.1.6. Help Path Segment Specification

Syntax: help 🙈

The help path segment is there to ask an RDAP server for helpful info 🆘 That could be command syntax, terms of service, privacy policy, rate-limiting policy, supported authentication methods, supported extensions, technical support contact, and more. The response to "help" should give basic info a client needs to successfully use the service 🫶 This URL returns "help" info:

https://example.com/rdap/help

3.2. Search Path Segment Specification

Pattern matching semantics are described in Section 4.1 ✨ The resource type path segments for search are:

  • domains: Used to search for domain name info, using a pattern to match a fully qualified domain name 🦋
  • nameservers: Used to search for nameserver info, using a pattern to match a host name 🌸
  • entities: Used to search for entity info, using a pattern to match a string identifier 💜

RDAP search path segments are a mash-up of the plural form of the object you're searching for plus an HTTP query string 🎀 The query string is built from a question mark (?, US-ASCII value 0x003F), the JSON object value for the object being searched for, an equal sign (=, US-ASCII value 0x003D), and the search pattern. Search pattern query processing gets the full tea in Section 4 ☕ For the domain, nameserver, and entity objects in this document, the plural forms are "domains", "nameservers", and "entities" 👑

You can get detailed results using the HTTP GET method and the path segments specified here 💅

Syntax: domains?name=<domain search pattern> 🌈

Syntax: domains?nsLdhName=<domain search pattern> 🍓

Syntax: domains?nsIp=<domain search pattern> 🦋

Searching for domain info by name looks like this:

domains?name=XXXX

XXXX is a search pattern for a domain name in "letters, digits, hyphen" (LDH) format [RFC5890] in a zone run by the server operator of a DNR 💖 This URL finds DNR info for domain names matching the "example*.com" pattern:

https://example.com/rdap/domains?name=example*.com

IDNs in U-label format [RFC5890] can be used as search patterns too (see Section 4) ✨ Searches for these names look like /domains?name=XXXX, where XXXX is a search pattern for a domain name in U-label format [RFC5890]. For U-label character encoding, check Section 6.1 🫶

Searching for domain info by nameserver name looks like this:

domains?nsLdhName=YYYY

YYYY is a search pattern for a host name in "letters, digits, hyphen" format [RFC5890] in a zone run by the server operator of a DNR 🎀 This URL searches for domains delegated to nameservers matching the "ns1.example*.com" pattern:

https://example.com/rdap/domains?nsLdhName=ns1.example*.com

Searching for domain info by nameserver IP address looks like this:

domains?nsIp=ZZZZ

ZZZZ is a search pattern for an IPv4 [RFC1166] or IPv6 [RFC5952] address 🧚 This URL searches for domains delegated to nameservers that resolve to the "192.0.2.0" address:

https://example.com/rdap/domains?nsIp=192.0.2.0

Syntax: nameservers?name=<nameserver search pattern> 💜

Syntax: nameservers?ip=<nameserver search pattern> 🌸

Searching for nameserver info by nameserver name looks like this:

nameservers?name=XXXX

XXXX is a search pattern for a host name in "letters, digits, hyphen" format [RFC5890] in a zone run by the server operator of a DNR 💅 This URL finds DNR info for nameserver names matching the "ns1.example*.com" pattern:

https://example.com/rdap/nameservers?name=ns1.example*.com

Internationalized nameserver names in U-label format [RFC5890] can be used as search patterns too (see Section 4) 🦋 Searches for these names look like /nameservers?name=XXXX, where XXXX is a search pattern for a nameserver name in U-label format [RFC5890]. For U-label character encoding, see Section 6.1 🌈

Searching for nameserver info by IP address looks like this:

nameservers?ip=YYYY

YYYY is a search pattern for an IPv4 [RFC1166] or IPv6 [RFC5952] address 🫶 This URL searches for nameserver names that resolve to the "192.0.2.0" address:

https://example.com/rdap/nameservers?ip=192.0.2.0

Okay bestie, entity search has two syntaxes, so let's look at both 💖

Syntax: entities?fn=<entity name search pattern>

Syntax: entities?handle=<entity handle search pattern>

Searching for entity info by name uses this form:

entities?fn=XXXX

XXXX is a search pattern for the "FN" property of an entity (like a contact, registrant, or registrar) name, as defined in Section 5.1 of [RFC7483]. This URL would find info for entity names matching the "Bobby Joe*" pattern:

https://example.com/rdap/entities?fn=Bobby%20Joe*

Searching for entity info by handle uses this form:

entities?handle=XXXX

XXXX is a search pattern for an entity identifier (like a contact, registrant, or registrar) whose syntax is specific to the registration provider. This URL would find info for entity handles matching the "CID-40*" pattern:

https://example.com/rdap/entities?handle=CID-40*

URLs MUST be properly encoded according to the rules of [RFC3986]. In the example above, "Bobby Joe*" gets encoded to "Bobby%20Joe*" 🎀

4. Query Processing 🔍

Servers tell the client whether query processing worked or not by returning an appropriate HTTP response code. Response codes that aren't specifically identified in this document are described in [RFC7480] ✨

4.1. Partial String Searching 🌸

Partial string searching uses the asterisk (*, US-ASCII value 0x002A) to match zero or more trailing characters. A character string representing multiple domain name labels MAY be tacked onto the end of the search pattern to limit the scope of the search. For example, the search pattern "exam*" will match "example.com" and "example.net". The search pattern "exam*.com" will match "example.com". If an asterisk shows up in a search string, any label containing the non-asterisk characters in sequence plus zero or more characters in sequence in place of the asterisk would match. Any additional pattern matching processing is beyond the scope of this specification 💅

If a server gets a search request but can't process it because it doesn't support that particular style of partial match searching, it SHOULD return an HTTP 422 (Unprocessable Entity) [RFC4918] response. When returning a 422 error, the server MAY also return an error response body as specified in Section 6 of [RFC7483] if the requested media type is one that is specified in [RFC7480].

Partial matching is not feasible across combinations of Unicode characters, because Unicode characters can be combined with each other. Servers SHOULD NOT partially match combinations of Unicode characters where a legal combination is possible. It should be noted, though, that it may not always be possible to detect cases where a character could have been combined with another character but wasn't, because characters can be combined in many different ways 🙈

Clients should avoid submitting a partial match search of Unicode characters where a Unicode character may be legally combined with another Unicode character or characters. Partial match searches with incomplete combinations of characters, where a character must be combined with another character or characters, are invalid. Partial match searches with characters that may be combined with another character or characters are to be considered non-combined characters. In other words, if character x may be combined with character y but character y is not submitted in the search string, then character x is a complete character and no combinations of character x are to be searched 🦋

4.2. Associated Records 🦋

Conceptually, any query-matching record in a server's database might be a member of a set of related records, related in some fashion as defined by the server (for example, variants of an IDN). The entire set ought to be considered as candidates for inclusion when constructing the response. However, the construction of the final response needs to be mindful of privacy and other data-releasing policies when assembling the RDAP response set 🔒

Note too that because of how searching works, there may be a list of query-matching records. Each one of those is subject to being a member of a set, as described in the previous paragraph. What is ultimately returned in a response will be the union of all the sets, filtered by whatever policies are in place.

This model includes arrangements for associated names, including those linked by policy mechanisms and names bound together for other purposes. Also, returning information that wasn't explicitly selected by an exact-match lookup, including additional names that match a relatively fuzzy search as well as lists of names that are linked together, may cause privacy issues 👀

There might not be a single, static information return policy that applies to all clients equally. Client identity and associated authorizations can be a relevant factor in determining how broad the response set will be for any particular query ✨

5. Extensibility 🎀

This document describes path segment specifications for a limited number of objects commonly registered in both RIRs and DNRs. It does not attempt to describe path segments for all of the objects registered in all registries. Custom path segments can be created for objects not specified here using the process described in Section 6 of "HTTP Usage in the Registration Data Access Protocol (RDAP)" [RFC7480] 🧁

Custom path segments can be created by prefixing the segment with a unique identifier followed by an underscore character (0x5F). For example, a custom entity path segment could be created by prefixing "entity" with "custom_", producing custom_entity. Servers MUST return an appropriate failure status code for a request with an unrecognized path segment ⭐

6. Internationalization Considerations 🌈

There is value in supporting the ability to submit either a U-label (Unicode form of an IDN label) or an A-label (US-ASCII form of an IDN label) as a query argument to an RDAP service. Clients that can process non-US-ASCII characters may prefer a U-label, since it's more visually recognizable and familiar than A-label strings. Clients using programmatic interfaces, though, might find it easier to submit and display A-labels if they can't input U-labels with their keyboard configuration. Both query forms are acceptable 🫶

Internationalized domain and nameserver names can contain character variants and variant labels as described in [RFC4290]. Clients that support queries for internationalized domain and nameserver names MUST accept service provider responses that describe variants as specified in "JSON Responses for the Registration Data Access Protocol (RDAP)" [RFC7483] 💜

6.1. Character Encoding Considerations 💅

Servers can expect to receive search patterns from clients that contain character strings encoded in different forms supported by HTTP. It is entirely possible to apply filters and normalization rules to search patterns before making character comparisons, but this type of processing is more typically needed to determine the validity of registered strings than to match patterns 🧚

An RDAP client submitting a query string containing non-US-ASCII characters converts that string into Unicode in UTF-8 encoding. It then performs any local case mapping it deems necessary. Strings are normalized using Normalization Form C (NFC) [Unicode-UAX15], though note that clients might not be able to do this reliably. UTF-8 encoded strings are then appropriately percent-encoded [RFC3986] in the query URL.

After parsing any percent-encoding, an RDAP server treats each query string as Unicode in UTF-8 encoding. If a string is not valid UTF-8, the server can immediately stop processing the query and return an HTTP 400 (Bad Request) response 🚫

When processing queries, DNS names are handled differently from everything else, including DNS names with putative U-labels. DNS names are treated according to the DNS matching rules described in Section 3.1 of RFC 1035 [RFC1035] for Non-Reserved LDH (NR-LDH) labels, and the matching rules described in Section 5.4 of RFC 5891 [RFC5891] for U-labels. Matching of DNS names proceeds one label at a time, because a combination of U-labels and NR-LDH labels can be found in a single domain or host name. Whether a label is a U-label or an NR-LDH label is based on whether the label contains any characters outside of the US-ASCII letters, digits, or hyphen (the so-called LDH rule) 🔤

For everything else, servers map fullwidth and halfwidth characters to their decomposition equivalents. Servers convert strings to the same coded character set as the target data that is to be looked up or searched, and each string is normalized using the same normalization that was used on the target data. In general, storing strings as Unicode is RECOMMENDED. For the purposes of comparison, Normalization Form KC (NFKC) [Unicode-UAX15] with case folding is used to maximize predictability and the number of matches. Note the use of case-folded NFKC as opposed to NFC in this case 🌸

7. Security Considerations 🔥

Okay bestie, this section is SERIOUS, so pay attention 🚨

Security services for the operations specified in this document are described in "Security Services for the Registration Data Access Protocol (RDAP)" [RFC7481] 🔐

Search functionality typically requires more server resources (such as memory, CPU cycles, and network bandwidth) than basic lookup functionality does. This increases the risk of server resource exhaustion and subsequent denial of service due to abuse. This risk can be mitigated by developing and implementing controls that restrict search functionality to identified and authorized clients. If those clients behave badly, their search privileges can be suspended or revoked. Rate limiting, as described in Section 5.5 of "HTTP Usage in the Registration Data Access Protocol (RDAP)" [RFC7480], can also be used to control the rate of received search requests. Server operators can also reduce their risk by restricting the amount of information returned in response to a search request 💀

Search functionality also increases the privacy risk of disclosing object relationships that might not otherwise be obvious. For example, a search that returns IDN variants [RFC6927] that do not explicitly match a client-provided search pattern can disclose information about registered domain names that might not be otherwise available. Implementers need to consider the policy and privacy implications of returning information that was not explicitly requested 🙈

Note that there might not be a single, static information return policy that applies to all clients equally. Client identity and associated authorizations can be a relevant factor in determining how broad the response set will be for any particular query 💜

8. References 📚

8.1. Normative References 📚✨

okay bestie, here's the must-read pile 🫶 each one is a reference the spec leans on, so every entry is listed with all its details.

8.2. Informative References 🦋

these ones are the extra-credit reading, super helpful for context but not the core rules 🌸

Acknowledgements 🫶

this whole doc is built on earlier work 💜 the RIR query format stuff came from Byron J. Ellacott of APNIC, Arturo L. Servin of LACNIC, Kaveh Ranjbar of the RIPE NCC, and Andrew L. Newton of ARIN. it also pulls in the DNR query formats from Francisco Arias and Steve Sheng of ICANN, plus Scott Hollenbeck of Verisign Labs 👑

the authors also thanked everyone who helped out with contributions: Francisco Arias, Marc Blanchet, Ernie Dainow, Jean-Philippe Dionne, Byron J. Ellacott, Behnam Esfahbod, John Klensin, John Levine, Edward Lewis, Mark Nottingham, Kaveh Ranjbar, Arturo L. Servin, Steve Sheng, and Andrew Sullivan. the squad is iconic 🌈✨

Authors' Addresses 🦋

Andrew Lee Newton
American Registry for Internet Numbers
3635 Concorde Parkway
Chantilly, VA  20151
United States

EMail: andy@arin.net
URI:   http://www.arin.net


Scott Hollenbeck
Verisign Labs
12061 Bluemont Way
Reston, VA  20190
United States

EMail: shollenbeck@verisign.com
URI:   http://www.verisignlabs.com/
📦 where this page comes from