Internet Engineering Task Force (IETF) M. Blanchet Request for Comments: 7484 Viagenie Category: Standards Track March 2015 ISSN: 2070-1721 権威を持つRegistration Data（RDAP）サービスの特定 Abstract 本ドキュメントは、ドメイン名、IPアドレス、またはAS（自律システム）番 号などの要求された範囲に対し、どのRDAP（Registration Data Access Protocol）サーバーがクエリに回答する権威があるかを特定する方法を規定 する。 Status of This Memo 本ドキュメントは、インターネット標準化過程のドキュメントである。 本ドキュメントは、IETF（Internet Engineering Task Force）の成果物で ある。IETFコミュニティのコンセンサスを代表するものである。また、本ド キュメントは、公開レビューを受けており、IESG（Internet Engineering Steering Group）から公開・発行することを承認されている。インターネッ ト標準に関する詳細は、RFC 5741のSection 2で提供されている。 本ドキュメントに関する最新の状態、正誤、フィードバックの方法などに関 する情報は、下記URLを参照。 http://www.rfc-editor.org/info/rfc7484 Copyright Notice Copyright (c) 2015 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 (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. Blanchet Standards Track [Page 1] RFC 7484 Finding Authoritative RDAP Service March 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Structure of the RDAP Bootstrap Service Registries . . . . . 3 4. Bootstrap Service Registry for Domain Name Space . . . . . . 5 5. Bootstrap Service Registries for Internet Numbers . . . . . . 6 5.1. Bootstrap Service Registry for IPv4 Address Space . . . . 7 5.2. Bootstrap Service Registry for IPv6 Address Space . . . . 8 5.3. Bootstrap Service Registry for AS Number Space . . . . . 9 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Non-existent Entries or RDAP URL Values . . . . . . . . . . . 10 8. Deployment and Implementation Considerations . . . . . . . . 10 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Formal Definition . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Imported JSON Terms . . . . . . . . . . . . . . . . . . 11 10.2. Registry Syntax . . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12.1. Bootstrap Service Registry for IPv4 Address Space . . . 14 12.2. Bootstrap Service Registry for IPv6 Address Space . . . 14 12.3. Bootstrap Service Registry for AS Number Space . . . . . 14 12.4. Bootstrap Service Registry for Domain Name Space . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction レジストリからの登録データの問い合わせ及び検索は、RDAP（Registration Data Access Protocol）[RFC7480] [RFC7482] [RFC7483] で定義されている。 これらのドキュメントは、どこにクエリを送信すべきかを規定していない。 本ドキュメントでは、要求された範囲のクエリに対し、どのサーバーが回答 する権威を持つかを特定する方法を規定する。 TLD（Top-Level Domain）、AS（自律システム）番号及びネットワークブロッ クは、IANAによって、TLDレジストリや RIR（地域インターネットレジスト リ）などのインターネットレジストリに委任される。インターネットレジス トリは、再委任と情報の管理を行う。従って、RDAPクライアントが必要とす るブートストラップ情報は、IANAによって維持されている。関連するレジス トリは、[ipv4reg]、[ipv6reg]、[asreg] 及び [domainreg] に既に存在す る。 Blanchet Standards Track [Page 2] RFC 7484 Finding Authoritative RDAP Service March 2015 本ドキュメントで、IANAは、本ドキュメントで規定されたJSON形式に基づい て新しいレジストリを作成し、ここにRDAPブートストラップサービスレジス トリと名付けた。この新しいレジストリは、上記で言及されたレジストリの 現在のエントリーに準じている。RDAPクライアントは、RDAPブートストラッ プサービスレジストリをフェッチし、データを抽出し、権威登録データサー バー及び適切なクエリのベースURLを見つけるためにクエリデータによる一 致を行う。 2. Conventions Used in This Document 本ドキュメントにおける次の各キーワード「しなければならない（MUST）」、 「してはならない（MUST NOT）」、「要求されている（REQUIRED）」、「す ることになる（SHALL）」、「することはない（SHALL NOT）」、「すべきで ある（SHOULD）」、「すべきではない（SHOULD NOT）」、「推奨される （RECOMMENDED）」、「してもよい（MAY）」、「任意である（OPTIONAL）」は、 [RFC2119] で説明されているように解釈されるべきものである。 3. Structure of the RDAP Bootstrap Service Registries 下記Section 12で規定されているRDAPブートストラップサービスレジストリ は、IANAが規定する場所からHTTP経由で照会することができるJSON [RFC7159] オブジェクトとして利用可能である。各レジストリのJSONオブジ ェクトは、バージョン識別子、レジストリの公告日のタイムスタンプ及び説 明などのレジストリに関するメタデータを含んでいる一連のメンバーを含む。 更に、"services"メンバーは、配列としてレジストリ項目自身を含む。配列 の各項目は、二つの要素の第2レベル配列を含む。それらの各要素が第3レベ ル配列である。 サービス配列の各要素は、二つの要素の第2レベル配列である。エントリー 配列とサービスURL配列の順である。 エントリー配列は、すべてのエントリーを含み、ベースRDAP URLの同じ集合 を持つ。サービスURL配列は、エントリー配列内のエントリーに使用できる ベースRDAP URLのリストを含む。これら二つの配列の要素は、いずれにして もソートされない。 Blanchet Standards Track [Page 3] RFC 7484 Finding Authoritative RDAP Service March 2015 以下は、RDAPブートストラップサービスレジストリのJSON出力の構造例を示 す： { "version": "1.0", "publication": "YYYY-MM-DDTHH:MM:SSZ", "description": "Some text", "services": [ [ ["entry1", "entry2", "entry3"], [ "https://registry.example.com/myrdap/", "http://registry.example.com/myrdap/" ] ], [ ["entry4"], [ "http://example.org/" ] ] ] } 正式な構文は、Section 10で説明されている。 "version"は、レジストリの形式バージョンに対応している。ここでは、バー ジョン"1.0"を定義する。 "publication"値の構文は、インターネットの日時形式 [RFC3339] に従う。 値は、IANAによるレジストリの最終更新日である。 任意の"description"文字列は、ブートストラップオブジェクトの内容につ いてのコメントを含めることができる。 [RFC7258] につき、ベースRDAP URLの各配列では、転送プロトコルのセキュ アなバージョンが選択され、まずそれを試すべきである（SHOULD）。例え ば、ベースRDAP URLの配列は、HTTPS及びHTTP URLの両方を含むが、ブート ストラップクライアントは、まずHTTPSバージョンを試すべきである （SHOULD）。 ベースRDAP URLは、[RFC7482] で定義されるさまざまなセグメントが連結さ れるため、"/"文字を後続させなければならない（MUST）。 JSON名称は、[RFC7480] で推奨される形式に従わなければならない（MUST）。 未認識のJSONオブジェクトのプロパティまたは値は、実装で無視されなけれ ばならない（MUST）。 Blanchet Standards Track [Page 4] RFC 7484 Finding Authoritative RDAP Service March 2015 エントリーとして使用される国際化ドメイン名（IDN）ラベルと、本ドキュ メントで定義されるレジストリのベースRDAP URLは、[RFC5890] で定義され るA-label形式を用いて表記されなければならない（MUST）。 エントリーとして使用されるすべてのドメイン名ラベルと、本ドキュメント で定義されるレジストリのベースRDAP URLは、小文字で表記されなければな らない（MUST）。 4. Bootstrap Service Registry for Domain Name Space このレジストリのJSON出力は、下記の例に示すようなベースRDAP URLでグルー プ化されたルートに付属するドメインラベルエントリーを含む。 { "version": "1.0", "publication": "YYYY-MM-DDTHH:MM:SSZ", "description": "Some text", "services": [ [ ["net", "com"], [ "https://registry.example.com/myrdap/" ] ], [ ["org", "mytld"], [ "http://example.org/" ] ], [ ["xn--zckzah"], [ "https://example.net/rdapxn--zckzah/", "http://example.net/rdapxn--zckzah/" ] ] ] } ドメイン名の権威登録データサービスは、ドメイン名空間のためのIANAブー トストラップサービスレジストリ内のエントリー配列におけるドメインの値 と、ターゲットドメイン名とのラベルに関する最長一致を行うことで見つけ られる。一致は、ラベルごとに、右から左へ行われる。その最長一致が複数 エントリーという結果であった場合、それらのエントリーは等価と考えられ る。 Blanchet Standards Track [Page 5] RFC 7484 Finding Authoritative RDAP Service March 2015 第2レベルの配列に一致するサービスURL配列内に含まれる値は、[RFC7482] で説明されているように、有効なベースRDAP URLである。 例えば、"a.b.example.com"に対するドメインRDAPクエリは、レジストリの 配列の一つであるcomエントリーと一致する。このクエリのベースRDAP URL は、配列の2番目の要素から得られる。その要素とは、このエントリーの有 効なベースRDAP URLの配列である。クライアントは、この配列からベース URLの一つを選ぶ。この例では、クライアントは使用可能な "https://registry.example.com/myrdap/"一つだけを選択する。[RFC7482] で規定されたセグメントは、クエリを完成するためにベースURLに付加され る。完全なクエリは以下となる。 "https://registry.example.com/myrdap/domain/a.b.example.com" a.b.example.comに対するドメインRDAPクエリがレジストリ内のcom及び example.comエントリーの両方に一致する場合、最長一致が適用され、 example.comエントリーがクライアントで使用される。 レジストリがcom及びgoodexample.comなどのエントリーを含む場合、 example.comに対するドメインRDAPクエリは、comエントリーにのみ一致する。 マッチングはラベルごとに行われるからである。 ドメイン名空間のルートのためのエントリーは、""で規定される。 5. Bootstrap Service Registries for Internet Numbers このセクションでは、IPv4とIPv6アドレス空間及びAS番号について記す。 IPアドレス空間にとって、権威登録データサービスは、アドレス空間のため の通信RDAPブートストラップサービスレジストリ内の配列の値とターゲット アドレスとの最長一致を行うことで見つけられる。最長一致は、ルーティン グと同じ方法で行われる。アドレスは、バイナリ形式に変換され、その後、 バイナリ文字列は、最長一致を見つけるため、規定されたプレフィックス長 まで比較される。配列の2番目の要素の値は、[RFC7482] で説明されている ベースRDAP URLである。最長一致法は、ベースRDAP URLを指す広大なアドレ ス空間のプレフィックスをカバーすることを可能にさせる。同時に、カバー するプレフィックスの範囲内にあるより多くの具体的なプレフィックスが、 別のベースRDAP URLで提供されている。 Blanchet Standards Track [Page 6] RFC 7484 Finding Authoritative RDAP Service March 2015 5.1. Bootstrap Service Registry for IPv4 Address Space このレジストリのJSON出力は、下記の例に示すような、CIDR（Classless Inter-domain Routing）形式 [RFC4632] で規定されたRDAP URLでグループ 化したIPv4プレフィックスエントリーを含む。 { "version": "1.0", "publication": "2024-01-07T10:11:12Z", "description": "RDAP Bootstrap file for example registries.", "services": [ [ ["1.0.0.0/8", "192.0.0.0/8"], [ "https://rir1.example.com/myrdap/" ] ], [ ["28.2.0.0/16", "192.0.2.0/24"], [ "http://example.org/" ] ], [ ["28.3.0.0/16"], [ "https://example.net/rdaprir2/", "http://example.net/rdaprir2/" ] ] ] } 例えば、"192.0.2.1/25"に対するクエリは、上記のレジストリの例における "192.0.0.0/8"エントリー及び"192.0.2.0/24"エントリーに一致する。後者 が、最長一致によりクライアントに選択される。このクエリのベースRDAP URLは、配列の2番目の要素から得られる。その要素とは、このエントリーの 有効なベースRDAP URLの配列である。クライアントは、この配列からベース URLの一つを選ぶ。この例では、クライアントは使用可能な "http://example.org/"一つだけを選択する。[RFC7482] で規定された {resource} は、クエリを完成するためにベースURLに付加される。完全な クエリは以下となる。 "https://example.org/ip/192.0.2.1/25" Blanchet Standards Track [Page 7] RFC 7484 Finding Authoritative RDAP Service March 2015 5.2. Bootstrap Service Registry for IPv6 Address Space このレジストリのJSON出力は、下記の例に示すような、[RFC4291] のアドレ スプレフィックス形式のテキスト表記を用い、ベースRDAP URLでグループ化 したIPv6プレフィックスエントリーを含む。 { "version": "1.0", "publication": "2024-01-07T10:11:12Z", "description": "RDAP Bootstrap file for example registries.", "services": [ [ ["2001:0200::/23", "2001:db8::/32"], [ "https://rir2.example.com/myrdap/" ] ], [ ["2600::/16", "2100:ffff::/32"], [ "http://example.org/" ] ], [ ["2001:0200:1000::/36"], [ "https://example.net/rdaprir2/", "http://example.net/rdaprir2/" ] ] ] } 例えば、"2001:0200:1000::/48"に対するクエリは、上記のレジストリの例 における"2001:0200::/23"エントリー及び"2001:0200:1000::/36"エントリー に一致する。後者のエントリーは、最長一致によりクライアントに選択され る。このクエリのベースRDAP URLは、配列の2番目の要素から得られる。そ の要素とは、このエントリーの有効なベースRDAP URLの配列である。クライ アントは、この配列からベースURLの一つを選ぶ。この例では、クライアン トは"https://example.net/rdaprir2/"を選択する。それが、プロトコルの セキュアなバージョンであるためである。[RFC7482] で規定されたセグメン トは、クエリを完成するためにベースURLに付加される。完全なクエリは以 下となる。 "https://example.net/rdaprir2/ip/2001:0200:1000::/48" ターゲットのRDAPサーバーが回答しない場合、クライアントは、配列から別 のURLプレフィックスを使用することができる。 Blanchet Standards Track [Page 8] RFC 7484 Finding Authoritative RDAP Service March 2015 5.3. Bootstrap Service Registry for AS Number Space このレジストリのJSON出力は、下記の例に示すような、ベースRDAP URLでグ ループ化したAS番号範囲のエントリーを含む。エントリー配列は、2番目の 要素内で見つかったベースRDAP URLによって提供されるAS番号範囲のリスト を含む配列である。その配列は、10進数形式で表記された二つのAS番号を常 に含む。そして、二つのAS番号は、その配列の二つの要素の間でAS番号の範 囲を表記する。単一のAS番号は、二つの同一AS番号の範囲として表記される。 { "version": "1.0", "publication": "2024-01-07T10:11:12Z", "description": "RDAP Bootstrap file for example registries.", "services": [ [ ["2045-2045"], [ "https://rir3.example.com/myrdap/" ] ], [ ["10000-12000", "300000-400000"], [ "http://example.org/" ] ], [ ["64512-65534"], [ "http://example.net/rdaprir2/", "https://example.net/rdaprir2/" ] ] ] } 例えば、AS 65411に対するクエリは、上記のレジストリの例における 64512-65534エントリーと一致する。このクエリのベースRDAP URLは、配列 の2番目の要素から得られる。その要素とは、このエントリーの有効なベー スRDAP URLの配列である。クライアントは、この配列からベースURLの一つ を選ぶ。この例では、クライアントは"https://example.net/rdaprir2/"を 選択する。 [RFC7482] で規定されたセグメントは、クエリを完成するためにベースURL に付加される。完全なクエリは以下となる。 "https://example.net/rdaprir2/autnum/65411" サーバーが回答しない場合、クライアントは、配列から別のURLプレフィッ クスを使用することができる。 Blanchet Standards Track [Page 9] RFC 7484 Finding Authoritative RDAP Service March 2015 6. Entity エンティティー（連絡先、登録者、レジストラなど）は、[RFC7482] で説明 されているハンドルによって問い合わされる。エンティティーのためのグロー バル名前空間が存在しないため、本ドキュメントでは、エンティティーのた めの権威RDAPサーバーの検索方法については説明しない。しかし、エンティ ティー識別子が以前のクエリから受信された場合、同一のRDAPサーバーがそ のエンティティーのクエリを受けるか、またはエンティティー識別子自身が クエリ可能な完全な参照URLであることが可能性としてある。 7. Non-existent Entries or RDAP URL Values レジストリは、要求された値を含まないかもしれない。その場合、要求され た値のための既知のRDAPサーバーがないので、クライアントは、適切なエラー メッセージをユーザーに提供すべきである（SHOULD）。 8. Deployment and Implementation Considerations この方法は、ローカルでサーバーを特定するためRDAPクライアントがIANAレ ジストリをフェッチするという事実に依存している。クライアントは、RDAP リクエストすべてでレジストリをフェッチすべきではない（SHOULD NOT）。 クライアントは、レジストリをキャッシュすべきである（SHOULD）が、キャ ッシュされたレジストリをリフレッシュする時間を識別するために、HTTP Expiresヘッダーフィールド [RFC7234] などの下層プロトコルのシグナルを 使用する。 クエリデータが、クライアントのキャッシュされたレジストリのどのエント リーとも一致しない場合、クライアントは、下記のようなさまざまな方法を 実施するであろう。 o ドメインオブジェクトの場合、クライアントは、まず該当する入力が委 任されているか、またはユーザーが入力を間違えた情報かを確認するた め、DNSに問い合わせる。DNSクエリは、TLDドメインのNSレコードをフェッ チすることができる。DNS回答が不在応答の場合、レジストリの新バージョ ンをフェッチする必要はない。しかし、DNS回答が正常の場合、これは現 在キャッシュされたレジストリは、もはや有効ではないことを意味する かもしれない。クライアントは、レジストリをフェッチし、解析し、そ の後、上記で規定された通常のマッチングを行う。この方法は、RDAPオ ブジェクトのすべてのタイプで機能するとは限らない。 o クライアントがRDAPアグリゲーターまたはRDAPリダイレクター及びその 関連するベースURLの存在を知っており、そしてそのサービスを信頼して いる場合、リダイレクターにクエリを送信する。リダイレクターは、ク ライアントが見つけられなかった権威サーバーをリダイレクターが知っ ている場合、クライアントをリダイレクトする。 Blanchet Standards Track [Page 10] RFC 7484 Finding Authoritative RDAP Service March 2015 登録データの一部の権威は、相互リダイレクト [REDIRECT-RDAP] を含む共 通サービスのために、それらの情報を共有の上、一丸となって取り組むかも しれない。 新規AS範囲、新規TLDまたは新規IPアドレス範囲といった新規オブジェクト が割り振られた時、この新規オブジェクトがブートストラップRDAPレジスト リに一致するエントリーを持つ保証はない。この新規エントリーのRDAPサー バーのセットアップが、後で有効になり、登録されるかもしれないためであ る。そのため、クライアントは、例えTLD、IPアドレス範囲、AS範囲といっ たオブジェクトが割り振られたとしても、ブートストラップレジストリに一 致するエントリーの存在が保証されないことを、予期しなければならない。 9. Limitations この方法は、本ドキュメントで説明されたオブジェクトを除き、他のオブジ ェクトのための権威RDAPサーバーを見つける直接的な方法を提供しない。 特に、下記のオブジェクトは、本ドキュメントで説明された方法を用いてブー トストラップされない。 o エンティティー o レジストリにおいて一部のエントリーと一致する終端文字列を含まない 検索パターンを用いたクエリ o ネームサーバー o ヘルプ 10. Formal Definition このセクションは、レジストリの公式定義である。基本要素の集合を用いた JSONオブジェクト及び配列の構造は、[RFC7159] で定義されている。これら の要素は、レジストリのJSON構造を説明するために使用される。 10.1. Imported JSON Terms o OBJECT：JSONオブジェクト。[RFC7159] のSection 4で定義されている。 o MEMBER：JSONオブジェクトのメンバー。[RFC7159] のSection 4で定義さ れている。 o MEMBER-NAME：MEMBERの名称。[RFC7159] のSection 4の"string"で定義 されている。 o MEMBER-VALUE：MEMBERの値。[RFC7159] のSection 4の"value"で定義さ れている。 Blanchet Standards Track [Page 11] RFC 7484 Finding Authoritative RDAP Service March 2015 o ARRAY：配列。[RFC7159] のSection 5で定義されている。 o ARRAY-VALUE：ARRAYの要素。[RFC7159] のSection 5で定義されている。 o STRING："string"。[RFC7159] のSection 7で定義されている。 10.2. Registry Syntax JSON構造の上記の用語を用いて、レジストリの構文は、下記の通り定義され る。 o rdap-bootstrap-registry：MEMBER version、MEMBER publication、任意 のMEMBER description及びMEMBER services-listを含むOBJECT o version：MEMBER-NAMEが"version"、MEMBER-VALUEがSTRINGであるMEMBER o publication：MEMBER-NAMEが"publication"、MEMBER-VALUEがSTRINGであ るMEMBER o description：MEMBER-NAMEが"description"、MEMBER-VALUEがSTRINGであ るMEMBER o services-list：MEMBER-NAMEが"services"、MEMBER-VALUEが services-arrayであるMEMBER o services-array：各ARRAY-VALUEがserviceであるARRAY o service：一番目のARRAY-VALUEがentry-list、2番目のARRAY-VALUEが service-uri-listである2要素のARRAY o entry-list：各ARRAY-VALUEがentryであるARRAY o entry：STRING o service-uri-list：各ARRAY-VALUEがservice-uriであるARRAY o service-uri：STRING Blanchet Standards Track [Page 12] RFC 7484 Finding Authoritative RDAP Service March 2015 11. Security Considerations RDAPサーバーを特定するブートストラップメソッドを提供することにより、 本ドキュメントは、エンドユーザーが不正な情報源の代わりに権威のある情 報源からRDAPデータを取得できるようにする。この方法は、RDAPプロトコル 自身と同じセキュリティプロパティを持つ。レジストリへのアクセスに使用 される転送は、IANAがサポートするTLS [RFC5246] を用いてよりセキュアに することができる。 RDAPを用いることの追加の考察は、[RFC7481] で説明されている。 12. IANA Considerations IANAは、下記のRDAPブートストラップサービスレジストリを作成し、JSONオ ブジェクトとして利用可能にする。このレジストリの内容は、Section 10で 規定された正式な構文を用い、Section 3、Section 4、Section 5で説明さ れている。 これらのレジストリでエントリーを追加または更新するプロセスは、通常の IANAレジストリプロセスとは異なる。これらのレジストリは、新しいRDAPサー バー情報の追加によって、割り振りレジストリ（[ipv4reg]、[ipv6reg]、 [asreg] と [domainreg]）においてIANAが管理するデータ、プロセス及びポ リシーから生成される。 IANAは、それらの割り振りレジストリが更新されると、割り振りレジストリ からRDAPブートストラップサービスレジストリのエントリーを作成し、更新 する。 本ドキュメントは、割り振りレジストリに関連するいずれのポリシーも変更 しない。IANAは、RDAPサーバー情報を収集するためのメカニズムを提供して いる。RDAPブートストラップサービスレジストリは、空の状態で始まる。そ して、ドメイン及びアドレス空間の登録者がIANAにRDAPサーバー情報を提供 することで、徐々に追加されていく。 IANAは、Protocol Registriesページ に、 新しいトップレベルカテゴリーを作成した。そのグループは、 "Registration Data Access Protocol（RDAP）"と呼ばれる。各RDAPブート ストラップサービスレジストリが、JSON形式でオンデマンド式のダウンロー ドを一般公衆のために利用可能にする。そのようなレジストリのURIは、 Protocol Registriesページに直接リストされる。 他の通常のレジストリは、他のドキュメントによって、このグループに追加 される。しかし、これらのレジストリのURIが明確にメインページにリスト される理由は、実装者にそれらのURIを明らかにするためである。これらは、 参照情報としてURIを用いて、人だけでなく、ソフトウェアによってもアク セスされるレジストリである。 Blanchet Standards Track [Page 13] RFC 7484 Finding Authoritative RDAP Service March 2015 これらのレジストリはソフトウェアによってアクセスされるので、RDAPブー トストラップサービスレジストリのダウンロード需要は、通常のIANAレジス トリに比べ、異常に高いかもしれない。レジストリが公開されることによる 技術インフラは、検討される必要があり、拡張する必要もあるかもしれない。 Section 8で述べたように、これらのレジストリにアクセスするソフトウェ アは、クエリレートを制限するHTTP Expiresヘッダーフィールドに依存する。 従って、IANAサーバーにおける適度な負荷を維持しつつ、レジストリの変更 のような時宜の情報の提供のために適切に設定されるヘッダーフィールドが 重要である。JSON形式のレジストリにアクセスするクライアントに返される HTTP Content-Typeは、[RFC7159] で定義される"application/json"でなけ ればならない（MUST）。 RDAPブートストラップサービスレジストリの情報がグループ化及び形式化さ れるため、レジストリエントリーはソート可能ではないかもしれない。従っ て、いずれにしてもエントリーがソートされることは、要求されず、期待さ れない。 12.1. Bootstrap Service Registry for IPv4 Address Space このレジストリのエントリーは、少なくとも下記を含む。 o 登録されているネットワークブロックのCIDR [RFC4632] 仕様 o この登録に関するRDAPサービスを提供する一つ以上のURL 12.2. Bootstrap Service Registry for IPv6 Address Space このレジストリのエントリーは、少なくとも下記を含む。 o 登録されているネットワークブロックのIPv6プレフィックス [RFC4291] 仕様 o この登録に関するRDAPサービスを提供する一つ以上のURL 12.3. Bootstrap Service Registry for AS Number Space このレジストリのエントリーは、少なくとも下記を含む。 o 登録されているAS番号の範囲 o この登録に関するRDAPサービスを提供する一つ以上のURL Blanchet Standards Track [Page 14] RFC 7484 Finding Authoritative RDAP Service March 2015 12.4. Bootstrap Service Registry for Domain Name Space このレジストリのエントリーは、少なくとも下記を含む。 o 登録されているルートに付属するドメイン名 o この登録に関するRDAPサービスを提供する一つ以上のURL 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, . [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, . 13.2. Informative References [REDIRECT-RDAP] Martinez, C., Zhou, L., and G. Rada, "Redirection Service for Registration Data Access Protocol", Work in Progress, draft-ietf-weirds-redirects-04, July 2014. Blanchet Standards Track [Page 15] RFC 7484 Finding Authoritative RDAP Service March 2015 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, . [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for Reputation Interchange", RFC 7071, November 2013, . [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, . [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, March 2015, . [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol", RFC 7481, March 2015, . [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol Query Format", RFC 7482, March 2015, . [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, March 2015, . [asreg] IANA, "Autonomous System (AS) Numbers", . [domainreg] IANA, "Root Zone Database", . [ipv4reg] IANA, "IPv4 Address Space Registry", . [ipv6reg] IANA, "IPv6 Global Unicast Address Assignments", . Blanchet Standards Track [Page 16] RFC 7484 Finding Authoritative RDAP Service March 2015 Acknowledgements The WEIRDS working group had multiple discussions on this topic, including a session during IETF 84, where various methods such as in-DNS and others were debated. The idea of using IANA registries was discovered by the author during discussions with his colleagues as well as by a comment from Andy Newton. All the people involved in these discussions are herein acknowledged. Linlin Zhou, Jean- Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom Harrison, Naoki Kambe, Alexander Mayrhofer, Edward Lewis, Pete Resnick, Alessandro Vesely, Bert Greevenbosch, Barry Leiba, Jari Arkko, Kathleen Moriaty, Stephen Farrell, Richard Barnes, and Jean- Francois Tremblay have provided input and suggestions to this document. Guillaume Leclanche was a coauthor of this document for some revisions; his support is therein acknowledged and greatly appreciated. The section on formal definition was inspired by Section 6.2 of [RFC7071]. Author's Address Marc Blanchet Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada EMail: Marc.Blanchet@viagenie.ca URI: http://viagenie.ca Blanchet Standards Track [Page 17] RFC7484-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Services Co., Ltd. https://jprs.jp/tech/