イベント用サブドメインを別の DNS 事業者へ委任するための引き継ぎ表

子ゾーンが本当に必要か判断する

編集可能なサブドメイン引き継ぎ表をダウンロード（英語のMarkdown）

事業者が一つのホストを自社サービスに向けるだけなら、親ゾーンの A、AAAA、CNAME で足りることがあります。別の運用者が複数種類のレコードや下位ホストを含む名前空間を管理するなら、委任を検討します。まず相手の正確な DNS 要件を確認してください。TXT 検証や CNAME の依頼を NS 委任の依頼と読み替えないでください。[1][2]

AWS は、サブドメインのレコードを親ゾーンに置く方法と、別の子ゾーンに置く方法を説明しています。Cloudflare も委任を説明しますが、自社の子ゾーン設定には製品・プラン上の制限があります。実際の構成と利用資格を確認してください。[1][3]

親と子の DNS 担当者を決める

登録済みドメイン、子ゾーンの正確な名前、双方の権威 DNS 事業者、変更権限を持つ担当者を記録します。親側が委任点の NS を管理し、子側がその下の応答を管理します。レジストラで登録ドメイン全体のネームサーバーを変更する作業は別です。tickets.example.org だけの委任に混ぜないでください。[1]

イベントページ、購入、登録、確認、メール、証明書検証、事業者検証のうち子の名前に依存するものを列挙します。公開 DNS とプライベート DNS のどちらが必要かも確認します。プライベートゾーンだけでは公開委任は成立しません。利用者への影響を承認する主催者と、技術的に検証する担当者を定めます。[1]

親を変更する前に子ゾーンを準備する

子側の最新手順に従いゾーンを作成します。付与された実際の権威ネームサーバーを転記し、記事の例示値は使いません。委任点とその下の既存レコードを棚卸しします。必要な Web、TXT、MX などのレコードを子ゾーンに用意し、親の変更前に子の権威サーバーへ直接問い合わせます。応答と UTC 時刻を保存します。[1]

AWS は、移行中に親と子でデータが重なると、リゾルバーが保持する権威情報によって応答が異なり得ると説明します。旧レコードの削除時点を計画し、子が答える前に稼働中のものを消さないでください。DNSSEC を使う場合は、両運用者が対応手順に沿って子の署名と親の DS を確認します。DS 値を推測しないでください。[1][3]

委任を公開し権威の経路を確認する

子ゾーンの準備と承認後、親側が子ゾーンの正確な名前に対して、子側から提示されたネームサーバーの NS を公開します。親の権威サーバーの NS 応答、子の権威サーバーのサービスレコードを順に確認します。キャッシュ更新中は複数の独立した再帰リゾルバーの結果も比較します。公開検索で NS が正しくても、購入フローの成功は別途確認が必要です。[1]

イベントページ、チケット・登録リンク、確認、当該名を使うメールを実際に試します。証明書と検証状態はサービス側の画面でも確認します。時刻、確認者、リゾルバーを記録します。TTL やキャッシュは異なるため固定の反映時間を約束しません。結果が食い違えば、依存する変更を止め、承認済みの切り戻しまたはエスカレーションを行います。[1]

切り戻しと保守の責任を残す

切り戻しには親ゾーンの編集者、旧レコード、判断者が必要です。親へ戻しても子側の応答がキャッシュに残る可能性があります。リゾルバーが子の NS を利用し得る間は、子ゾーンやレコードを閉じないでください。安定後、事業者の計画に従って親側の不要な重複を整理し、変更前後の証拠を保存します。[1]

子ゾーンの保守、将来の TXT・証明書対応、支払い、アクセス点検、イベントや契約終了時の委任解除の担当を決めます。放置された委任は次の開催時の見えない依存関係になります。ドメイン台帳に次回点検日とともに記録します。権威を親へ戻す際も、別の DNS 変更として準備と利用者テストが必要です。[1]

編集可能な引き継ぎ表を使う

ダウンロードできる表は、判断、依存レコード、担当者、事前確認、観測結果、終了時の引き継ぎを分けています。子ゾーンごとに一枚作り、DNS 変更承認とともに保管します。事業者共通のコマンド手順ではありません。パスワード、API トークン、移管コード、秘密鍵は書かないでください。[1]

Boletolibre.com でイベントページやリンクを管理する場合は、実際の公開ホスト名と参加者の操作を依存一覧に記録してください。そのホスト向けに提示された DNS 手順を使い、Boletolibre がレジストラや権威 DNS を運用するとは仮定しないでください。[1]