[要約] RFC 7482は、RDAPクエリフォーマットに関する規格であり、RDAPサーバーへのデータアクセスを標準化しています。目的は、効率的なデータ検索とクエリ応答の一貫性を確保することです。
Internet Engineering Task Force (IETF) A. Newton
Request for Comments: 7482 ARIN
Category: Standards Track S. Hollenbeck
ISSN: 2070-1721 Verisign Labs
March 2015
Registration Data Access Protocol (RDAP) Query Format
登録データアクセスプロトコル（RDAP）クエリ形式
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).
このドキュメントでは、「RESTful」Webアクセスパターンを使用してレジストリ（地域インターネットレジストリ（RIR）とドメイン名レジストリ（DNR）の両方を含む）から登録情報を取得するために使用できるHTTP URLを構築するための統一パターンについて説明します。これらの統一パターンは、Registration Data Access Protocol（RDAP）のクエリ構文を定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7482.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7482で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
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).
このドキュメントでは、RESTful Webサービスと統一クエリパターンを使用して登録データをクエリするための仕様について説明します。このサービスは、ハイパーテキスト転送プロトコル（HTTP）[RFC7230]と[RFC7480]で説明されている規則を使用して実装されます。これらの統一パターンは、Registration Data Access Protocol（RDAP）のクエリ構文を定義します。
The protocol described in this specification is intended to address deficiencies with the WHOIS protocol [RFC3912] that have been identified over time, including:
この仕様で説明されているプロトコルは、次のようなWHOISプロトコル[RFC3912]の不備に対処することを目的としています。
o lack of standardized command structures;
o 標準化されたコマンド構造の欠如;
o lack of standardized output and error structures;
o 標準化された出力とエラー構造の欠如;
o lack of support for internationalization and localization; and o lack of support for user identification, authentication, and access control.
o国際化とローカリゼーションに対するサポートの欠如。 oユーザーの識別、認証、およびアクセス制御のサポートの欠如。
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 are to enable queries of:
このドキュメントで説明されているパターンは、RIRとDNRが使用するWHOISおよびその他のRESTful Webサービスで採用されているすべての方法を意図的に網羅しているわけではありません。ここで説明するパターンの目的は、次のクエリを有効にすることです。
o networks by IP address;
o IPアドレスによるネットワーク。
o Autonomous System (AS) numbers by number;
o 自律システム（AS）番号。
o reverse DNS metadata by domain;
o ドメインごとにDNSメタデータを逆にします。
o nameservers by name;
o 名前によるネームサーバー。
o registrars by name; and
o 名前による登録機関;そして
o entities (such as contacts) by identifier.
o 識別子によるエンティティ（連絡先など）。
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.
サーバーの実装は、ローカルの要件に応じて、これらの機能のサブセットのみを無料でサポートします。サーバーは、サポートされていないクエリタイプをクライアントに通知するために、HTTP 501（未実装）[RFC7231]応答を返さなければなりません（MUST）。また、各レジストリがWHOISやその他のRESTful Webサービスを彼らのニーズとその支持者のニーズに固有に維持し続けることも想定されており、ここで説明するパターンを通じて取得される情報は、そのようなサービスを参照する場合があります。
Likewise, future IETF standards 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 standards.
同様に、将来のIETF標準では、クエリタイプのパターンが追加される可能性があります。このドキュメントで定義されているパターンや将来のIETF標準で定義されているパターンに干渉しないカスタム拡張機能に対応するため、セクション5で簡単なパターン名前空間スキームについて説明します。
WHOIS services, in general, are read-only services. Therefore, URL [RFC3986] patterns specified in this document are only applicable to the HTTP [RFC7231] GET and HEAD methods.
一般に、WHOISサービスは読み取り専用サービスです。したがって、このドキュメントで指定されているURL [RFC3986]パターンは、HTTP [RFC7231] GETおよびHEADメソッドにのみ適用できます。
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 [RFC7483].
このドキュメントでは、説明されているURLをHTTP GETで発行した結果またはエンティティについては説明していません。これらのエンティティの仕様は[RFC7483]で説明されています。
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].
HTTPには、サーバーがクライアントを認証するためのメカニズムと、クライアントがサーバーを認証するためのメカニズム（認証スキームを構築できる）が含まれているため、このドキュメントではこのようなメカニズムについては説明しません。デプロイメントではローカルの基準に基づいて選択を行う必要があるため、認証と承認のポリシー、プロビジョニング、および処理はこのドキュメントの範囲外です。サポートされている認証メカニズムは、[RFC7481]で説明されています。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
IDN: Internationalized Domain Name
IDN：国際化ドメイン名
IDNA: Internationalized Domain Names in Applications, a protocol for the handling of IDNs.
IDNA：アプリケーションの国際化ドメイン名。IDNを処理するためのプロトコル。
DNR: Domain Name Registry
DNR：ドメイン名レジストリ
NFC: Unicode Normalization Form C [Unicode-UAX15]
NFC：Unicode正規化フォームC [Unicode-UAX15]
NFKC: Unicode Normalization Form KC [Unicode-UAX15]
NFKC：Unicode正規化形式KC [Unicode-UAX15]
RDAP: Registration Data Access Protocol
RDAP：Registration Data Access Protocol
REST: Representational State Transfer. The term was first described in a doctoral dissertation [REST].
REST：表現状態転送。この用語は、博士論文[REST]で最初に説明されました。
RESTful: An adjective that describes a service using HTTP and the principles of REST.
RESTful：HTTPを使用したサービスとRESTの原則を説明する形容詞。
RIR: Regional Internet Registry
RIR：地域インターネットレジストリ
The base URLs used to construct RDAP queries are maintained in an IANA 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
RDAPクエリの構築に使用されるベースURLは、[RFC7484]で説明されているIANAレジストリで維持されます。クエリは、レジストリから適切なベースURLを取得し、セクション3.1または3.2で指定されたパスセグメントを追加することによって形成されます。通常、レジストリまたはその他のサービスプロバイダーは、プロトコル、ホスト、ポートを識別するベースURLを提供し、セクション5に従って完全なURLが解決されるベースURLとして使用されます
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/".
RFC 3986 [RFC3986]の。たとえば、ベースURLが「https://example.com/rdap/」の場合、すべてのRDAPクエリURLは「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.
ブートストラップレジストリには、エンティティやヘルプなど、グローバル名前空間の一部ではないクエリオブジェクトの情報は含まれていません。完全なクエリを作成するには、関連付けられたオブジェクトのベースURLが必要です。
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 to the entity path segment specified in either Sections 3.1.5 or 3.2.3.
エンティティの場合、特定のエンティティに関連付けられているサービス（ドメイン、アドレスなど）のベースURLが取得されます。クエリURLは、ベースURLをセクション3.1.5または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 to the help path segment specified in Section 3.1.6.
ヘルプのために、追加情報が必要なサービス（ドメイン、アドレスなど）のベースURLが取得されます。クエリURLは、ベースURLをセクション3.1.6で指定されたヘルプパスセグメントに連結することによって構築されます。
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].
[RFC7480]のセクション4.1で説明されているように、RDAPでエンコードされた結果を返さずにオブジェクトが存在するかどうかを判断する簡単な検索は、HTTP HEADメソッドを使用して実行できます。
The resource type path segments for exact match lookup are:
完全一致検索のリソースタイプパスセグメントは次のとおりです。
o 'ip': Used to identify IP networks and associated data referenced using either an IPv4 or IPv6 address.
o 'ip'：IPv4またはIPv6アドレスのいずれかを使用して参照されるIPネットワークおよび関連データを識別するために使用されます。
o 'autnum': Used to identify Autonomous System number registrations and associated data referenced using an asplain Autonomous System number.
o 'autnum'：asplain自律システム番号を使用して参照される自律システム番号登録および関連データを識別するために使用されます。
o 'domain': Used to identify reverse DNS (RIR) or domain name (DNR) information and associated data referenced using a fully qualified domain name.
o 「ドメイン」：完全修飾ドメイン名を使用して参照される逆引きDNS（RIR）またはドメイン名（DNR）情報および関連データを識別するために使用されます。
o 'nameserver': Used to identify a nameserver information query using a host name.
o 'nameserver'：ホスト名を使用してネームサーバー情報クエリを識別するために使用されます。
o 'entity': Used to identify an entity information query using a string identifier.
o 'entity'：文字列識別子を使用してエンティティ情報クエリを識別するために使用されます。
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 bitmask length of 32 for IPv4 and a bitmask 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.
IPネットワークに関する情報のクエリは、/ ip / XXX / ...または/ ip / XXX / YY / ...の形式です。ここで、「ip」に続くパスセグメントは、IPv4ドット付き10進数またはIPv6 [RFC5952]アドレス（つまり、XXX）またはIPv4またはIPv6クラスレスドメイン間ルーティング（CIDR）[RFC4632]表記アドレスブロック（つまり、XXX / YY）。意味的には、アドレスを使用するより簡単な形式は、IPv4の場合は32のビットマスク長、IPv6の場合は128のビットマスク長を持つCIDRブロックと考えることができます。特定の特定のアドレスまたはCIDRが、ネットワークの階層内の複数のIPネットワークに含まれる場合があります。したがって、このクエリは、IPネットワークの階層にそれを完全に包含する「最も具体的な」または最小のIPネットワークを対象とします。
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 are to ignore it if possible.
このクエリでサポートされているIPv4およびIPv6アドレス形式は、RFC 3986 [RFC3986]のセクション3.2.2でIPv4addressおよびIPv6address ABNF定義として説明されています。任意の有効なIPv6テキストアドレス形式[RFC4291]を使用できます。これには、圧縮されたゼロを使用して、または使用せずに記述されたIPv6アドレスと、埋め込まれたIPv4アドレスを含むIPv6アドレスが含まれます。 IPv6アドレス[RFC5952]のテキスト表現を書くためのルールは推奨されます。ただし、zone_id [RFC4007]はこのコンテキストでは適切ではありません。したがって、RFC 6874 [RFC6874]の対応する構文拡張を使用してはならず（MUST NOT）、サーバーは可能であればそれを無視します。
For example, the following URL would be used to find information for the most specific network containing 192.0.2.0:
たとえば、次のURLは、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:
次のURLは、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::0:
次のURLは、2001：db8 :: 0を含む最も具体的なネットワークの情報を見つけるために使用されます。
https://example.com/rdap/ip/2001:db8::0
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.
自律システム番号の登録に関する情報のクエリは、/ autnum / XXX / ...の形式です。ここで、XXXは単純な自律システム番号[RFC5396]です。一部のレジストリでは、自律システム番号の登録は個別の番号ベースで行われますが、他のレジストリは自律システム番号のブロックを登録する場合があります。このクエリのセマンティクスは、数値が登録されたブロックの範囲内にある場合、クエリのターゲットはブロック登録であり、個々の数値登録はサイズが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):
たとえば、次のURLは、自律システム番号12（登録されたブロックの範囲内の番号）を説明する情報を見つけるために使用されます。
https://example.com/rdap/autnum/12
The following URL would be used to find information describing 4-byte Autonomous System number 65538:
次のURLは、4バイトの自律システム番号65538を説明する情報を見つけるために使用されます。
https://example.com/rdap/autnum/65538
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.
ドメイン情報のクエリは、/ domain / XXXX / ...の形式です。XXXXは、in-addr内の（[RFC0952]および[RFC1123]で指定されている）完全修飾（ルートに対して）ドメイン名です。 arpaまたはip6.arpaゾーン（RIRの場合）、またはサーバーオペレーターが管理するゾーンの完全修飾ドメイン名（DNRの場合）。 AラベルまたはUラベル形式[RFC5890]で表される国際化ドメイン名（IDN）も有効なドメイン名です。 Uラベル形式の文字エンコードについては、セクション6.1を参照してください。
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.
IDNは、AラベルとUラベルの混合として表現してはなりません。つまり、IDNの国際化されたラベルは、すべてAラベルまたはすべてUラベルである必要があります（SHOULD）。 RDAPクライアントは、複数の独立したデータソースからクエリ文字列を組み立てることができます。このようなクライアントは、AラベルとUラベル間の変換を実行できない場合があります。 AラベルとUラベルが混在するクエリ文字列を受信するRDAPサーバーは、すべてのUラベルをAラベルに変換し、IDNA処理を実行して、完全一致ルックアップを続行できます。このような場合、クエリソースに返される応答は、クエリソースからの入力と一致しない場合があります。または、サーバーはクエリの処理を拒否する場合があります。
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.
サーバーは、AラベルまたはUラベル形式のいずれかを使用して、一致を実行することができます。すべてのラベルを一致させるために1つの一貫したフォームを使用すると、信頼性が高くなる可能性があります。
The following URL would be used to find information describing the zone serving the network 192.0.2/24:
次のURLは、ネットワーク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:
次のURLは、ネットワーク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:
次のURLは、blah.example.comドメイン名の情報を見つけるために使用されます。
https://example.com/rdap/domain/blah.example.com
The following URL would be used to find information for the xn--fo-5ja.example IDN:
次のURLは、xn--fo-5ja.example IDNの情報を見つけるために使用されます。
https://example.com/rdap/domain/xn--fo-5ja.example
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.
<nameserver name>パラメータは、[RFC0952]および[RFC1123]で指定されている完全修飾ホスト名を表します。 A-labelまたはU-label形式[RFC5890]で表される国際化された名前も、有効なネームサーバー名です。ネームサーバー名のIDN処理は、セクション3.1.3で指定されたドメイン名処理命令を使用します。 Uラベル形式の文字エンコードについては、セクション6.1を参照してください。
The following URL would be used to find information for the ns1.example.com nameserver:
次のURLは、ns1.example.comネームサーバーの情報を見つけるために使用されます。
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.example.com次のURLは、ns1.xn--fo-5ja.exampleネームサーバーの情報を見つけるために使用されます。
https://example.com/rdap/nameserver/ns1.xn--fo-5ja.example
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].
<handle>パラメーターは、構文が登録プロバイダーに固有のエンティティ（連絡先、登録者、レジストラなど）の識別子を表します。たとえば、一部のDNRでは、連絡先識別子が[RFC5730]と[RFC5733]で指定されています。
The following URL would be used to find information for the entity associated with handle XXXX:
次のURLは、ハンドルXXXXに関連付けられたエンティティの情報を見つけるために使用されます。
https://example.com/rdap/entity/XXXX
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:
ヘルプパスセグメントを使用して、RDAPサーバーから役立つ情報（コマンド構文、利用規約、プライバシーポリシー、レート制限ポリシー、サポートされている認証方法、サポートされている拡張機能、テクニカルサポートの連絡先など）を要求できます。 「ヘルプ」への応答は、クライアントがサービスを正常に使用するために必要な基本情報を提供する必要があります。次のURLは、「ヘルプ」情報を返すために使用されます。
https://example.com/rdap/help
Pattern matching semantics are described in Section 4.1. The resource type path segments for search are:
パターンマッチングのセマンティクスについては、セクション4.1で説明します。検索用のリソースタイプパスセグメントは次のとおりです。
o 'domains': Used to identify a domain name information search using a pattern to match a fully qualified domain name.
o 'domains'：完全修飾ドメイン名に一致するパターンを使用してドメイン名情報検索を識別するために使用されます。
o 'nameservers': Used to identify a nameserver information search using a pattern to match a host name.
o 'nameservers'：ホスト名と一致するパターンを使用してネームサーバー情報検索を識別するために使用されます。
o 'entities': Used to identify an entity information search using a pattern to match a string identifier.
o 'entities'：文字列識別子と一致するパターンを使用してエンティティ情報検索を識別するために使用されます。
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), the JSON object value associated with the object being searched for, the equal sign character ('=', US-ASCII value 0x003D), and the search pattern. 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".
RDAP検索パスセグメントは、検索対象のオブジェクトの複数形とHTTPクエリ文字列の連結を使用して形成されます。 HTTPクエリ文字列は、疑問符文字（ '？'、US-ASCII値0x003F）、検索対象のオブジェクトに関連付けられたJSONオブジェクト値、等号文字（ '='、US-ASCII）の連結を使用して形成されます。値0x003D）、および検索パターン。検索パターンクエリ処理については、セクション4で詳しく説明します。このドキュメントで説明するドメイン、ネームサーバー、エンティティオブジェクトの場合、複数のオブジェクト形式は「ドメイン」、「ネームサーバー」、「エンティティ」です。
Detailed results can be retrieved using the HTTP GET method and the path segments specified here.
詳細な結果は、HTTP GETメソッドとここで指定したパスセグメントを使用して取得できます。
Syntax: domains?name=<domain search pattern>
Syntax: domains?nsLdhName=<domain search pattern>
Syntax: domains?nsIp=<domain search pattern>
Searches for domain information by name are specified using this form:
名前によるドメイン情報の検索は、次のフォームを使用して指定されます。
domains?name=XXXX
ドメイン？名前= XXXX
XXXX is a search pattern representing a domain name in "letters, digits, hyphen" (LDH) format [RFC5890] in a zone administered by the server operator of a DNR. The following URL would be used to find DNR information for domain names matching the "example*.com" pattern:
XXXXは、DNRのサーバーオペレーターによって管理されるゾーンの「文字、数字、ハイフン」（LDH）形式[RFC5890]でドメイン名を表す検索パターンです。次のURLは、「example * .com」パターンに一致するドメイン名のDNR情報を見つけるために使用されます。
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.
Uラベル形式のIDN [RFC5890]も検索パターンとして使用できます（セクション4を参照）。これらの名前の検索は、/ domains？name = XXXXの形式で行われます。XXXXは、Uラベル形式[RFC5890]でドメイン名を表す検索パターンです。 Uラベル形式の文字エンコードについては、セクション6.1を参照してください。
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] in a zone administered by the server operator of a DNR. The following URL would be used to search for domains delegated to nameservers matching the "ns1.example*.com" pattern:
domains？nsLdhName = YYYY YYYYは、DNRのサーバーオペレーターが管理するゾーン内のホスト名を「文字、数字、ハイフン」形式[RFC5890]で表す検索パターンです。次のURLは、「ns1.example * .com」パターンに一致するネームサーバーに委任されたドメインを検索するために使用されます。
https://example.com/rdap/domains?nsLdhName=ns1.example*.com
Searches for domain information by nameserver IP address are specified using this form:
ネームサーバーIPアドレスによるドメイン情報の検索は、次の形式を使用して指定されます。
domains?nsIp=ZZZZ
ドメイン？nsIp = ZZZZ
ZZZZ is a search pattern representing 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:
ZZZZは、IPv4 [RFC1166]またはIPv6 [RFC5952]アドレスを表す検索パターンです。次のURLは、「192.0.2.0」アドレスに解決されるネームサーバーに委任されたドメインを検索するために使用されます。
https://example.com/rdap/domains?nsIp=192.0.2.0
Syntax: nameservers?name=<nameserver search pattern>
Syntax: nameservers?ip=<nameserver search pattern>
Searches for nameserver information by nameserver name are specified using this form:
ネームサーバー名によるネームサーバー情報の検索は、次の形式を使用して指定されます。
nameservers?name=XXXX
ネームサーバー？name = XXXX
XXXX is a search pattern representing a host name in "letters, digits, hyphen" format [RFC5890] in a zone administered by the server operator of a DNR. The following URL would be used to find DNR information for nameserver names matching the "ns1.example*.com" pattern:
XXXXは、DNRのサーバーオペレーターによって管理されるゾーン内のホスト名を「文字、数字、ハイフン」形式[RFC5890]で表す検索パターンです。次のURLは、「ns1.example * .com」パターンに一致するネームサーバー名のDNR情報を見つけるために使用されます。
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.
Uラベル形式の国際化されたネームサーバー名[RFC5890]も検索パターンとして使用できます（セクション4を参照）。これらの名前の検索は、/ nameservers？name = XXXXという形式です。ここで、XXXXは、Uラベル形式[RFC5890]のネームサーバー名を表す検索パターンです。 Uラベル形式の文字エンコードについては、セクション6.1を参照してください。
Searches for nameserver information by nameserver IP address are specified using this form:
ネームサーバーIPアドレスによるネームサーバー情報の検索は、次の形式を使用して指定されます。
nameservers?ip=YYYY
nameservers？ip = YYYY
YYYY is a search pattern representing 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:
YYYYは、IPv4 [RFC1166]またはIPv6 [RFC5952]アドレスを表す検索パターンです。次のURLは、「192.0.2.0」アドレスに解決されるネームサーバー名の検索に使用されます。
https://example.com/rdap/nameservers?ip=192.0.2.0
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
エンティティ？fn = XXXX
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 of [RFC7483]. The following URL would be used to find information for entity names matching the "Bobby Joe*" pattern:
XXXXは、[RFC7483]のセクション5.1で指定されているエンティティ（連絡先、登録者、レジストラなど）の名前の「FN」プロパティを表す検索パターンです。次のURLは、「Bobby Joe *」パターンに一致するエンティティ名の情報を見つけるために使用されます。
https://example.com/rdap/entities?fn=Bobby%20Joe*
Searches for entity information by handle are specified using this form:
ハンドルによるエンティティ情報の検索は、次のフォームを使用して指定されます。
entities?handle=XXXX
エンティティ？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:
XXXXは、登録プロバイダーに固有の構文を持つエンティティ（連絡先、登録者、レジストラなど）の識別子を表す検索パターンです。次のURLは、「CID-40 *」パターンに一致するエンティティハンドルの情報を見つけるために使用されます。
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*".
[RFC3986]の規則に従って、URLを適切にエンコードする必要があります。上記の例では、「Bobby Joe *」は「Bobby％20Joe *」にエンコードされています。
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].
サーバーは、適切なHTTP応答コードをクライアントに返すことにより、クエリ処理の成功または失敗を示します。このドキュメントで具体的に特定されていない応答コードは、[RFC7480]で説明されています。
Partial string searching uses the asterisk ('*', US-ASCII value 0x002A) character to match zero or more trailing characters. A character string representing multiple domain name labels 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. Additional pattern matching processing is beyond the scope of this specification.
部分文字列検索では、アスタリスク（ '*'、US-ASCII値0x002A）文字を使用して、0個以上の末尾の文字と一致させます。複数のドメイン名ラベルを表す文字列を検索パターンの最後に連結して、検索の範囲を制限できます。たとえば、検索パターン「exam *」は「example.com」と「example.net」に一致します。検索パターン「exam * .com」は「example.com」に一致します。検索文字列にアスタリスクが含まれている場合、アスタリスクの代わりにアスタリスク以外の文字が順に含まれ、さらにゼロ個以上の文字が順に含まれているラベルが一致します。追加のパターンマッチング処理は、この仕様の範囲を超えています。
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. 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].
サーバーが検索リクエストを受信したが、特定のスタイルの部分一致検索をサポートしていないためにリクエストを処理できない場合、サーバーはHTTP 422（Unprocessable Entity）[RFC4918]応答を返す必要があります。リクエストされたメディアタイプが[RFC7480]で指定されているタイプの場合、422エラーを返すときに、サーバーは[RFC7483]のセクション6で指定されているエラーレスポンス本文も返す場合があります。
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.
Unicode文字は相互に組み合わせることができるため、Unicode文字の組み合わせ間で部分一致を実行することはできません。サーバーは、正当な組み合わせが可能な場合、Unicode文字の組み合わせを部分的に一致させるべきではありません（SHOULD NOT）。ただし、文字はさまざまな方法で組み合わせることができるため、文字を別の文字と組み合わせることができたはずのケースを常に検出できるとは限らないことに注意してください。
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 (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).
クライアントは、Unicode文字が別のUnicode文字と合法的に結合される可能性があるUnicode文字の部分一致検索を送信しないでください。文字の組み合わせが不完全な部分一致検索では、文字を別の文字と組み合わせる必要があるか、文字が無効です。別の文字と組み合わせることができる文字を使用した部分一致検索は、非組み合わせ文字と見なされます（つまり、文字xは文字yと組み合わせることができるが、文字yが検索文字列で送信されない場合、文字xは完全な文字で、文字xの組み合わせは検索されません）。
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.
概念的には、サーバーのデータベース内のクエリ照合レコードは、IDNのバリアントなど、サーバーによって定義された方法で関連付けられた一連の関連レコードのメンバーである可能性があります。セット全体は、応答を構築する際に含める候補として考慮されるべきです。ただし、最終的な応答の構築では、RDAP応答セットを組み立てる際に、プライバシーやその他のデータ解放ポリシーに注意する必要があります。
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.
すべてのクライアントに等しく適用される単一の静的な情報の返信ポリシーがない場合があることに注意してください。クライアントIDと関連する承認は、特定のクエリに対する応答セットの範囲を決定する際の重要な要素となります。
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].
このドキュメントでは、RIRとDNRの両方に一般的に登録されている限られた数のオブジェクトのパスセグメント仕様について説明します。すべてのレジストリに登録されているすべてのオブジェクトのパスセグメントについては説明しません。ここに指定されていないオブジェクトのカスタムパスセグメントは、「登録データアクセスプロトコル（RDAP）でのHTTPの使用」[RFC7480]のセクション6で説明されているプロセスを使用して作成できます。
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.
カスタムパスセグメントは、一意の識別子とその後に続くアンダースコア文字（0x5F）をセグメントの前に付けることによって作成できます。たとえば、「entity」の前に「custom_」を付けて「custom_entity」を生成することにより、カスタムエンティティパスセグメントを作成できます。サーバーは、認識されていないパスセグメントを含むリクエストに対して、適切な失敗ステータスコードを返さなければなりません（MUST）。
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.
RDAPサービスへのクエリ引数としてUラベル（IDNラベルのUnicode形式）またはAラベル（IDNラベルのUS-ASCII形式）を送信する機能をサポートすることには価値があります。 US-ASCII以外の文字を処理できるクライアントは、Aラベル文字列よりも視覚的に認識しやすく、使い慣れているためUラベルを好むかもしれませんが、プログラムインターフェイスを使用するクライアントは、Aラベルを送信および表示できない場合に、Aラベルを送信および表示する方が簡単な場合があります。キーボード設定でUラベルを入力します。どちらのクエリ形式も使用できます。
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].
国際化ドメインおよびネームサーバー名には、[RFC4290]で説明されているように、文字のバリアントとバリアントラベルを含めることができます。国際化ドメインおよびネームサーバー名のクエリをサポートするクライアントは、「Registration Data Access Protocol（RDAP）のJSON応答」[RFC7483]で指定されているバリアントを説明するサービスプロバイダーの応答を受け入れる必要があります。
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.
サーバーは、HTTPでサポートされるさまざまな形式でエンコードされた文字列を含む検索パターンをクライアントから受信することを期待できます。文字の比較を行う前に検索パターンにフィルターと正規化ルールを適用することは完全に可能ですが、このタイプの処理は、パターンを照合するよりも、登録された文字列の有効性を判断するために必要です。
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.
US-ASCII以外の文字を含むクエリ文字列を送信するRDAPクライアントは、そのような文字列をUTF-8エンコーディングのUnicodeに変換します。次に、必要と思われるローカルケースマッピングを実行します。文字列は、Normalization Form C（NFC）[Unicode-UAX15]を使用して正規化されます。クライアントがこれを確実に行うことができない場合があることに注意してください。 UTF-8でエンコードされた文字列は、クエリURLで適切にパーセントエンコードされます[RFC3986]。
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.
パーセントエンコーディングを解析した後、RDAPサーバーは各クエリ文字列をUTF-8エンコーディングのUnicodeとして扱います。文字列が有効なUTF-8でない場合、サーバーはクエリの処理を直ちに停止し、HTTP 400（Bad Request）応答を返すことができます。
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).
クエリを処理する場合、推定Uラベルを含むDNS名やその他すべてのDNS名の処理に違いがあります。 DNS名は、RFC 1035 [RFC1035]のセクション3.1に記載されている非予約LDH（NR-LDH）ラベルのDNSマッチングルールと、RFC 5891 [RFC5891]のセクション5.4に記載されているUラベルのマッチングルールに従って処理されます。 。 1つのドメインまたはホスト名でUラベルとNR-LDHラベルの組み合わせが見つかる可能性があるため、DNS名のマッチングは一度に1つのラベルを処理します。ラベルがUラベルかNR-LDHラベルかは、ラベルにUS-ASCII文字、数字、ハイフン以外の文字が含まれているかどうか（いわゆるLDHルール）に基づいて決定されます。
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.
それ以外の場合は、サーバーは全角文字と半角文字を対応する分解文字にマッピングします。サーバーは、文字列を、検索または検索されるターゲットデータの同じコード化文字セットに変換し、各文字列は、ターゲットデータで使用されたものと同じ正規化を使用して正規化されます。一般に、Unicodeとしての文字列の格納は推奨されます。比較の目的で、予測可能性と一致数を最大化するために、ケースフォールディング付きの正規化形式KC（NFKC）[Unicode-UAX15]が使用されます。この場合のNFCではなく、大文字と小文字を区別したNFKCの使用に注意してください。
Security services for the operations specified in this document are described in "Security Services for the Registration Data Access Protocol (RDAP)" [RFC7481].
このドキュメントで指定されている操作のセキュリティサービスは、「登録データアクセスプロトコル（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.
基本的な検索機能と比較すると、検索機能は通常、より多くのサーバーリソース（メモリ、CPUサイクル、ネットワーク帯域幅など）を必要とします。これにより、サーバーリソースが枯渇し、悪用によるサービス拒否のリスクが高まります。このリスクは、コントロールを開発および実装して、検索機能を特定および承認されたクライアントに制限することで軽減できます。これらのクライアントの動作が悪い場合、その検索権限を一時停止または取り消すことができます。 「登録データアクセスプロトコル（RDAP）でのHTTPの使用」[RFC7480]のセクション5.5で説明されているレート制限を使用して、受信した検索要求のレートを制御することもできます。サーバーオペレーターは、検索要求に応答して返される情報の量を制限することにより、リスクを軽減することもできます。
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.
検索機能は、他の方法では明白ではないかもしれないオブジェクト関係を開示するプライバシーリスクも増加させます。たとえば、クライアントが提供する検索パターンに明示的に一致しないIDNバリアント[RFC6927]を返す検索は、他の方法では利用できない可能性がある登録済みドメイン名に関する情報を開示する可能性があります。実装者は、明示的に要求されなかった情報を返すことのポリシーとプライバシーへの影響を考慮する必要があります。
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.
すべてのクライアントに等しく適用される単一の静的な情報の返信ポリシーがない場合があることに注意してください。クライアントIDと関連する承認は、特定のクエリに対する応答セットの範囲を決定する際の重要な要素となります。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985, <http://www.rfc-editor.org/info/rfc952>.
[RFC0952] Harrenstien、K.、Stahl、M。、およびE. Feinler、「DoD Internet host table specification」、RFC 952、1985年10月、<http://www.rfc-editor.org/info/rfc952>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>.
[RFC1123] Braden、R。、編、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月、<http://www.rfc-editor.org/info/rfc1123>。
[RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990, <http://www.rfc-editor.org/info/rfc1166>.
[RFC1166] Kirkpatrick、S.、Stahl、M。、およびM. Recker、「インターネット番号」、RFC 1166、1990年7月、<http://www.rfc-editor.org/info/rfc1166>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://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, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月、<http：//www.rfc- editor.org/info/rfc3986>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月、<http://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, August 2006, <http://www.rfc-editor.org/info/rfc4632>.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、2006年8月、<http：//www.rfc-editor .org / info / rfc4632>。
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007, <http://www.rfc-editor.org/info/rfc4918>.
[RFC4918] Dusseault、L.、編、「Web分散オーサリングおよびバージョン管理（WebDAV）のHTTP拡張機能」、RFC 4918、2007年6月、<http://www.rfc-editor.org/info/rfc4918>。
[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of Autonomous System (AS) Numbers", RFC 5396, December 2008, <http://www.rfc-editor.org/info/rfc5396>.
[RFC5396] Huston、G.およびG. Michaelson、「Textual Representation of Autonomous System（AS）Numbers」、RFC 5396、2008年12月、<http://www.rfc-editor.org/info/rfc5396>。
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009, <http://www.rfc-editor.org/info/rfc5730>.
[RFC5730] Hollenbeck、S。、「Extensible Provisioning Protocol（EPP）」、STD 69、RFC 5730、2009年8月、<http://www.rfc-editor.org/info/rfc5730>。
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, August 2009, <http://www.rfc-editor.org/info/rfc5733>.
[RFC5733] Hollenbeck、S。、「Extensible Provisioning Protocol（EPP）Contact Mapping」、STD 69、RFC 5733、2009年8月、<http://www.rfc-editor.org/info/rfc5733>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月、<http://www.rfc-editor.org/info/rfc5890>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、2010年8月、<http://www.rfc-editor.org/info/rfc5891>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、August 2010、<http://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, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、2014年6月、<http://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, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231>。
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, March 2015, <http://www.rfc-editor.org/info/rfC7480>.
[RFC7480]ニュートン、A。、エラコット、B。、およびN.コング、「登録データアクセスプロトコル（RDAP）でのHTTPの使用」、RFC 7480、2015年3月、<http://www.rfc-editor.org / info / rfC7480>。
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", RFC 7481, March 2015, <http://www.rfc-editor.org/info/rfc7481>.
[RFC7481] Hollenbeck、S. and N. Kong、 "Security Services for the Registration Data Access Protocol（RDAP）"、RFC 7481、March 2015、<http://www.rfc-editor.org/info/rfc7481>。
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, March 2015, <http://www.rfc-editor.org/info/rfc7483>.
[RFC7483]ニュートンA.およびS.ホレンベック、「JSON Responses for the Registration Data Access Protocol（RDAP）」、RFC 7483、2015年3月、<http://www.rfc-editor.org/info/rfc7483>。
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data (RDAP) Service", RFC 7484, March 2015, <http://www.rfc-editor.org/info/rfc7484>.
[RFC7484] Blanchet、M。、「Finding the Authoritative Registration Data（RDAP）Service」、RFC 7484、2015年3月、<http://www.rfc-editor.org/info/rfc7484>。
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2013, <http://www.unicode.org/reports/tr15/>.
[Unicode-UAX15] Unicodeコンソーシアム、「Unicode Standard Annex＃15：Unicode Normalization Forms」、2013年9月、<http://www.unicode.org/reports/tr15/>。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>.
[REST] Fielding、R。、「Architectural Styles and the Design of Network-based Software Architectures」、Ph.D。カリフォルニア大学アーバイン校の論文、2000年、<http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf>。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004, <http://www.rfc-editor.org/info/rfc3912>.
[RFC3912] Daigle、L。、「WHOIS Protocol Specification」、RFC 3912、2004年9月、<http://www.rfc-editor.org/info/rfc3912>。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005, <http://www.rfc-editor.org/info/rfc4007>.
[RFC4007] Deering、S.、Haberman、B.、Jinmei、T.、Nordmark、E。、およびB. Zill、「IPv6 Scoped Address Architecture」、RFC 4007、2005年3月、<http：//www.rfc- editor.org/info/rfc4007>。
[RFC4290] Klensin, J., "Suggested Practices for Registration of Internationalized Domain Names (IDN)", RFC 4290, December 2005, <http://www.rfc-editor.org/info/rfc4290>.
[RFC4290] Klensin、J。、「国際化ドメイン名（IDN）の登録のための推奨プラクティス」、RFC 4290、2005年12月、<http://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, February 2013, <http://www.rfc-editor.org/info/rfc6874>.
[RFC6874] Carpenter、B.、Cheshire、S。、およびR. Hinden、「Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers」、RFC 6874、2013年2月、<http://www.rfc-editor.org / info / rfc6874>。
[RFC6927] Levine, J. and P. Hoffman, "Variants in Second-Level Names Registered in Top-Level Domains", RFC 6927, May 2013, <http://www.rfc-editor.org/info/rfc6927>.
[RFC6927] Levine、J。およびP. Hoffman、「トップレベルドメインに登録されたセカンドレベル名のバリアント」、RFC 6927、2013年5月、<http://www.rfc-editor.org/info/rfc6927> 。
Acknowledgements
謝辞
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.
このドキュメントは、APNICのByron J. Ellacott、LACNICのArturo L. Servin、RIPE NCCのKaveh Ranjbar、およびARINのAndrew L. Newtonによって開発されたRIRクエリ形式に関するオリジナルの作業から派生しています。さらに、このドキュメントには、ICANNのFrancisco AriasとSteve ShengおよびVerisign LabsのScott Hollenbeckによって最初に記述されたDNRクエリ形式が組み込まれています。
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, Mark Nottingham, Kaveh Ranjbar, Arturo L. Servin, Steve Sheng, and Andrew Sullivan.
著者は、このドキュメントへの貢献に対して次の個人に謝意を表します。 Kaveh Ranjbar、Arturo L. Servin、Steve Sheng、Andrew Sullivan。
Authors' Addresses
著者のアドレス
Andrew Lee Newton American Registry for Internet Numbers 3635 Concorde Parkway Chantilly, VA 20151 United States
Andrew Lee Newton American Registry for Internet Numbers 3635 Concorde Parkway Chantilly、VA 20151アメリカ合衆国
EMail: andy@arin.net
URI: http://www.arin.net
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston、VA 20190アメリカ
EMail: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/