RFC 9082

Registration Data Access Protocol (RDAP) Query Format

📅 published June 2021, from ietf

Registration Data Access Protocol (RDAP) Query Format 🎀

Okay bestie, this is RFC 9082 💅 It's a Standards Track document (STD 95) from June 2021, written by S. Hollenbeck at Verisign Labs and A. Newton at AWS. It's published under ISSN 2070-1721. It obsoletes RFC 7482, which means it replaces that one. The header doesn't list any Updates, so it doesn't update anything. It's giving official IETF standard energy ✨

Abstract

This doc is all about uniform patterns for building HTTP URLs 🌸 You use them to fetch registration info from registries, both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs), using "RESTful" web access patterns. These patterns are the query syntax for the Registration Data Access Protocol (RDAP). It obsoletes RFC 7482, so that's the vibe 🦋

Status of This Memo

This is an Internet Standards Track document. ✨

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841. 🧚

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9082. 💜

Copyright (c) 2021 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 stand on the publication date. Please actually read these, because they spell out your rights and restrictions. Code Components pulled out of this document have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. ⚠️

Table of Contents 📑

   1.  Introduction
   2.  Conventions Used in This Document
     2.1.  Acronyms and Abbreviations
   3.  Path Segment Specification
     3.1.  Lookup Path Segment Specification
       3.1.1.  IP Network Path Segment Specification
       3.1.2.  Autonomous System Path Segment Specification
       3.1.3.  Domain Path Segment Specification
       3.1.4.  Nameserver Path Segment Specification
       3.1.5.  Entity Path Segment Specification
       3.1.6.  Help Path Segment Specification
     3.2.  Search Path Segment Specification
       3.2.1.  Domain Search
       3.2.2.  Nameserver Search
       3.2.3.  Entity Search
   4.  Query Processing
     4.1.  Partial String Searching
     4.2.  Associated Records
   5.  Extensibility
   6.  Internationalization Considerations
     6.1.  Character Encoding Considerations
   7.  IANA Considerations
   8.  Security Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Appendix A.  Changes from RFC 7482
   Acknowledgments
   Authors' Addresses

1. Introduction 🌈

So this spec describes how to query registration data with a RESTful web service and uniform query patterns. The service runs on the Hypertext Transfer Protocol (HTTP) [RFC7230] plus the conventions in [RFC7480]. These patterns define the query syntax for RDAP, and again, this one obsoletes RFC 7482 🫶

RDAP is meant to fix some known WHOIS problems [RFC3912] that piled up over time 🙈 The 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 purposefully do NOT cover every method the RIRs and DNRs use in their WHOIS and other RESTful services. The goal is to enable queries of:

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

Servers are free to support only a subset of these features based on local needs 💅 But Servers MUST return an HTTP 501 (Not Implemented) [RFC7231] response to tell clients about any unsupported query types. Also, the plan is for each registry to keep maintaining WHOIS and/or other RESTful services for its own needs and its community's needs. The info you get through these patterns may point to those services 🍓

Future IETF specs may add more patterns for more query types. Section 5 describes a simple namespacing scheme for custom extensions so they won't clash with the patterns here or with future IETF patterns ✨

WHOIS services are generally read-only, so the URL [RFC3986] patterns in this document only apply to the HTTP [RFC7231] GET and HEAD methods. 👀

This document doesn't describe the results or entities you get back from issuing the URLs with an HTTP GET. That's covered in [RFC9083] 📦

Resource management, provisioning, and update functions are also out of scope. Registries each have their own (very different) ways of doing these, and a uniform approach probably isn't needed for interoperability 🧚

HTTP already has mechanisms for servers to authenticate clients and for clients to authenticate servers, which authorization schemes can be built on, so this document doesn't describe those mechanisms. Policy, provisioning, and processing of authentication and authorization are out of scope too, since deployments have to choose based on local criteria. Supported authentication mechanisms are described in [RFC7481] 🔐

2. Conventions Used in This Document 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🔥

