拡張プロビジョニングプロトコル
拡張プロビジョニングプロトコル
通信プロトコル
略語EPP
目的登録や更新などのドメイン名取引の自動化
開発者スコット・ホレンベック、インターネット技術タスクフォース（IETF）
導入2009 （2009年）
OSI層アプリケーション層
ポート700
RFC(s)5730、5731、5732、5733、5734​​​​​​​​

拡張プロビジョニングプロトコル（EPP ）は、インターネット上のレジストリ内でオブジェクトを割り当てるために設計された柔軟なプロトコルです。EPP作成の動機は、ドメイン名レジストリとドメイン名レジストラ間の通信を可能にする堅牢で柔軟なプロトコルを作成することでした。これらのトランザクションはドメイン名の登録または更新のたびに必要となり、ドメインハイジャックの防止にも役立ちます。EPP導入前は、レジストリには統一されたアプローチがなく、さまざまな独自のインターフェースが存在していました。ドメイン名への使用が当初の推進力でしたが、このプロトコルはあらゆる種類の発注・履行システムに使用できるように設計されています。[ 1 ]

EPPは構造化されたテキストベースのフォーマットであるXMLに基づいています。基盤となるネットワークトランスポートは固定されていませんが、現在指定されている唯一の方法はTCPです。このプロトコルは、 BEEP、SMTP、SOAP、HTTPSなどの他のトランスポートも利用できる柔軟性を備えて設計されています。[ 1 ]ただし、大多数はTCPを使用しているのに対し、HTTPSのみが一部で使用されています。

歴史

最初のプロトコル草案は、2000年11月にVerisignのScott HollenbeckによってIETF個人提出インターネット草案文書として公開されました。 [ 2 ]個人提出文書は、 2000年12月にIETF-49で開催されたBoFセッション後に設立されたIETFプロビジョニングレジストリ（provreg）ワーキンググループによって採択されました。 [ 3 ]提案された標準文書（RFC 3730 - 3734）は、 2004年3月にRFCエディターによって公開されました。[ 4 ]草案標準文書（RFC 4930 - 4934）は、2007年5月に公開されました。[ 5 ]

2009年8月、IETFはEPPをSTD 69として完全な標準規格として認定した。[ 6 ]

提案された標準となった最初のEPP拡張は、2004年9月のRFC 3915の償還猶予期間拡張でした。[ 7 ]それ以来、いくつかの異なる提案された標準拡張が続きました。[ 8 ]

採択

このプロトコルは、.ac、.ag、.ai 、.as 、.ar、.at、.au、.be、.br、.bz、.ca 、.cat、.cc、.ch、.cl 、.cn、.co、.cr、.cx、.cz、.dk、.dm、.ee、.es (HTTPS 経由) 、. eu、 .fi 、.fm、.fr、.gg、.gr (HTTPS 経由)、. gs、.hn、.ht、.il、.im、.in、.io、.it (HTTPS 経由)、. je 、 .keなど、多数のccTLDドメイン名レジストリによって 採用されています。.ki、.ky、.kz、.la、.lc、.li、.lt、.lu、.lv、.md、.me、.mk、.mn、.ms、.mu、.mx、.na、.nf、.ng、.nl、.no、.nu、.nz、.pe、.pk、.pl（HTTPS 経由）、. ps、.pt、.ru、.ro、.sc、.se、.sh、.si、.su、.tl、.tm、.tv 、 .tw 、 .ua 、 .uk 、 .us 、.vc 、 .ve、.za、およびENUMレジストリ+31、+41、+43、+44、+48の国番号を運用する事業者など。[ 9 ]

ICANNは、基本レジストリ契約においてEPPサービスの提供を条件としています。そのため、すべてのgTLDがこのプロトコルを採用しています。[ 10 ]

EPPサーバーソフトウェアのオープンソース実装は複数存在します。Council of Country Code Administrators (CoCCA) は、約59のccTLDと6つのgTLDで使用されているEPPサーバーソフトウェアを管理しています。[ 11 ]もう一つのオープンソースソフトウェアはFRED（ CZ.NICが管理）で、11のccTLDがユーザーとなっています。[ 12 ]

