ウェブホスティング

技術的観点からのドメイン移管プロセス完全な手順

について説明する。 ドメイン移管プロセス ロック解除からレジストリでの最終確認まで、ステップ・バイ・ステップで技術的に行う。このようにして、認証コード、EPPプロセス、および DNSアップデート ウェブサイトとEメールにアクセスできるよう、クリーンな状態を保つ。.

中心点

ロック解除 とオーナーデータのチェック
認証コード 時間内のリクエスト
イーピーピー-新しいレジストラで転送を開始する
DNSアップデート 事前準備
TLDルール 期限を守る

準備：ドメインのロック解除とデータのチェック

まずは移籍のロックから。 レジストラ・ロック をカスタマーポータルに入力し、変更が可能であることを確認します。その後、WHOISのコンタクトデータ、特に 電子メール を確認する。詳細が一致しない場合、プロセスは不必要に長い時間停止することが多い。また、後で確実な比較ができるように、現在のセットアップを文書化しておく。最後に、技術的な手順を忘れないようにチェックリストを作成する。.

スタート前のDNS戦略

生産的な移動の前に、私は次のことを計画する。 DNSアップデート 失敗を避けるためにアクティブにする。新しいプロバイダーと同一のDNSゾーンを設定し、A、AAAA、MX、CNAMEレコードをテストする。外部のネームサーバーを使用している場合は、変更中もサーバーを維持できるので、リスクを大幅に軽減できる。私はTTL（time-to-live値）をチェックし、世界的に変更がより早く届くように、的を絞った方法で値を下げます。このガイドは、私がエラーを回避するのに役立つ：移籍時のミスを防ぐ, これはスタート前に一度、確認する。.

認証コード(EPP)を安全に要求する

なし 認証コード 一度も転送が実行されていません。私は自分のアカウントで前のレジストラからコードを要求するか、サポートに要求します。多くのコードは約30日間有効なので、速やかに使用しています。.deについては、問題が発生した場合、私は担当オペレータを介して代替コード（AuthInfo2）を開始することができます。私はコードを暗号化して保存し、安全でない通信手段で共有することはありません。 電子メール.

新しいレジストラで転送を開始する

私は新しいプロバイダーで実際の変更を開始し、ドメインを入力し、次のように入力します。 認証コード を正しく実行する。バックグラウンドでは、システムはレジストリ用のXMLベースのプロトコルであるEPPを介して通信します。新しいレジストラがリクエストを送信し、レジストリがチェックして古いプロバイダに通知します。gTLDの場合、しばしば短い異議申し立て期間があり、その後レジストリがドメインを移管します。完全なプロセスをコンパクトに読みたい場合は、このガイドをご覧ください：レジストラを変更する手順, これは、私がクイックリファレンスとして気に入っているものだ。.

レジストリにおける技術的プロセス

その道筋を理解してもらうために、技術的なステップを分かりやすくまとめ、次のように説明する。 フォーカルポイント EPPと確認について最初に、新しいレジストラはドメインと認証コードを含む移管リクエストをレジストリに送信します。その後、ステータスチェックが行われます：所有権、ブロック、期限、および異議申し立て。旧レジストラは同意することも、沈黙を保つこともできます。期限後に応答がない場合は、通常は承認を意味します。承認後、レジストリは新レジストラにドメインを割り当て、連絡先、ネームサーバー、およびドメイン名を更新します。 ステータス.

EPPステータスコードの使用

ハンガーについては次のように書いてある。 EPPステータスコード 問題がどこにあり、どのような対処が必要かを明確に示しているからだ：

オーケーすべての準備が整った。転送を開始することができます。.
クライアント転送禁止レジストラのロックが有効です。アカウントのロックを解除します。.
サーバー転送禁止レジストリまたはポリシーブロック（例：プロシージャ/UDRP）。サポートに理由を明らかにします。.
転送保留移籍は進行中だ。期限を待つか、確認メールをチェックします。.
償還期間 / ペンディング削除削除サイクルに入ったドメイン。移管はブロックされ、まず回復が可能で、次に移管。.
クライアント更新禁止アップデートがロックされている。私は変更を加える前に追加のロック（レジストリロック）を削除します。.