2.1. Acronyms and Abbreviations 💜

  • IDN: Internationalized Domain Name, a fully-qualified domain name containing one or more labels that are intended to include one or more Unicode code points outside the ASCII range (cf. "domain name", "fully-qualified domain name", and "internationalized domain name" in RFC 8499 [RFC8499]).
  • IDNA: Internationalized Domain Names in Applications, a protocol for the handling of IDNs. In this document, "IDNA" refers specifically to the version of those specifications known as "IDNA2008" [RFC5890].
  • DNR: Domain Name Registry or Domain Name Registrar
  • 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 used to build RDAP queries are kept in an IANA registry (the "bootstrap registry") described in [RFC7484]. To make a query, you grab the right base URL from that registry and append a path segment from either Section 3.1 or Section 3.2. Usually a registry or other service provider gives you a base URL that identifies the protocol, host, and port. That base URL is what the complete URL gets resolved against, as per Section 5 of RFC 3986 [RFC3986]. For example, if the base URL is https://example.com/rdap/, then all RDAP query URLs will begin 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. You NEED a base URL for an associated object to build a complete query, though. You can get around this for entities using the practice in RFC 8521 [RFC8521] 🙌

For entities, you retrieve a base URL for the service (domain, address, etc.) tied to the entity. Then you build the query URL by concatenating that base URL with the entity path segment from Section 3.1.5 or Section 3.2.3.

For help, you retrieve a base URL for any service (domain, address, etc.) where you need more info. Then you build the query URL by concatenating that base URL with the help path segment from Section 3.1.6.

3.1. Lookup Path Segment Specification ✨

A simple lookup to check whether an object exists, without getting RDAP-encoded results back, can be done with 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 🌸 Whatever comes after ip is either an IPv4 dotted decimal or IPv6 [RFC5952] address (that's the XXX), or an IPv4 or IPv6 Classless Inter-domain Routing (CIDR) [RFC4632] address block (that's the XXX/YY) 💅. A plain address can be treated like a CIDR block with a prefix length of 32 for IPv4 and 128 for IPv6 🧚. A specific address or CIDR can sit inside several IP networks in a hierarchy, so this query targets the "most-specific" or smallest IP network that completely encompasses it 🎀.

The IPv4 and IPv6 address formats you can use here are the IPv4address and IPv6address ABNF definitions in Section 3.2.2 of RFC 3986 [RFC3986] 🦋. Any valid IPv6 text address format [RFC4291] works, including addresses with or without compressed zeros and addresses that contain embedded IPv4 addresses 💜. Following the rules for writing a text representation of an IPv6 address [RFC5952] is RECOMMENDED 🌈. BUT the zone_id [RFC4007] isn't appropriate in this context 🙈. So the syntax extension in RFC 6874 [RFC6874] MUST NOT be used, and servers SHOULD ignore it 💀.

Quick reminder: don't use the RFC 6874 zone_id syntax here. Servers should ignore it, so it's not the move 🚫

Example time 🍓 To find info for the most specific network containing 192.0.2.0, use https://example.com/rdap/ip/192.0.2.0 ✨

To find info for the most specific network containing 192.0.2.0/24, use https://example.com/rdap/ip/192.0.2.0/24 🌸

To find info for the most specific network containing 2001:db8::, use https://example.com/rdap/ip/2001:db8:: 💖

3.1.2. Autonomous System Path Segment Specification 🌟

Syntax:  autnum/<autonomous system number>

okay this one is for Autonomous System number registrations 🦋 The format is /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 🧁. The rule is that if a number falls inside a range of registered blocks, the query's target is the block registration 👑. Individual number registrations get treated like a block with a size of 1 🌈.

For example, to find info describing Autonomous System number 12 (a number within a range of registered blocks), use https://example.com/rdap/autnum/12 🎀

To find info describing 4-byte Autonomous System number 65538, use https://example.com/rdap/autnum/65538 ✨

3.1.3. Domain Path Segment Specification 🍓

Syntax:  domain/<domain name>