プロトコルコマンド

コマンドには、セッション管理、クエリ、オブジェクト変換の3つのクラスがあります。これらのコマンドはオブジェクトにマッピングされ、その正確な機能が指定されます。[ 1 ]最も一般的な標準化オブジェクトは、ホスト、[ 13 ]連絡先[ 14 ]およびドメイン[ 15 ]です。組織[ 16 ]などの標準化オブジェクトも存在しますが、これらはあまり使用されません。

クライアントがサーバーに接続すると、サーバーは直ちにクライアントに「グリーティング」メッセージを送信します。このメッセージには、クライアントが接続する必要があるサーバーに関する情報が含まれています。これには、サーバー名、サーバーの現在の日時（UTC）、サポートされている機能、プライバシーポリシーが含まれます。サポートされている機能には、EPPのバージョン、言語、オブジェクト、拡張機能が含まれます。[ 1 ]

セッション管理コマンドは以下の通りである: [ 1 ]

指示 使用法
こんにちは サーバーに別の「挨拶」応答を要求します。
ログイン 新しいセッションを開始します。このセッションは、ログアウトが使用されるか、サーバーがユーザーをログアウトするまで維持されます。パスワードの変更にも使用されます。クライアントは、ログイン時の「挨拶」メッセージからEPPのバージョンと言語を1つ選択する必要があります。また、サーバーがサポートし、このセッションで使用するすべてのオブジェクトと拡張機能も選択する必要があります。
ログアウト 現在のセッションを終了します。

クエリコマンドは以下のとおりです: [ 1 ]

指示 使用法
チェック オブジェクトがまだ作成可能かどうかを確認します。
情報 オブジェクトに関する現在の情報をすべて取得します。
世論調査 ユーザ宛てにサーバからメッセージを読み取ったり、受信を確認したりして、次のメッセージを受信できるようにメッセージを削除します。(メッセージ キュー)
移行 開始されたオブジェクト転送プロセスの現在のステータスを取得します。

オブジェクト変換コマンドは以下の通り: [ 1 ]

指示 使用法
作成する 新しいオブジェクトを作成します。
消去 オブジェクトを削除します。ホストと連絡先は直ちに削除されますが、ドメインは主に償還猶予期間に変更されます。
更新する ドメイン名の登録期間を延長します。ドメイン以外のオブジェクトには有効期限がないため、このオプションは使用できません。
移行 オブジェクトのレジストラ/所有者を変更します。受信転送プロセスの開始またはキャンセル、および送信転送の承認または拒否に使用できます。
アップデート オブジェクトを更新します。これには通常、ドメイン所有者の変更が含まれますが、TLDによってはこれらの操作のワークフローが複雑になるため、EPP拡張機能を介して実装されることがよくあります。

例

ドメインを作成するコマンドの例は次のようになります。

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp xmlns= "urn:ietf:params:xml:ns:epp-1.0" > <command> <create> <domain:create xmlns:domain= "urn:ietf:params:xml:ns:domain-1.0" > <domain:name> example.com </domain:name> <domain:period unit= "y" > 1 </domain:period> <domain:ns> <domain:hostObj> ns1.example.net </domain:hostObj> <domain:hostObj> ns2.example.net </domain:hostObj> </domain:ns> <domain:registrant> REG-1738 </domain:registrant> <domain:contact type= "admin" > ADM-9374 </domain:contact> <domain:contact type= "tech" > OTH-2567 </domain:contact> <domain:contact type= "billing" > OTH-2567 </domain:contact> <domain:authInfo> <domain:pw> y85NS%FJ4zeKuHXo </domain:pw> </domain:authInfo> </domain:create> </create> <clTRID> uu28qbb2wo6o5bpk </clTRID> </command> </epp>

