ドメインの連絡先の詳細を変更した後、60日間の「登録者ロックの変更」が存在するのはなぜですか？
ICANNが https://www.icann.org/resources/pages/name-holder-faqs-2017-10-10-en で列挙した状況はほとんどありませんレジストラがドメイン名の移管を拒否するのはなぜですか？セクションで、レジストラはどちらかmayまたはmustドメインの移管を拒否します。これらのいくつかには、特定のイベント後の60日間のウィンドウが含まれます。
これらの1つである、ドメインが別のレジストラから移管された後にレジストラが実装することを許可されている60日間のロックは、 なぜ各ドメイン移管の間に60日待たなければならないのですか？ 、根拠：異なるレジストラ間でドメインを転送できるレートを調整することにより、（迅速に発見された）ドメインハイジャックに関与する異なるレジストラの最大数が低く抑えられます。これにより、ドメインをハイジャックして正当な所有者に戻した後の一連のイベント。
ただし、これらの60日間のルールの別の1つは、レジストラがrequiredのいずれかの連絡後に課す60日間の「登録者の変更」ロックです。登録者の変更の詳細。このロックは上記の説明では正当化されていないようです。そのため、その存在には別の理由があると思いますが、私にはわかりません。ドメイン転送ロックがレジストラの裁量にある場合、それは何のためであり、なぜそれが必須なのですか？
レジストラ間の登録の譲渡に関するポリシー に記載されているように、レジストラは譲渡を行う前に登録名保有者から許可を得る必要があります。そのため、これらの連絡先の詳細はセキュリティの目的に役立ちます。これらは、レジストラがドメイン移管を実行する前に承認を確認するために使用する詳細です。
したがって、ロックはドメインのハイジャックを回避するのに役立ちます。ロックがなければ、レジストラへのログイン詳細を取得した誰かがドメインの連絡先メールアドレスを自分のものに変更し、転送を要求し、確認メールを自分で受信し、それを使用して転送を許可できます。 ロックでは、このようなハイジャックはすぐには実行できません。連絡先の詳細を変更せずに転送をリクエストした場合、確認メールを受信しません。また、連絡先メールを変更した場合、ロックが作動し、ハッカーの前に何かが間違っていることに気付き修正するための60日間を与えますドメインを盗むことができます。
以下に説明する理由により、問題はリンクしています。
しかし、最初に歴史に戻って状況を説明してください。実際には、主にgTLDと.COM/.NETをターゲットにしています。
- レジストリ/レジストラの分割が開始されたとき、通信に使用されるプロトコルはRRPでした（ RFC2832 を参照）。 4.3.10のセクションでわかるように、新しいレジストラはtransferコマンドを使用しました...ドメイン名以外は何も提供しませんでした
- もちろん、これはそれ自体で虐待が発生する可能性があることを意味するため、ICANNは現在の登録者（または管理連絡先）に事前の同意を求めるレジストラを義務付けるポリシーを起草しました。転送コマンドを起動する前に登録者に連絡できるようにwhois出力を解析して電子メールアドレスを取得する必要があったため、これは実際にはレジストラにとって悪夢でした。このポリシーは時間とともに進化し、その最新バージョンでは、登録予定者が再度登録者または管理者の連絡先に送信する必要がある特定の電子メールメッセージが義務付けられており、転送を進める前に特定の肯定的な確認を取り戻す必要があります
- この危険があっても、またはそれを軽減するために、多くのレジストラは、送信転送の通知時に顧客にメールを送信しました（レジストリから情報を取得します）。デフォルトでは、現在のレジストラは反対（何もしない場合、転送は承認されますが、現在のレジストラが適切なコマンドをレジストリに送信すると、その一部は顧客にこの機能を提供します）転送はブロックされますが、この5日間のみ
- 並行して、RRPは次第にEPPに置き換えられました（ STD69 を参照）。このプロトコルでは、転送の方法が少し異なります。アイデアは、各ドメイン名がプロトコルで
authInfoと呼ばれる「パスワード」を持ち、作成時に定義され（後で必要に応じて更新される）、通常は登録者（実際に現場で実際に起こったことではなかったため、レジストラはしばしば自分自身でそれを処理しました）;転送コマンドは、レジストラ候補がドメイン名とともにauthInfoを送信することを要求しました。レジストラ候補は、転送を開始する人が登録者または受け取った誰かであるため、この「パスワード」を取得したという考えです。登録者から与えられたauthInfo - この新しい保護を使用しても、ICANNポリシーは変更されなかったため、レジストラは、転送を試みる前に電子メールで肯定的な承認を送信し、取得するよう契約上義務付けられ、
authInfo（プロトコルで必須）。
これらの「保護」のすべてでさえ、「多くの」ドメインがさまざまな理由で盗まれるというフィールドで起こりました、そして、そうする人々は1つのレジストラから別のものに盗まれました、そしてそれは調査と操作の最終的なキャンセルの両方を複雑にしましたドメインがXからYに、次にZになった場合、解決はZからXに戻すことができず、Yを含める必要があるため、物事が長く複雑になりました。
したがって、作成または移管後の60日間のブラックアウト：ドメイン名が再び移動する前に、紛争を調査しながら少なくともドメインを凍結するためにドメインがレジストラに連絡するのに十分な時間を盗まれたと考える登録者を与えます。
このICANNポリシーの詳細は次のとおりです。 https://www.icann.org/resources/pages/registrars/transfers-en （およびコンセンサスポリシーとして、明示的に必要なく直ちに適用されます） ICANNによって認定されたレジストラまたはレジストリをどこでも参照できるため、これはgTLDのみに関係します。
ごく最近（2016年12月）だけで、ICANNは登録者の変更、特にそのメールにもポリシーを拡張しました。ここでレッドラインを見ることができます： https://www.icann.org/en/system/files/files/transfer-policy-redline-25may16-en.pdf
転送/作成後の遅延とは異なり、登録者の変更後の遅延はオプトアウトであるため、顧客が要求した場合、レジストラはそれを没収することができます。
なぜICANNが追加したのですか？それ以外の場合は、上記の手順全体が現在の登録者（または管理者の連絡先）に依存し、転送を開始するために電子メールに返信するため、明確な抜け穴があるためです。
そのようなドメインを盗むことを想像してください：authInfoコード（将来のレジストラに渡すため）と、メールアドレスを制御して "FOA"（収集するフォーマットされたメール）の両方が必要です承認）。デフォルトではできません。しかし、（フィッシング攻撃などの他のあらゆる種類の攻撃によって）正しい承認でレジストラパネルに接続する方法を見つけた場合、次の2つのことを提供する正しいレジストラントを変更できます。
- すべてのレジストラには現在の登録者にそれを与えるシステムがあるため、最初に
authInfoコードを簡単に取得できます。 - その後、任意の種類のメールを送信して、そこにFOAを受信して返信できるようにします。
前のすべてが成功した場合、転送を開始できます。また、5つの関係者がいるために元の登録者が突然苦情を申し立てた場合、トラブルシューティングが困難になります：レジストリ（ポリシーにより、レジストリが移管に関する紛争を処理する役割を持つことができます）、元のレジストラ、新しいレジストラ、現在のレジストラント、および前のもの。
現在、最新のICANNポリシーでは、たとえ登録者情報を変更できたとしても、転送を開始するまで60日間待つ必要があります。繰り返しますが、これにより、以前の登録者が問題が発生したことを検出する時間が長くなります（レジストラはアカウントの何かが変更されたことを彼に通知した可能性があり、上級ユーザーの場合はwhoisの出力を監視して違いがあるかもしれません...）、そしてそれを修正します。または、少なくとも転送を凍結して、問題が悪化しないことを確認します。
最後の点として、これらはすべて近い将来に変更され、最初のようにいくつかの健全な設定に戻る可能性があることに注意してください（問題を解決するためにポリシーとプロトコルを上下に重ねることで、問題が増えるだけです）。新しい欧州規制（GDPR）は、whoisとtransferの両方に影響を与えます。要するに、将来のレジストラが現在の所有者に電子メールを送信してその承認を得るのが非常に難しくなるということです。テーブルに関するICANNの現在の提案は、RDAPティアードアクセスを使用することです。これは機能する可能性がありますが、確かに時間がかかり、実際にシステムの改良（およびICANNによる以前の試みの変更よりも壊れたシステムの回避策です）グローバルなwhoisコンテンツリポジトリを作成するなど、システム全体がさらに間違った方向に進んでいました。別のソリューションがICANN内のワーキンググループによってテーブルに追加されました。 https://www.icann.org/en/system/files/files/gdpr-comments-contract-party-techops-icann-proposed- Compliance-models-08mar18-en.pdf
つまり、currentレジストラではなく、プロスペクティブレジストラが義務付けられます現在の所有者から承認を得るため。将来のレジストラは、プロトコルで要求され、転送を開始する顧客から取得したauthInfoを使用して、転送を開始するだけです。
誰かがあなたのドメインの登録者の連絡先の詳細を変更できた場合、すぐにそれを転送していただければ幸いですか？または、悪意のあるアクションを元に戻すことができるように、何らかの冷却期間を好むでしょうか？
これは、登録者の詳細（一部のみ）の変更後の60日間のロックのポイントです。
ICANNが許可するそのルールには「アウト」があります。多くのレジストラは、登録者がそのロックをオプトアウトする方法を追加しました。
なぜそのルールが存在するのですか？これは、ドメインのハイジャックを防ぐための方法です。 2要素認証を追加するなど、ドメインハイジャックを最小限に抑える他のより効果的な方法が他にもたくさんあるので、ほとんどのレジストラやレジストラントでさえ、このタイプのロックを要求していないと思います。