私は、gTLDに加え、次のことも認識している。 認証コード という言葉からますます TAC (Transfer Authorisation Code）-原則は同じである：譲渡を正当化する期間限定の機密トークンである。.

ロック、60日ルール、許容される不合格

私は、見落とされがちなポリシーのためのタイムバッファを計画しています。登録または移管が成功した後、多くのレジストラは 60日間ロック, この期間は通常、それ以上の移管は拒否されます。登録者の変更も、事前にオプトアウトが設定されていない限り、gTLDのブロッキング期間を引き起こす可能性があります。旧レジストラから許されるNACK理由には、アクティブブロック、支払い不足、アイデンティティの衝突、法的手続きなどがあります。これらの理由のいずれにも該当しない場合、理由なく移管を延期すべきではありません。したがって、私は事前に次のことを確認します。ブロックされていないか？連絡先は正しいか？そうすれば、不必要なループを避けることができます。.

失敗のないDNS更新

私は、サイトを立ち上げる前にDNSゾーンを制御された方法で反転させることで、サイトへのアクセスを維持している。 TTL より低い。グローバルなディストリビューション（伝播）では、解像度に短時間の違いが生じることがあります。私はいくつかのネットワークからターゲットをテストし、digやnslookupなどのツールでAレコードとMXレコードをチェックします。必要であれば、すべてのキャッシュが変換されるまで、一時的に両方のインフラを並行してセットアップします。タイムウィンドウの詳細も知りたい場合は、以下のメモを参考にしてほしい。期間.

DNSSECのクリーンな移行

と一緒に ディナセック 私はレジストリのDSエントリを考慮に入れている。ネームサーバーが変更され、キーが変更された場合、私には2つの安全な戦略がある：

隙間のあるコンバージョン： 私は、切り替えの直前にレジストリからDSを削除し、グローバル更新を待ち（TTLが低いと便利）、新しいネームサーバーに切り替えてから、新しいDSを設定する。これにより、不正な署名によるSERVFAILを避けることができる。.
シームレスなロールオーバー： 新しいDNSKEYを並行して保管し（KSKロールオーバー）、署名してからDSを更新する。その後、古い鍵を削除する。これにより、厳密な検証を行うリゾルバでの検証リスクを低減できる。.

レジストリとプロバイダーをサポート CDS/CDNSKEY, DSのアップデートは部分的に自動化できる。自動化しない場合、私は手動でシーケンスを制御し、故障の際にすぐにダブルチェックできるように時間を記録する。.

子ネームサーバーとグルーレコード

ドメインが独自のネームサーバーを使用している場合（たとえば. ns1.mydomain.tld)、存在する ホスト・オブジェクト／グルー・レコード を登録します。ここでは別に計画している：

移行する前に、新しいインフラからホストオブジェクトにIPを追加して（デュアルスタック、デュアルプロバイダー）、移行フェーズでも確実に解決できるようにします。.
移管後、すべてのキャッシュが新しいパスを安全に指すようになったら、古いIPを再び削除する。.
私は、新しい登録サーバーがホストオブジェクトの管理を直接サポートしているかどうかを調べます。もしそうでなければ、私は両方のサポートと密接に変更を調整します。.

これにより、子ネームサーバー上のドメインが、移管の結果、予期せず解決不能になることを防ぐことができる。.

TLDの仕様と期限

締め切りと承認はエンディングによって変わるので、私はそのあたりをよく見ている。 ティーエルディーディー. .comや.netのようなgTLDは通常、変更が有効になる前に数日間の異議申立期間を設けます。.deは、有効なコードが利用可能になると、ほぼリアルタイムで移動します。国別コード拡張子（ccTLD）は、それぞれ異なる動作をし、独自のルールに従います。以下の概要は、最も重要なポイントを分類したものです。 プランニング.

ティーエルディーディー	移籍プロセス	特別な機能	コード/確認	ネームサーバーの動作
.com / .net / .org	EPP経由の要請、短い異議申立期間	旧ページへのアクセスは正しいまま DNS-準備	認証コード必須、所有者はメールを受信	事前に新しいゾーンを設定するか、外部のネームサーバーを保持する
ドットデ	コード入力後のリアルタイム転送	オプションで代替コード(AuthInfo2)を指定可能	認証コードは必須、確認は多くの場合プロセス内で直接行う	古いゾーンはキャンセルできるので、新しいプロバイダーのゾーンを用意する。
ccTLDs（各種）	レジストリによって大きく異なる	一部追加証拠または期限	時にはコード、時には他のリリース	外部のネームサーバーが残っているかどうかを事前にチェックする

決済、条件、満期フェーズ

を失う。 拡張ロジック は見えない：多くのgTLDでは、移管に成功すると期間が1年延長されます（上限あり）。.deを含むいくつかのccTLDは、移管中にこの自動延長がありません。ドメインの有効期限が迫っている場合、嫌なサプライズを避けることができます：

ギリギリになってから移管を始めることはない。もしドメインが グレース- または 償還段階, 移籍はしばしば阻止されるか、回復後にしかできない。.
旧レジストラとの自動更新は、中間請求書につながる可能性があります。成功した移管後、gTLDの場合、これらはしばしば取り消されます。私は日付を明確に文書化します。.
変更後、新しいレジストラで以下のようにアクティベートしました。 自動更新 隙間がないように。.

スケジューリングとTTLタイムテーブル

重要なプロジェクトのために、私は少額の資金を確保している。 ランブックプラン 右だ：

T-7日からT-3日： ゾーンをミラーし、監視を設定する（HTTP、MX、DNS）。関連レコードのTTLを300～600秒に短縮する。.
T-2日： 認証コードをチェックし、ロックを解除し、連絡先を再検証する。.
T-1日目： 最後のゾーン同期を実行し、DNSSECプラン（DSの削除またはロールオーバー）を実施する。.
T（ピーク時以外）： 転送を開始し、両方のポータルでログとステータスを監視する。.
TからT+1へ： 買収成功後、テストを繰り返し、DS/記録を確定し、古いインフラを整然と解体する。.
T+2: TTLを徐々に引き上げ、最終的な文書化を行う。.