2つのホストオブジェクトと3つの異なる連絡先オブジェクトを使用するには、事前に作成しておく必要があり、クライアントはログイン済みである必要があることに注意してください。 はauthInfo pwレジストラ間の転送に必要な秘密鍵です。 はclTRIDクライアントが生成する各コマンドの一意のトランザクションIDです。上記のコマンドに対するサーバーの応答は次のようになります。

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp xmlns= "urn:ietf:params:xml:ns:epp-1.0" > <response> <result code= "1000" > <msg>コマンドは正常に完了しました</msg> </result> <resData> <domain:creData xmlns:domain= "urn:ietf:params:xml:ns:domain-1.0" > <domain:name> example.com </domain:name> <domain:crDate> 2023-03-12T12:00:00.0Z </domain:crDate> <domain:exDate> 2024-03-12T12:00:00.0Z </domain:exDate> </domain:creData> </resData> <trID> <clTRID> uu28qbb2wo6o5bpk </clTRID> <svTRID> ma3fuaeuh7bzpgv9 </svTRID> </trID> </response> </epp>

はclTRIDクライアントが送信したものと同じですが、 はsvTRIDサーバーが生成する一意のトランザクションIDです。サーバーは結果コード、メッセージ、および新規作成されたドメインの有効期限などの追加の結果データを返します。

拡張機能

このプロトコルは、ほぼすべてのコマンドに拡張オブジェクトを送信する機能を提供しており、レジストリは基本コマンドを変更することなく新しい機能を追加することができます。[ 1 ]

多くのレジストリで使用されている標準化された拡張機能がいくつかあります。これには、DNSSEC [ 17 ] 、IDN [ 18 ]、プレミアムドメイン名[ 19 ] 、ドメイン復旧（RGP）[ 7 ] 、新規TLDの立ち上げ[ 20 ]、レジストリメンテナンス[ 21 ]などを扱う拡張機能が含まれます。 [ 8 ]

一部のレジストリは、それぞれのTLDに固有の拡張子を開発しています。非標準化された拡張子の一般的な使用例は、ドメインの作成に必要な追加データ（例えば、VAT識別番号）の収集です。[ 8 ]

結果コード

サーバーからのすべての応答は、指定された形式に従う必要があります。各応答コードは、人間が判読できるメッセージに対応しています。形式1xxxのコードは正常な操作を示し、形式2xxxのコードはエラーを示します。エラーはさらに、形式20xxのプロトコル構文エラー、形式21xxの実装固有のルールエラー、形式22xxのセキュリティエラー、形式23xxのサーバーシステムエラー、形式25xxのコネクション管理エラーに分類されます。ほとんどの結果には、オブジェクトに追加データresData（例えば、必須パラメータが不足しているかどうかなど）が含まれる場合があります。[ 1 ]

レスポンスコード1001はオフライン処理を有効にします。例えば、ドメイン名レジストリがドメイン登録前に登録者を検証したい場合などが挙げられます。この場合、処理が完了するまでドメインは他のクライアントに対してブロックされ、クライアントはpollコマンドで取得できるpollメッセージによって通知されます。コード1300と1301はpollコマンド専用で、メッセージの有無を示します。[ 1 ]

標準化された結果コードと結果メッセージの完全なリストは次のとおりです：[ 1 ]

コード メッセージ
1000コマンドは正常に完了しました
1001コマンドは正常に完了しました。アクションは保留中です。
1300コマンドは正常に完了しました。メッセージはありません。
1301コマンドは正常に完了しました。キューから取り出すにはackが必要です。
1500コマンドは正常に完了しました。セッションを終了します。
2000不明なコマンド
2001コマンド構文エラー
2002コマンド使用エラー
2003必要なパラメータがありません
2004パラメータ値の範囲エラー
2005パラメータ値の構文エラー
2101実装されていないコマンド
2102実装されていないオプション
2103実装されていない拡張機能
2104請求失敗
2105オブジェクトは更新の対象外です
2106オブジェクトは譲渡できません
2200認証エラー
2201認証エラー
2202無効な認証情報
2300オブジェクトの転送保留
2301転送が保留されていないオブジェクト
2302オブジェクトが存在します
2303オブジェクトが存在しません
2304オブジェクトの状態により操作が禁止されています
2305オブジェクトの関連付けにより操作が禁止されています
2306パラメータ値ポリシーエラー
2307実装されていないオブジェクトサービス
2308データ管理ポリシー違反
2400コマンドが失敗しました
2500コマンドが失敗しました。サーバーが接続を閉じています。
2501認証エラー。サーバーが接続を閉じています
2502セッション制限を超えました。サーバーが接続を閉じています。