for domain info, the format is /domain/XXXX 💅 XXXX is a fully qualified (relative to the root) domain name, as specified in [RFC0952] and [RFC1123] 🌸 It can be in the in-addr.arpa or ip6.arpa zones (for RIRs), or a fully qualified domain name in a zone that the server operator runs (for DNRs) 🧚 Internationalized Domain Names (IDNs) written in either A-label or U-label format [RFC5890] are valid too 🦋 For info on character encoding for the U-label format, see Section 6.1 💜

IDNs SHOULD NOT be a mix of A-labels and U-labels 🙅‍♀️ Basically, the internationalized labels in an IDN SHOULD be all A-labels or all U-labels, not a blend 🎀 It's possible for an RDAP client to put together a query string from several independent data sources 🧩 But a client like that might not be able to convert between A-labels and U-labels 😭 If an RDAP server gets a query string that mixes A-labels and U-labels, it MAY convert all the U-labels to A-labels, do IDNA processing, and go on with an exact-match lookup 🔥 In that case, the response sent back to the query source might not match what the source typed in 🙈 Or, the server MAY refuse to process the query 💀

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

Here's the zone serving the network 192.0.2/24: https://example.com/rdap/domain/2.0.192.in-addr.arpa 🌸

Here's 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 🧚

To find info for the blah.example.com domain name, use https://example.com/rdap/domain/blah.example.com 💖

To find info for the xn--fo-5ja.example IDN, use 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 in Section 3.1.3 🎀 For info on character encoding for the U-label format, see Section 6.1 ✨

To find info for the ns1.example.com nameserver, use https://example.com/rdap/nameserver/ns1.example.com 🌸

To find info for the ns1.xn--fo-5ja.example nameserver, use 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 💅 Its syntax depends on the registration provider 🌈 For example, for some DNRs, contact identifiers are specified in [RFC5730] and [RFC5733] 🦋

To find info for the entity associated with handle XXXX, use https://example.com/rdap/entity/XXXX ✨

3.1.6. Help Path Segment Specification 🆘

Syntax:  help

the help path segment is how you 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 that a client needs to use the service successfully 💖

To return "help" info, use https://example.com/rdap/help 🌸

3.2. Search Path Segment Specification 🔍

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

  • 'domains': used to identify a domain name info search that uses a pattern to match a fully qualified domain name 🌐
  • 'nameservers': used to identify a nameserver info search that uses a pattern to match a host name 🖥️
  • 'entities': used to identify an entity info search that uses a pattern to match a string identifier 🧾

okay so RDAP search path segments are made by smooshing together the plural form of the object you're searching for and an HTTP query string 🧩 The query string is a question mark character ('?', US-ASCII value 0x003F), a noun for the JSON object property tied to the object you're searching for, an equal sign ('=', US-ASCII value 0x003D), and then the search pattern 🎀 (This is different from the more generic HTTP query string, which lets you have multiple parameters at once 🙃) Search pattern query processing is covered more fully 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 with the HTTP GET method and the path segments we just talked about 🦋

Syntax:  domains?name=<domain search pattern>

Syntax:  domains?nsLdhName=<nameserver search pattern>

Syntax:  domains?nsIp=<nameserver IP address>

searching for domain info by name uses this form: domains?name=XXXX 💅 XXXX is a search pattern for a domain name in "letters, digits, hyphen" (LDH) format [RFC5890] 🧚 To find DNR info for domain names that match the "example*.com" pattern, use https://example.com/rdap/domains?name=example*.com ✨