よくあるつまずきを避ける

私は古いWHOISデータを避けている。時間. .アクティブな転送ロックはすべてのスタートをブロックするので、まずそれをチェックする。TTLの値が高すぎると伝搬が長くなるので、あらかじめ下げておく。新旧プロバイダーのゾーンレベルが異なると、解決に一貫性がなくなる。そのため、私は開始前にレコードを入念にチェックし、それぞれを文書化する。修正.

メールとホスティングの移行を別々に計画

転送はレジストリに影響するだけで、ファイルやメールボックスには影響しない。 クリア. .SFTPまたはバックアップ・リストアを使ってウェブ・コンテンツを移行し、本番稼動前にテストします。IMAP同期またはエクスポート/インポートを使用してメールボックスを移動し、メッセージが欠落しないようにします。SPF、DKIM、DMARCを新しいゾーンにきれいに移行します。すべてが整ってから、再びTTLを増加させ、新しいゾーンをバックアップします。 安定性.

メール配信と並行運用

私が特に考えているのは 電子メール-フロー。切り替えの間、受信メールがリゾルバによって古いMXになることもあれば、新しいMXになることもあります。私はこのように対処しています：

量が多い場合は、メールボックスの構造を変更するために短いフリーズフェイズを計画し、シフトが失われないようにする。.
必要であれば、私は デュアル・デリバリー (一時的に2つのMXターゲット）あるいは、両方のバックエンドにサービスを提供する中央リレー（十分に投与され、制御されている）。.
転送後、私はSPF、DKIM、DMARCを再度検証し、DMARCレポートを使って受信者の評価をチェックする。.

変更後のセキュリティチェック

移行に成功した後、私は 移籍禁止 また顧客アカウントに2ファクタ認証を設定し、認証コードの履歴を確保する。WHOISの詳細を再度チェックし、可視性とデータ保護が正しいことを確認する。DNSSEC、SPF、DKIMのエラーはすぐに修正する。最後に、すべての手順を文書化し バックアップ 準備はできている。

リワークモニタリング、自動更新、監査

をチェックする。 自動更新-を設定し、利用可能であれば、有効期限が切れる前に通知を設定します。私は、ウェブサイト、APIエンドポイント、MX、SPF/DKIMチェック、DNSSECについて、24～48時間のアクティブモニタリングを実行し、キャッシュのエッジケースを捕捉しています。監査のために、スクリーンショット、エクスポートファイル、ゾーンステータス、EPPイベントをアーカイブしています。. 転送保留 → オーケー)を明確に文書化することができる。.

プライバシー、RDAP、コンタクトチャネル

アクティブ プライバシー/プロキシ 確認メールが私に届くようにしています（転送は機能し、チケットシステムはフィルタリングされません）。レジストラによっては、WHOISの代わりにRDAPベースのコンタクトチャネルを使用するところもあります。私は、登録された電子メールを一貫性のあるものに保ち、検証ブロックが有効にならないように、転送の直前に自発的に連絡先を変更することは避けています。.

国際化ドメイン（IDN）

時点では IDN スペルをチェックし ピュニコード すべてのシステムで一貫して私は、証明書（SANエントリ）、リダイレクト、およびASCIIラベルしか受け付けない可能性のあるアプリケーションをチェックします。移転しても何も変わりませんが、並行して行われるDNSの再編成中にエラーが忍び込む傾向があります。.

スタックの移動と整理

複数のドメインを移管する場合は、それらをまとめて スタック・トランスファー 標準化されたTTL戦略、認証コードと期限の中央テーブル、明確なエスカレーションパス。私は重要なゾーン（SSOプロバイダーやMXなど）に優先順位をつけ、監視を強化するようにしています。これにより、私は概要を把握し、チーム内のコンテキストの変更を減らすことができます。.

トラブルシューティング：転送がハングする場合

プロセスが行き詰まったら、私は明確な方法を見つける。 リスト から。私はロック、コードの有効性、オーナーメール、ネームサーバーエントリーをチェックします。その後、新しいレジストラにステータスログを要求し、古いプロバイダにレジストリにフィードバックを送信するよう依頼します。.deの場合、新しいコードを要求し、プロセスを再開します。疑わしい場合は、DNSが一貫性を持つまで、生産的な切り替えを一時停止します。 トラブルフリー が実行されています。

簡単にまとめると

を持っている。 ドメイン移管プロセス タイト：まずブロックを解除してデータをチェックし、認証コードを保存してからEPP転送を開始。同時に、新しいプロバイダーでDNSゾーンを設定し、TTLを下げる。期限中は、ステータスメッセージを監視し、解決とメールをテストする。転送が終わったら、転送ブロックをアクティブにし、セキュリティチェックを設定し、TTLを再び上げる。この順序を守れば、管理された方法でドメインを移動し、安全に保つことができる。 アクセシビリティ.