EPP オブジェクト ステータス コード

ステータスコードには、サーバーとクライアントの2種類があります。サーバーステータスコードはレジストリによってのみ設定および削除できますが、クライアントステータスコードは、サーバーステータスコードで禁止されていない限り、レジストラによっても設定および削除できます。[ 15 ]

サーバー ステータス コードは、ドメインの不正使用ケースを処理したり、ドメインのライフサイクル ステージをマークしたり、不正な改ざんに対する追加のセキュリティ (レジストリ ロックと呼ばれることが多いサービス) を提供したりするためによく使用されます。

クライアント ステータス コードは、不正使用ケース、未払い、無効な連絡先データ、またはレジストラ ロック機能の処理にも一般的に使用されます。

現在標準化されているサーバーステータスコードは以下のとおりです。[ 15 ] [ 7 ]

サーバーステータス 説明 ユーザーが必要とするアクション
期間を追加この猶予期間は、ドメイン名の初回登録後に設けられます。この期間中にレジストラがドメイン名を削除した場合、レジストリはレジストラに対し、登録費用を返金する場合があります。これはドメイン登録後数日間に表示される情報ステータスです。ドメイン名に問題はありません。
自動更新期間この猶予期間は、ドメイン名の登録期間が終了した後に設けられ、レジストリによって自動的に延長（更新）されます。この期間中にレジストラがドメイン名を削除した場合、レジストリはレジストラに更新費用を返金します。これは、レジストリによるドメインの自動更新後に一定期間設定される情報ステータスです。ドメインの保持（更新料の支払い）を希望されない場合は、直ちにレジストラにご連絡いただき、対応策についてご相談ください。
非アクティブこのステータスコードは、委任情報（ネームサーバー）がドメインに関連付けられていないことを示します。ドメインはDNSでアクティブ化されておらず、解決できません。ドメインが数日間このステータスのままになっている場合は、レジストラに連絡して処理の遅延に関する情報をリクエストすることをお勧めします。TLDが登録に書類の提出を求めている場合は、必要な書類を提出する必要がある可能性があります。
わかりましたこれはドメインの標準ステータスであり、保留中の操作や禁止事項がないことを意味します。レジストラに clientTransferProhibited、clientDeleteProhibited、clientUpdateProhibited などのステータス制限を制定するよう依頼すると、ドメインの不正な移管、削除、更新を防ぐことができます。
保留中作成このステータス コードは、ドメインの作成要求が受信され、処理中であることを示します。TLD が特別登録期間（サンライズなど）中の場合、ドメイン名はその期間の終了時に割り当てられる可能性があることを示している可能性があります。
削除保留中このステータスコードは、redemptionPeriod または pendingRestore と混在する場合があります。その場合、ドメイン名に設定されているステータス（償還期間または復元保留中）に応じて、上記の対応する説明が適用されます。このステータスが redemptionPeriod または pendingRestore ステータスと混在していないと仮定します。その場合、pendingDelete ステータスコードは、ドメインが redemptionPeriod ステータスになってから30日が経過し、その30日以内に復元されていないことを示します。ドメインはこのステータスのまま数日間保持され、その後、レジストリデータベースから消去され、削除されます。削除されたドメインは、レジストリのポリシーに従って再登録できます。ドメイン名を保持したい場合は、すぐにレジストラに連絡して利用可能なオプションについて話し合う必要があります。
保留中更新このステータス コードは、ドメインの更新リクエストが受信され、処理中であることを示します。ドメインの更新をリクエストしておらず、今後ドメインを保持する（つまり、更新料を支払う）必要がない場合は、すぐにレジストラに連絡して、利用可能なオプションについて相談してください。
復元保留中このステータスコードは、レジストラがレジストリにredemptionPeriodステータスのドメインの復元を依頼したことを示します。レジストリは、レジストラから必要な復元書類が提出されるまで、ドメインをこのステータスで保持します。レジストラが指定された期間内にレジストリオペレータに復元依頼の確認書類を提出しなかった場合、ドメインはredemptionPeriodステータスに戻ります。一般的に7日間と定められている期間内にドメインのステータスコードを確認し、レジストラが期限内に正しい復元書類を提出したことを確認してください。この期間が終了し、ドメインがredemptionPeriod（償還期間）ステータスに戻った場合は、レジストラに連絡して、ドメインに必要な復元書類の送付を滞らせている可能性のある問題を解決してください。
保留中の転送このステータス コードは、ドメインを新しいレジストラに移管するリクエストが受信され、処理中であることを示します。ドメインの移管をリクエストしていない場合は、すぐにレジストラに連絡して、移管リクエストを拒否するよう依頼する必要があります。
更新保留中このステータスコードは、ドメインの更新リクエストが受信され、処理中であることを示します。ドメインの更新をリクエストしなかった場合は、すぐにレジストラに連絡して問題を解決する必要があります。
償還期間このステータスコードは、レジストラがレジストリにドメインの削除を依頼したことを示します。ドメインは30日間このステータスで保持されます。償還期間の終了から5日後、ドメインはレジストリデータベースから削除され、登録可能になります。ドメインを維持したい場合は、レジストラがドメインの削除を要求し、ドメインがredemptionPeriodステータスになった原因となった問題を解決する必要があります。未解決の問題が解決され、適切な料金が支払われた後、レジストラはお客様に代わってドメインを復元します。
更新期間この猶予期間は、ドメイン名の登録期間がレジストラによって明示的に延長（更新）された後に提供されます。この期間中にレジストラがドメイン名を削除した場合、レジストリは更新費用をレジストラに返金します。これは、レジストラによるドメイン更新期間中に限って表示される情報ステータスです。ドメインの更新をリクエストしておらず、今後ドメインを保持（つまり更新料を支払う）したくない場合は、すぐにレジストラに連絡して、利用可能なオプションについてご相談ください。
サーバー削除禁止このステータスコードは、ドメインの削除を阻止します。これは稀なステータスで、通常は法的な紛争中、お客様のリクエスト時、または redemptionPeriod ステータスが適用されている場合に発生します。このステータスは、ドメインに解決が必要な問題があることを示している可能性があります。その場合は、レジストラに連絡して詳細情報を要求し、問題を解決してください。ドメインに問題がなく、単に削除したい場合は、まずレジストラに連絡して、レジストリオペレータと協力してこのステータスコードを削除するよう依頼してください。また、一部のレジストリオペレータは、登録者がレジストラを通じてこのステータスを設定することで、不正な削除に対する追加の保護策となるレジストリロックサービスを提供しています。このステータスの削除には、レジストラがリクエストをドメインレジストリに転送し、制限が解除されるのを待つ必要があるため、clientDeleteProhibited の場合よりも時間がかかる場合があります。
サーバーホールドこのステータスコードはドメインのレジストリオペレータによって設定されています。ドメインはDNSで有効化されていません。委任情報（ネームサーバー）をご提供いただいた場合、このステータスはドメインに解決が必要な問題があることを示している可能性があります。その場合は、レジストラに連絡して詳細情報をリクエストしてください。ドメインに問題はないが、DNSで名前解決する必要がある場合は、レジストラに連絡して必要な委任情報をご提供いただく必要があります。
サーバー更新禁止このステータスコードは、ドメインのレジストリオペレータがレジストラによるドメイン更新を許可しないことを示します。これは稀なステータスで、通常は法的な紛争が発生したときやドメインが削除対象になったときに発生します。多くの場合、このステータスはドメインに問題があることを示し、早急な対処が必要です。レジストラに連絡して詳細情報を要求し、問題を解決してください。ドメインに問題がなく、単に更新を希望する場合は、まずレジストラに連絡して、レジストリオペレータと協力してこのステータスコードを削除するよう依頼してください。このプロセスは、レジストラがリクエストをドメインレジストリに転送し、制限が解除されるのを待つ必要があるため、clientRenewProhibited の場合よりも時間がかかる場合があります。
サーバー転送禁止このステータスコードは、ドメインを現在のレジストラから別のレジストラに移管することを防ぎます。これは稀なステータスで、通常は法的紛争やその他の紛争発生時、お客様のリクエスト時、またはredemptionPeriodステータスが適用されている場合に発生します。このステータスは、ドメインに問題があることを示している可能性があり、早急な対処が必要です。レジストラに連絡して詳細情報を要求し、問題を解決してください。ドメインに問題がなく、単に別のレジストラに移管したいだけの場合は、まずレジストラに連絡して、レジストリオペレータと協力してこのステータスコードを削除するよう依頼する必要があります。また、一部のレジストリオペレータは、登録者がレジストラを通じてこのステータスを設定することで不正な移管に対する追加の保護策となるレジストリロックサービスを提供しています。このステータスの削除には、レジストラがリクエストをドメインのレジストリに転送し、制限が解除されるのを待つ必要があるため、clientTransferProhibited の場合よりも時間がかかる場合があります。
サーバー更新禁止このステータスコードはドメインをロックし、更新を不可能にします。これは稀なステータスで、通常は法的な紛争中、お客様のリクエスト時、または redemptionPeriod ステータスが適用されている場合に発生します。このステータスは、ドメインに解決が必要な問題があることを示している可能性があります。その場合は、詳細情報や問題の解決方法について、レジストラにお問い合わせください。ドメインに問題がなく、単に更新したいだけの場合は、まずレジストラに連絡し、レジストリオペレータと協力してこのステータスコードを削除するよう依頼してください。また、一部のレジストリオペレータは、登録者がレジストラを通じてこのステータスを設定することで、不正な更新に対する追加の保護策となるレジストリロックサービスを提供しています。このステータスの削除には、レジストラがリクエストをドメインレジストリに転送し、制限が解除されるのを待つ必要があるため、clientUpdateProhibited の場合よりも時間がかかる場合があります。
転送期間この猶予期間は、ドメイン名をあるレジストラから別のレジストラに移管した後に提供されます。この期間中に新しいレジストラがドメイン名を削除した場合、レジストリは移管費用をレジストラに返金します。これは、ドメインを新しいレジストラに移管する期間に限って表示される情報ステータスです。ドメインの移管をリクエストしていない場合は、元のレジストラにお問い合わせください。