IDNs in U-label format [RFC5890] can also be search patterns (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 info on character encoding for the U-label format, see Section 6.1 💜

Searching for domain info by nameserver name uses this form: domains?nsLdhName=YYYY 🎀 YYYY is a search pattern for a host name in "letters, digits, hyphen" format 💖 To search for domains delegated to nameservers that match the "ns1.example*.com" pattern, use https://example.com/rdap/domains?nsLdhName=ns1.example*.com 🌷

Searching for domain info by nameserver IP address uses this form: domains?nsIp=ZZZZ 🧩 ZZZZ is an IPv4 [RFC1166] or IPv6 [RFC5952] address 🌈 To search for domains that have been delegated to nameservers that resolve to the "192.0.2.0" address, use https://example.com/rdap/domains?nsIp=192.0.2.0 🫶

Syntax:  nameservers?name=<nameserver search pattern>

Syntax:  nameservers?ip=<nameserver IP address>

searching for nameserver info by nameserver name uses this form: nameservers?name=XXXX 💅 XXXX is a search pattern for a host name in "letters, digits, hyphen" format [RFC5890] 🌸 To find info for nameserver names that match the "ns1.example*.com" pattern, use https://example.com/rdap/nameservers?name=ns1.example*.com ✨

Internationalized nameserver names in U-label format [RFC5890] can also be search patterns (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 info on character encoding for the U-label format, see Section 6.1 💜

Searching for nameserver info by nameserver IP address uses this form: nameservers?ip=YYYY 🎀 YYYY is an IPv4 [RFC1166] or IPv6 [RFC5952] address 💖 To search for nameserver names that resolve to the "192.0.2.0" address, use https://example.com/rdap/nameservers?ip=192.0.2.0 🌈

Okay so entity search is how you look up people and orgs (contacts, registrants, registrars) by name or by handle. There are two syntaxes, and both are giving organized 💅

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

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

Searching by name uses this form: entities?fn=XXXX. The XXXX part is a search pattern for the "fn" property of an entity (like a contact, registrant, or registrar) name, as described in Section 5.1 of [RFC9083]. So if you want everything matching "Bobby Joe*", you'd hit this URL:

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

Searching by handle uses this form: entities?handle=XXXX. Here XXXX is a search pattern for an entity identifier (contact, registrant, or registrar), and the exact syntax of that identifier is up to each registration provider 🧚 For "CID-40*" handles, the URL would be:

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

URLs MUST be properly encoded according to the rules of [RFC3986]. Look at the example above: "Bobby Joe*" becomes Bobby%20Joe*. Encoding is not optional, bestie 🫶

4. Query Processing 💅

Servers tell clients whether a query worked by sending back an appropriate HTTP response code. Any codes that aren't specifically covered in this document are described in [RFC7480]. Easy peasy ✨

4.1. Partial String Searching 🦋

Partial string searching uses the asterisk (*, US-ASCII value 0x2A) to match zero or more trailing characters. A character string representing a domain label suffix MAY be tacked onto the end of the search pattern to narrow the search. For example, exam* will match "example.com" and "example.net", while exam*.com will only match "example.com". If an asterisk shows up in a search string, any label that has the non-asterisk characters in order, plus zero or more characters in the asterisk's spot, counts as a match. A partial string search MUST NOT include more than one asterisk. Anything fancier than that is beyond the scope of this specification, so no pattern-matching deep dives here 🙈

If a server gets a search request it can't process because it doesn't support that style of partial match, it SHOULD return an HTTP 422 (Unprocessable Entity) [RFC4918] response. That's unless a different response code fits better based on the server's policy settings. The 422 says "search is supported, but this particular query can't be processed," which is iconic honestly. When a server sends a 422, it MAY also include an error response body as specified in Section 6 of [RFC9083], but only if the requested media type is one specified in [RFC7480].

Partial matching across combinations of Unicode characters is not feasible, because Unicode characters can combine with each other. Servers SHOULD NOT partially match combinations of Unicode characters wherever a legal combination is possible. Here's the tea though: it may not always be possible to spot a case where a character could have been combined with another one but wasn't, since characters can combine in lots of different ways 😭

Clients SHOULD NOT submit a partial match search of Unicode characters where a character may legally combine with another character or characters. Partial match searches with incomplete combinations (where a character has to be combined with something but isn't) are invalid, period. And characters that can combine but aren't combined in the search string get treated as complete, non-combined characters. So if character x can combine with character y but y isn't in the search string, then x is a complete character and none of its combinations get searched 🌸

4.2. Associated Records 🌸

Conceptually, any query-matching record in a server's database might belong to a set of related records. The server decides how they're related, like variants of an IDN. The whole set ought to be considered as candidates when building the response. Still, the final response has to be mindful of privacy and other data-releasing policies when the RDAP response set gets assembled 🔒

Also, a search can match a whole list of records, and each one of those could be a member of its own set, as described above. Whatever ends up in the response is the union of all those sets, filtered by whatever policies are in place. Main character energy, but make it policy-compliant 💖

This model covers associated names too, including names linked together by policy mechanisms and names bound together for other purposes. Heads up though: returning information that an exact-match lookup didn't explicitly select, like extra names from a fuzzy search or lists of linked names, may cause privacy issues. Not cute 🙈

There also might not be a single, static information return policy that applies to every client equally. Client identity and associated authorizations can be a big factor in how broad the response set is for any particular query 👑

5. Extensibility 🧚

This document only describes path segment specifications for a limited number of objects commonly registered in both RIRs and DNRs. It does not try to cover path segments for every object registered in every registry, because that would be a whole mood. If you need a custom path segment for an object that isn't specified here, you can create one using the process described in Section 6 of "HTTP Usage in the Registration Data Access Protocol (RDAP)" [RFC7480] ✨

Custom path segments are made by prefixing the segment with a unique identifier followed by an underscore character (0x5F). For example, a custom entity path segment could be made by prefixing "entity" with "custom_", giving you custom_entity. Cute, right? Servers MUST return an appropriate failure status code for a request with an unrecognized path segment. No ghosting, servers, respond properly 💀

6. Internationalization Considerations 🌈

There's real value in letting people submit either a U-label (the Unicode form of an IDN label) or an A-label (the US-ASCII form of an IDN label) as a query argument to an RDAP service. Clients that can handle non-US-ASCII characters might prefer U-labels, since they're more visually recognizable and familiar than A-label strings. Clients using programmatic interfaces might find A-labels easier to submit and display, especially if their keyboard setup can't type U-labels. Both query forms are acceptable, so everyone gets to be iconic 🌍

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)" [RFC9083]. Non-negotiable, bestie 💅

6.1. Character Encoding Considerations 💜

Servers can expect to receive search patterns from clients containing character strings encoded in the different forms that HTTP supports. It's totally possible to apply filters and normalization rules to search patterns before making character comparisons. Still, that kind of processing is more typically needed to figure out whether registered strings are valid than to match patterns 🧐

An RDAP client submitting a query string with non-US-ASCII characters converts it into Unicode in UTF-8 encoding. Then it does any local case mapping it thinks is necessary. Strings get normalized using Normalization Form C (NFC) [Unicode-UAX15], though clients might not be able to do this reliably, so be careful 😬 After that, the UTF-8 encoded strings get 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 isn't valid UTF-8, the server can immediately stop processing the query and return an HTTP 400 (Bad Request) response. Rude input, rude output 🙃

Handling is different for DNS names, including ones with putative U-labels, versus everything else. DNS names follow the DNS matching rules described in Section 3.1 of RFC 1035 [RFC1035] for Non-Reserved LDH (NR-LDH) labels. For U-labels, they follow the matching rules described in Section 5.4 of RFC 5891 [RFC5891]. Matching of DNS names happens one label at a time, because a single domain or host name can have a mix of U-labels and NR-LDH labels. Whether a label counts as a U-label or an NR-LDH label depends on whether it 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 being looked up or searched. Each string gets normalized using the same normalization that was used on the target data. In general, storing strings as Unicode is RECOMMENDED 🌸 For comparison purposes, 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 here instead of NFC, because it's a different vibe for a different job 💖

7. IANA Considerations 🎀

This document has no IANA actions. Quiet and chill 😌

8. Security Considerations 🔥

Security services for the operations in this document are described in "Security Services for the Registration Data Access Protocol (RDAP)" [RFC7481]. Read that one too, it's important 🔐

Search functionality typically takes more server resources (like memory, CPU cycles, and network bandwidth) than basic lookup does. This raises the risk of server resource exhaustion and the denial of service that can follow from 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 control the rate of incoming search requests. Server operators can further reduce their risk by limiting how much information gets returned in response to a search request. Protect your server like it's your main ✨

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 don't explicitly match a client-provided search pattern can disclose information about registered domain names that wouldn't otherwise be available. Implementers need to think about the policy and privacy implications of returning information that wasn't explicitly requested 🕵️‍♀️

Again, there might not be a single, static information return policy that applies to every client equally. Client identity and associated authorizations can be a big factor in how broad the response set is for any particular query 👑

9. References 📚

9.1. Normative References

9.2. Informative References

Appendix A. Changes from RFC 7482 🦋

Okay bestie, this is the glow-up log! ✨ Here's everything that changed from RFC 7482.

  • Addressed known errata. 🩹
  • Addressed other reported clarifications and corrections: IDN, IDNA, and DNR definitions. Noted that registrars are entities. Added a reference to RFC 8521 to address the bootstrap registry limitation. Removed extraneous "...". Clarified HTTP query string, search pattern, name server search, domain label suffix, and asterisk search. 🧹
  • Addressed "The HTTP query string" clarification. 💭
  • Modified coauthor address. 📬
  • Updated references to RFC 7483 to RFC 9083. 🔄
  • Added an IANA Considerations section. Changed references to use HTTPS for targets. 🔒
  • Changed "XXXX is a search pattern representing the "FN" property of an entity (such as a contact, registrant, or registrar) name as specified in Section 5.1" to "Changed "XXXX is a search pattern representing the "fn" property of an entity (such as a contact, registrant, or registrar) name as described in Section 5.1". 🎀
  • Added acknowledgments. 🫶
  • Changed "The intent of the patterns described here are to enable queries" to "The intent of the patterns described here is to enable queries". 🌸
  • Changed "the corresponding syntax extension in RFC 6874 [RFC6874] MUST NOT be used, and servers are to ignore it if possible" to "the corresponding syntax extension in RFC 6874 [RFC6874] MUST NOT be used, and servers SHOULD ignore it". 🙅‍♀️
  • Changed "Only a single asterisk is allowed for a partial string search" to "A partial string search MUST NOT include more than one asterisk". ⭐
  • Changed "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" to "Clients SHOULD NOT submit a partial match search of Unicode characters where a Unicode character may be legally combined with another Unicode character or characters". 💅
  • Changed description of nameserver IP address "search pattern" in Sections 3.2.1 and 3.2.2. 🧚
  • IESG review feedback: Added "obsoletes 7482" to the headers, Abstract, and Introduction. Changed "IETF standards" to "IETF specifications" and "Therefore" to "Accordingly" in Section 1. Updated the BCP 14 boilerplate. Added definition of "bootstrap registry" and changed "concatenating ... to" to "concatenating ... with" in Section 3. Changed "bitmask length" to "prefix length" and "2001:db8::0" to "2001:db8::" in Section 3.1.1. Added "in contrast to the more generic HTTP query string that admits multiple simultaneous parameters" in Section 3.2. Changed "0x002A" to "0x2A" in Section 4.1. Clarified use of HTTP 422 SHOULD in Section 4.1. 👑

Acknowledgments 🌈

This document is derived from original work on RIR query formats developed by Byron J. Ellacott of APNIC, Arturo L. Servin of LACNIC, Kaveh Ranjbar of the RIPE NCC, and Andrew L. Newton of ARIN. Additionally, this document incorporates DNR query formats originally described by Francisco Arias and Steve Sheng of ICANN and Scott Hollenbeck of Verisign Labs.

The authors would like to acknowledge the following individuals for their contributions to this document: Francisco Arias, Marc Blanchet, Ernie Dainow, Jean-Philippe Dionne, Byron J. Ellacott, Behnam Esfahbod, John Klensin, John Levine, Edward Lewis, Mario Loffredo, Patrick Mevzek, Mark Nottingham, Kaveh Ranjbar, Arturo L. Servin, Steve Sheng, Jasdip Singh, and Andrew Sullivan. 🫶💖

Authors' Addresses 💌

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

Email: shollenbeck@verisign.com
URI:   https://www.verisignlabs.com/


Andy Newton
Amazon Web Services, Inc.
13200 Woodland Park Road
Herndon, VA 20171
United States of America

Email: andy@hxr.us
📦 where this page comes from