diff options
Diffstat (limited to 'doc/rfc/rfc9082.txt')
| -rw-r--r-- | doc/rfc/rfc9082.txt | 1010 |
1 files changed, 1010 insertions, 0 deletions
diff --git a/doc/rfc/rfc9082.txt b/doc/rfc/rfc9082.txt new file mode 100644 index 0000000..94cc8f9 --- /dev/null +++ b/doc/rfc/rfc9082.txt @@ -0,0 +1,1010 @@ + + + + +Internet Engineering Task Force (IETF) S. Hollenbeck +Request for Comments: 9082 Verisign Labs +STD: 95 A. Newton +Obsoletes: 7482 AWS +Category: Standards Track June 2021 +ISSN: 2070-1721 + + + Registration Data Access Protocol (RDAP) Query Format + +Abstract + + This document describes uniform patterns to construct HTTP URLs that + may be used to retrieve registration information from registries + (including both Regional Internet Registries (RIRs) and Domain Name + Registries (DNRs)) using "RESTful" web access patterns. These + uniform patterns define the query syntax for the Registration Data + Access Protocol (RDAP). This document obsoletes RFC 7482. + +Status of This Memo + + This 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. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9082. + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided 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 + + This document describes a specification for querying registration + data using a RESTful web service and uniform query patterns. The + service is implemented using the Hypertext Transfer Protocol (HTTP) + [RFC7230] and the conventions described in [RFC7480]. These uniform + patterns define the query syntax for the Registration Data Access + Protocol (RDAP). This document obsoletes RFC 7482. + + The protocol described in this specification is intended to address + deficiencies with the WHOIS protocol [RFC3912] that have been + identified over time, including: + + * 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 described in this document purposefully do not encompass + all of the methods employed in the WHOIS and other RESTful web + services used by the RIRs and DNRs. The intent of the patterns + described here 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. + + Server implementations 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 inform clients of + unsupported query types. It is also envisioned that each registry + will continue to maintain WHOIS and/or other RESTful web services + specific to their needs and those of their constituencies, and the + information retrieved through the patterns described here may + reference such services. + + Likewise, future IETF specifications may add additional patterns for + additional query types. A simple pattern namespacing scheme is + described in Section 5 to accommodate custom extensions that will not + interfere with the patterns defined in this document or patterns + defined in future IETF specifications. + + WHOIS services, in general, are read-only services. Accordingly, URL + [RFC3986] patterns specified in this document are only applicable to + the HTTP [RFC7231] GET and HEAD methods. + + This document does not describe the results or entities returned from + issuing the described URLs with an HTTP GET. The specification of + these entities is described in [RFC9083]. + + Additionally, resource management, provisioning, and update functions + are out of scope for this document. Registries have various and + divergent methods covering these functions, and it is unlikely a + uniform approach is needed for interoperability. + + HTTP contains mechanisms for servers to authenticate clients and for + clients to authenticate servers (from which authorization schemes may + be built), so such mechanisms are not described in this document. + Policy, provisioning, and processing of authentication and + authorization are out of scope for this document as deployments will + have to make choices 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 construct RDAP queries are maintained in an + IANA registry (the "bootstrap registry") described in [RFC7484]. + Queries are formed by retrieving an appropriate base URL from the + registry and appending a path segment specified in either Sections + 3.1 or 3.2. Generally, a registry or other service provider will + provide a base URL that identifies the protocol, host, and port, and + this will be used as a base URL that the complete URL is resolved + against, as per Section 5 of RFC 3986 [RFC3986]. For example, if the + base URL is "https://example.com/rdap/", all RDAP query URLs will + begin with "https://example.com/rdap/". + + The bootstrap registry does not contain information for query objects + that are not part of a global namespace, including entities and help. + A base URL for an associated object is required to construct a + complete query. This limitation can be overcome for entities by + using the practice described in RFC 8521 [RFC8521]. + + For entities, a base URL is retrieved for the service (domain, + address, etc.) associated with a given entity. The query URL is + constructed by concatenating the base URL with the entity path + segment specified in either Sections 3.1.5 or 3.2.3. + + For help, a base URL is retrieved for any service (domain, address, + etc.) for which additional information is required. The query URL is + constructed by concatenating the base URL with the help path segment + specified in Section 3.1.6. + +3.1. Lookup Path Segment Specification + + A simple lookup to determine if an object exists (or not) without + returning RDAP-encoded results can be performed 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> + + Queries for information about IP networks are of the form /ip/XXX or + /ip/XXX/YY where the path segment following 'ip' is either an IPv4 + dotted decimal or IPv6 [RFC5952] address (i.e., XXX) or an IPv4 or + IPv6 Classless Inter-domain Routing (CIDR) [RFC4632] notation address + block (i.e., XXX/YY). Semantically, the simpler form using the + address can be thought of as a CIDR block with a prefix length of 32 + for IPv4 and a prefix length of 128 for IPv6. A given specific + address or CIDR may fall within multiple IP networks in a hierarchy + of networks; therefore, this query targets the "most-specific" or + smallest IP network that completely encompasses it in a hierarchy of + IP networks. + + The IPv4 and IPv6 address formats supported in this query are + described in Section 3.2.2 of RFC 3986 [RFC3986] as IPv4address and + IPv6address ABNF definitions. Any valid IPv6 text address format + [RFC4291] can be used. This includes IPv6 addresses written using + with or without compressed zeros and IPv6 addresses containing + embedded IPv4 addresses. The rules to write a text representation of + an IPv6 address [RFC5952] are RECOMMENDED. However, the zone_id + [RFC4007] is not appropriate in this context; therefore, the + corresponding syntax extension in RFC 6874 [RFC6874] MUST NOT be + used, and servers SHOULD ignore it. + + For example, the following URL would be used to find information for + the most specific network containing 192.0.2.0: + + https://example.com/rdap/ip/192.0.2.0 + + The following URL would be used to find information for the most + specific network containing 192.0.2.0/24: + + https://example.com/rdap/ip/192.0.2.0/24 + + The following URL would be used to find information for the most + specific network containing 2001:db8:: + + https://example.com/rdap/ip/2001:db8:: + +3.1.2. Autonomous System Path Segment Specification + + Syntax: autnum/<autonomous system number> + + Queries for information regarding Autonomous System number + registrations are of the form /autnum/XXX where XXX is an asplain + Autonomous System number [RFC5396]. In some registries, registration + of Autonomous System numbers is done on an individual number basis, + while other registries may register blocks of Autonomous System + numbers. The semantics of this query are such that if a number falls + within a range of registered blocks, the target of the query is the + block registration and that individual number registrations are + considered a block of numbers with a size of 1. + + For example, the following URL would be used to find information + describing Autonomous System number 12 (a number within a range of + registered blocks): + + https://example.com/rdap/autnum/12 + + The following URL would be used to find information describing 4-byte + Autonomous System number 65538: + + https://example.com/rdap/autnum/65538 + +3.1.3. Domain Path Segment Specification + + Syntax: domain/<domain name> + + Queries for domain information are of the form /domain/XXXX, where + XXXX is a fully qualified (relative to the root) domain name (as + specified in [RFC0952] and [RFC1123]) in either the in-addr.arpa or + ip6.arpa zones (for RIRs) or a fully qualified domain name in a zone + administered by the server operator (for DNRs). Internationalized + Domain Names (IDNs) represented in either A-label or U-label format + [RFC5890] are also valid domain names. See Section 6.1 for + information on character encoding for the U-label format. + + IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; + that is, internationalized labels in an IDN SHOULD be either all + A-labels or all U-labels. It is possible for an RDAP client to + assemble a query string from multiple independent data sources. Such + a client might not be able to perform conversions between A-labels + and U-labels. An RDAP server that receives a query string with a + mixture of A-labels and U-labels MAY convert all the U-labels to + A-labels, perform IDNA processing, and proceed with exact-match + lookup. In such cases, the response to be returned to the query + source may not match the input from the query source. Alternatively, + the server MAY refuse to process the query. + + The server MAY perform the match using either the A-label or U-label + form. Using one consistent form for matching every label is likely + to be more reliable. + + The following URL would be used to find information describing the + zone serving the network 192.0.2/24: + + https://example.com/rdap/domain/2.0.192.in-addr.arpa + + The following URL would be used to find information 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 + + The following URL would be used to find information for the + blah.example.com domain name: + + https://example.com/rdap/domain/blah.example.com + + The following URL would be used to find information 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 represents a fully qualified host + name as specified in [RFC0952] and [RFC1123]. Internationalized + names represented in either A-label or U-label format [RFC5890] are + also valid nameserver names. IDN processing for nameserver names + uses the domain name processing instructions specified in + Section 3.1.3. See Section 6.1 for information on character encoding + for the U-label format. + + The following URL would be used to find information for the + ns1.example.com nameserver: + + https://example.com/rdap/nameserver/ns1.example.com + + The following URL would be used to find information 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 represents an entity (such as a contact, + registrant, or registrar) identifier whose syntax is specific to the + registration provider. For example, for some DNRs, contact + identifiers are specified in [RFC5730] and [RFC5733]. + + The following URL would be used to find information 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 can be used to request helpful information + (command syntax, terms of service, privacy policy, rate-limiting + policy, supported authentication methods, supported extensions, + technical support contact, etc.) from an RDAP server. The response + to "help" should provide basic information that a client needs to + successfully use the service. The following URL would be used to + return "help" information: + + 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 identify a domain name information search using a + pattern to match a fully qualified domain name. + + 'nameservers': Used to identify a nameserver information search + using a pattern to match a host name. + + 'entities': Used to identify an entity information search using a + pattern to match a string identifier. + + RDAP search path segments are formed using a concatenation of the + plural form of the object being searched for and an HTTP query + string. The HTTP query string is formed using a concatenation of the + question mark character ('?', US-ASCII value 0x003F), a noun + representing the JSON object property associated with the object + being searched for, the equal sign character ('=', US-ASCII value + 0x003D), and the search pattern (this is in contrast to the more + generic HTTP query string that allows multiple simultaneous + parameters). Search pattern query processing is described more fully + in Section 4. For the domain, nameserver, and entity objects + described in this document, the plural object forms are "domains", + "nameservers", and "entities". + + Detailed results can be retrieved using the HTTP GET method and the + path segments specified here. + +3.2.1. Domain Search + + Syntax: domains?name=<domain search pattern> + + Syntax: domains?nsLdhName=<nameserver search pattern> + + Syntax: domains?nsIp=<nameserver IP address> + + Searches for domain information by name are specified using this + form: + + domains?name=XXXX + + XXXX is a search pattern representing a domain name in "letters, + digits, hyphen" (LDH) format [RFC5890]. The following URL would be + used to find DNR information for domain names matching the + "example*.com" pattern: + + https://example.com/rdap/domains?name=example*.com + + IDNs in U-label format [RFC5890] can also be used as search patterns + (see Section 4). Searches for these names are of the form + /domains?name=XXXX, where XXXX is a search pattern representing a + domain name in U-label format [RFC5890]. See Section 6.1 for + information on character encoding for the U-label format. + + Searches for domain information by nameserver name are specified + using this form: + + domains?nsLdhName=YYYY + + YYYY is a search pattern representing a host name in "letters, + digits, hyphen" format [RFC5890]. The following URL would be used to + search for domains delegated to nameservers matching the + "ns1.example*.com" pattern: + + https://example.com/rdap/domains?nsLdhName=ns1.example*.com + + Searches for domain information by nameserver IP address are + specified using this form: + + domains?nsIp=ZZZZ + + ZZZZ is an IPv4 [RFC1166] or IPv6 [RFC5952] address. The following + URL would be used to search for domains that have been delegated to + nameservers that resolve to the "192.0.2.0" address: + + https://example.com/rdap/domains?nsIp=192.0.2.0 + +3.2.2. Nameserver Search + + Syntax: nameservers?name=<nameserver search pattern> + + Syntax: nameservers?ip=<nameserver IP address> + + Searches for nameserver information by nameserver name are specified + using this form: + + nameservers?name=XXXX + + XXXX is a search pattern representing a host name in "letters, + digits, hyphen" format [RFC5890]. The following URL would be used to + find information 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 + also be used as search patterns (see Section 4). Searches for these + names are of the form /nameservers?name=XXXX, where XXXX is a search + pattern representing a nameserver name in U-label format [RFC5890]. + See Section 6.1 for information on character encoding for the U-label + format. + + Searches for nameserver information by nameserver IP address are + specified using this form: + + nameservers?ip=YYYY + + YYYY is an IPv4 [RFC1166] or IPv6 [RFC5952] address. The following + URL would be used to search for nameserver names that resolve to the + "192.0.2.0" address: + + https://example.com/rdap/nameservers?ip=192.0.2.0 + +3.2.3. Entity Search + + Syntax: entities?fn=<entity name search pattern> + + Syntax: entities?handle=<entity handle search pattern> + + Searches for entity information by name are specified using this + form: + + entities?fn=XXXX + + 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 of [RFC9083]. The following URL would be used to find + information for entity names matching the "Bobby Joe*" pattern: + + https://example.com/rdap/entities?fn=Bobby%20Joe* + + Searches for entity information by handle are specified using this + form: + + entities?handle=XXXX + + XXXX is a search pattern representing an entity (such as a contact, + registrant, or registrar) identifier whose syntax is specific to the + registration provider. The following URL would be used to find + information 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*" is encoded to "Bobby%20Joe*". + +4. Query Processing + + Servers indicate the success or failure of query processing by + returning an appropriate HTTP response code to the client. Response + codes not specifically identified in this document are described in + [RFC7480]. + +4.1. Partial String Searching + + Partial string searching uses the asterisk ('*', US-ASCII value 0x2A) + character to match zero or more trailing characters. A character + string representing a domain label suffix MAY be concatenated to 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 appears in a search string, any label + that contains the non-asterisk characters in sequence plus zero or + more characters in sequence in place of the asterisk would match. A + partial string search MUST NOT include more than one asterisk. + Additional pattern matching processing is beyond the scope of this + specification. + + If a server receives a search request but cannot process the request + because it does not support a particular style of partial match + searching, it SHOULD return an HTTP 422 (Unprocessable Entity) + [RFC4918] response (unless another response code is more appropriate + based on a server's policy settings) to note that search + functionality is supported, but this particular query cannot be + processed. When returning a 422 error, the server MAY also return an + error response body as specified in Section 6 of [RFC9083] 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 was not, because characters can be combined in many different + ways. + + 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. 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 + (that is, 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 due to the nature of searching, 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 + that has been filtered by whatever policies are in place. + + Note that this model includes arrangements for associated names, + including those that are linked by policy mechanisms and names bound + together for some other purposes. Note also that returning + information that was not 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. + + 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. + +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 capable of + processing non-US-ASCII characters may prefer a U-label since this is + more visually recognizable and familiar than A-label strings, but + clients using programmatic interfaces might find it easier to submit + and display A-labels if they are unable to 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)" [RFC9083]. + +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 prior to 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 such strings into Unicode in UTF-8 encoding. It + then performs any local case mapping deemed necessary. Strings are + normalized using Normalization Form C (NFC) [Unicode-UAX15]; 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, there is a difference in handling DNS names, + including those with putative U-labels, and everything else. DNS + names are treated according to the DNS matching rules as 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 it is possible for a combination of U-labels and NR- + LDH labels to be found in a single domain or host name. The + determination of 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 of 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, storage + of 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. IANA Considerations + + This document has no IANA actions. + +8. Security Considerations + + 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) when compared to basic + lookup functionality. 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 to 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. + +9. References + +9.1. Normative References + + [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet + host table specification", RFC 952, DOI 10.17487/RFC0952, + October 1985, <https://www.rfc-editor.org/info/rfc952>. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, <https://www.rfc-editor.org/info/rfc1035>. + + [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, + DOI 10.17487/RFC1123, October 1989, + <https://www.rfc-editor.org/info/rfc1123>. + + [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet + numbers", RFC 1166, DOI 10.17487/RFC1166, July 1990, + <https://www.rfc-editor.org/info/rfc1166>. + + [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>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <https://www.rfc-editor.org/info/rfc3986>. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, <https://www.rfc-editor.org/info/rfc4291>. + + [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing + (CIDR): The Internet Address Assignment and Aggregation + Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August + 2006, <https://www.rfc-editor.org/info/rfc4632>. + + [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed + Authoring and Versioning (WebDAV)", RFC 4918, + DOI 10.17487/RFC4918, June 2007, + <https://www.rfc-editor.org/info/rfc4918>. + + [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of + Autonomous System (AS) Numbers", RFC 5396, + DOI 10.17487/RFC5396, December 2008, + <https://www.rfc-editor.org/info/rfc5396>. + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, + <https://www.rfc-editor.org/info/rfc5730>. + + [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, + August 2009, <https://www.rfc-editor.org/info/rfc5733>. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, DOI 10.17487/RFC5890, August 2010, + <https://www.rfc-editor.org/info/rfc5890>. + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + DOI 10.17487/RFC5891, August 2010, + <https://www.rfc-editor.org/info/rfc5891>. + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, + DOI 10.17487/RFC5952, August 2010, + <https://www.rfc-editor.org/info/rfc5952>. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + <https://www.rfc-editor.org/info/rfc7230>. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, + <https://www.rfc-editor.org/info/rfc7231>. + + [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>. + + [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>. + + [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data + (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March + 2015, <https://www.rfc-editor.org/info/rfc7484>. + + [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>. + + [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, + January 2019, <https://www.rfc-editor.org/info/rfc8499>. + + [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>. + + [Unicode-UAX15] + The Unicode Consortium, "Unicode Standard Annex #15: + Unicode Normalization Forms", September 2013, + <https://www.unicode.org/reports/tr15/>. + +9.2. Informative References + + [REST] Fielding, R., "Architectural Styles and the Design of + Network-based Software Architectures", Ph.D. + Dissertation, University of California, Irvine, 2000, + <https://www.ics.uci.edu/~fielding/pubs/dissertation/ + fielding_dissertation.pdf>. + + [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, + DOI 10.17487/RFC3912, September 2004, + <https://www.rfc-editor.org/info/rfc3912>. + + [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and + B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, + DOI 10.17487/RFC4007, March 2005, + <https://www.rfc-editor.org/info/rfc4007>. + + [RFC4290] Klensin, J., "Suggested Practices for Registration of + Internationalized Domain Names (IDN)", RFC 4290, + DOI 10.17487/RFC4290, December 2005, + <https://www.rfc-editor.org/info/rfc4290>. + + [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing + IPv6 Zone Identifiers in Address Literals and Uniform + Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, + February 2013, <https://www.rfc-editor.org/info/rfc6874>. + + [RFC6927] Levine, J. and P. Hoffman, "Variants in Second-Level Names + Registered in Top-Level Domains", RFC 6927, + DOI 10.17487/RFC6927, May 2013, + <https://www.rfc-editor.org/info/rfc6927>. + + [RFC8521] Hollenbeck, S. and A. Newton, "Registration Data Access + Protocol (RDAP) Object Tagging", BCP 221, RFC 8521, + DOI 10.17487/RFC8521, November 2018, + <https://www.rfc-editor.org/info/rfc8521>. + +Appendix A. Changes 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 |