現在標準化されているクライアントステータスコードは以下のとおりです。[ 15 ]

クライアントのステータス 説明 ユーザーが必要とするアクション
クライアント削除禁止このステータス コードは、ドメインのレジストリにドメインの削除要求を拒否するように指示します。このステータスは、ドメイン名登録を削除できないことを示します。これにより、ハイジャックや詐欺による不正削除を防ぐことができます。ドメインを削除したい場合は、まずレジストラに連絡して、このステータスコードの削除を依頼してください。
クライアントホールドこのステータスコードは、ドメインレジストリにDNSでドメインをアクティブ化しないよう指示し、結果としてドメインは解決されません。これは稀なステータスで、通常は法的な紛争、未払い、またはドメインが削除対象となっている場合に適用されます。多くの場合、このステータスはドメインに問題があり、解決が必要であることを示しています。その場合は、レジストラに連絡して問題を解決してください。ドメインに問題はないが、解決が必要な場合は、まずレジストラに連絡してこのステータスコードを削除するよう依頼してください。
クライアント更新禁止このステータスコードは、ドメインレジストリにドメイン更新リクエストを拒否するよう指示します。これは稀なステータスで、通常は法的な紛争やドメインが削除対象となっている場合に使用されます。多くの場合、このステータスはドメインに問題があり、解決が必要であることを示しています。その場合は、レジストラに連絡して問題を解決してください。ドメインに問題がなく、単に更新を希望する場合は、まずレジストラに連絡してこのステータスコードを削除するよう依頼してください。
クライアント転送禁止このステータス コードは、ドメインのレジストリに、現在のレジストラから別のレジストラへのドメインの移管要求を拒否するように指示します。このステータスは、ドメイン名登録の移管が不可能であることを示します。これにより、ハイジャックや詐欺による不正な移管を防ぐことができます。ドメインを移管する場合は、まずレジストラに連絡し、このステータスコードを削除するよう依頼してください。
クライアント更新禁止このステータス コードは、ドメインのレジストリにドメインの更新要求を拒否するように指示します。このドメイン名のステータスは、ドメインを更新できないことを示しています。これにより、詐欺行為による不正な更新を防ぐことができます。ドメインを更新したい場合は、まずレジストラに連絡して、このステータスコードを削除するよう依頼してください。

セキュリティに関する考慮事項

EPPはプレーンテキストパスワードのみを提供し、さらにEPPログインパスワードの種類は6～16文字の文字列と指定されています[ 1 ]。これは今日の標準からすると非常に短いと言えるかもしれません。したがって、TCP接続ではTLSを使用し、クライアント証明書の使用と、クライアントとサーバーの正しいID確認を強く推奨します[ 22 ] 。

多くのドメイン名レジストリでは、 EPP サーバーに接続するための IP ホワイトリストの設定も提供しています。

EPPは、クライアントが生成した を介したリプレイ攻撃に対してある程度の保護を提供しますclTRIDが、この要素はオプションであるため、すべてのサーバーソフトウェアで使用されるわけではありません。したがって、使用するトランスポートメカニズムには、追加のリプレイ防止メカニズムを実装する必要があります。[ 1 ]

  • RFC  3375、汎用レジストリ・レジストラプロトコル要件
  • RFC  5730、拡張プロビジョニング プロトコル (EPP) ( RFC  4930 を廃止し、 RFC 4930はRFC  3730を廃止しました)
  • RFC  5734、TCP 経由の拡張プロビジョニング プロトコル (EPP) トランスポート( RFC  4934は廃止)

EPP オブジェクト RFC

  • RFC  5731、拡張プロビジョニング プロトコル (EPP) ドメイン名マッピング( RFC  4931は廃止)
  • RFC  5732、拡張プロビジョニング プロトコル (EPP) ホスト マッピング( RFC  4932は廃止)
  • RFC  5733、拡張プロビジョニング プロトコル (EPP) 連絡先マッピング( RFC  4933は廃止)
  • RFC  8543、拡張プロビジョニングプロトコル（EPP）組織マッピング

EPP拡張RFC

  • RFC  3735、EPP 拡張のガイドライン
  • RFC  3915、ドメインレジストリ猶予期間マッピング（例：猶予期間の追加、償還猶予期間）
  • RFC  4114、拡張プロビジョニングプロトコル（EPP）のE.164番号マッピング
  • RFC  5076、拡張プロビジョニングプロトコルのENUM検証情報マッピング
  • RFC  5910、ドメインネームシステム ( DNS ) の拡張プロビジョニングプロトコル (EPP) のセキュリティ拡張マッピング( RFC  4310、DNSSEC は廃止)
  • RFC  8334、拡張プロビジョニングプロトコル (EPP) の起動フェーズマッピング
  • RFC  8495、拡張プロビジョニングプロトコル（EPP）の割り当てトークン拡張
  • RFC  8544、拡張プロビジョニングプロトコル（EPP）の組織拡張
  • RFC  8590、拡張プロビジョニングプロトコル (EPP) の変更ポーリング拡張
  • RFC  8748、拡張プロビジョニングプロトコル（EPP）のレジストリ料金拡張
  • RFC  8807、拡張プロビジョニングプロトコル（EPP）のログインセキュリティ拡張
  • RFC  9038、拡張プロビジョニングプロトコル（EPP）の未処理名前空間
  • RFC  9154、拡張プロビジョニングプロトコル（EPP）転送のための安全な認証情報
  • RFC  9167、拡張プロビジョニングプロトコル（EPP）のレジストリメンテナンス通知

参照

参考文献

  1. ^ a b c d e f g h i j k l m Hollenbeck, S. (2009年8月). 「拡張プロビジョニングプロトコル (EPP)」 . doi : 10.17487/RFC5730 . ISSN 2070-1721 . 
  2. ^ Hollenbeck, S. (2001-05-01). 「拡張プロビジョニングプロトコル」 . IETFデータトラッカー. 2023年3月13日閲覧。
  3. ^ 「IETF 2000年12月議事録」 . www.ietf.org . 2023年3月13日閲覧。
  4. ^ Hollenbeck, S. (2004年3月). 「拡張プロビジョニングプロトコル (EPP)」 . doi : 10.17487/RFC3730 . ISSN 2070-1721 . 
  5. ^ Hollenbeck, S. (2007年5月). 「拡張プロビジョニングプロトコル (EPP)」 . doi : 10.17487/RFC4930 . ISSN 2070-1721 . 
  6. ^ Hollenbeck, S. (2009年8月). 「拡張プロビジョニングプロトコル（EPP）」 .
  7. ^ a b c Hollenbeck, S. (2004年9月). 「拡張プロビジョニングプロトコル（EPP）のドメインレジストリ猶予期間マッピング」 . doi : 10.17487/RFC3915 . ISSN 2070-1721 . 
  8. ^ a b c「拡張プロビジョニングプロトコル（EPP）の拡張機能」 www.iana.org . 2023年3月11日閲覧。
  9. ^ 「RFC 4930-4934の実装レポート - Wayback Machine」 . 2012年1月15日. 2012年1月15日時点のオリジナルよりアーカイブ。2023年3月12日閲覧。{{cite web}}: CS1 maint: bot: 元のURLステータス不明（リンク）
  10. ^ 「ICANN基本レジストリ契約」newgtlds.icann.org . 2023年3月12日閲覧。
  11. ^ 「CoCCA公式ウェブサイト」 . 2023年3月12日閲覧。
  12. ^ 「FREDの紹介 - fred」fred.nic.cz . 2023年3月12日閲覧。
  13. ^ Hollenbeck, S. (2009年8月). 「拡張プロビジョニングプロトコル（EPP）ホストマッピング」 . doi : 10.17487/RFC5732 . ISSN 2070-1721 . 
  14. ^ Hollenbeck, S. (2009年8月). 「拡張プロビジョニングプロトコル（EPP）連絡先マッピング」 . doi : 10.17487/RFC5733 . ISSN 2070-1721 . 
  15. ^ a b c d Hollenbeck, S. (2009年8月). 「拡張プロビジョニングプロトコル（EPP）ドメイン名マッピング」 . doi : 10.17487/RFC5731 . ISSN 2070-1721 . 
  16. ^ Zhou, L.; Kong, N.; Yao, J.; Gould, J.; Zhou, G. (2019年3月). 「Extensible Provisioning Protocol (EPP) Organization Mapping」 . doi : 10.17487/RFC8543 . ISSN 2070-1721 . S2CID 65065583 .  
  17. ^ Gould, J.; Hollenbeck, S. (2010年5月). 「拡張プロビジョニングプロトコル（EPP）のためのドメインネームシステム（DNS）セキュリティ拡張マッピング」 . doi : 10.17487/RFC5910 . ISSN 2070-1721 . 
  18. ^ 「拡張プロビジョニングプロトコル（EPP）のための国際化ドメイン名マッピング拡張」 IETFデータトラッカー。 2023年3月11日閲覧。
  19. ^ Carney, R.; Brown, G.; Frakes, J. (2020年3月). 「拡張プロビジョニングプロトコル（EPP）のレジストリ料金延長」 . doi : 10.17487/RFC8748 . ISSN 2070-1721 . 
  20. ^ Gould, J.; Tan, W.; Brown, G. (2018年3月). 「拡張プロビジョニングプロトコル（EPP）の起動フェーズマッピング」 . doi : 10.17487/RFC8334 . ISSN 2070-1721 . 
  21. ^ Sattler, T.; Carney, R.; Kolker, J. (2021年12月). 「拡張プロビジョニングプロトコル（EPP）のレジストリメンテナンス通知」 . doi : 10.17487/RFC9167 . ISSN 2070-1721 . 
  22. ^ Hollenbeck, S. (2009年8月). 「TCP経由の拡張プロビジョニングプロトコル（EPP）トランスポート」 . doi : 10.17487/RFC5734 . ISSN 2070-1721 . 
「 https://en.wikipedia.org/w/index.php?title=Extensible_Provisioning_Protocol&oldid=1316327812」から取得