解決した課題

  • 自社ドメインの設定を変更した直後から、ホームページが表示できない／メール送受信ができない状態になった。
  • ドメイン自体は失効していないが、外部からの名前解決が期待通りに動かず、各サービス（Web・メール）に到達できない状況が発生した。

対応内容

  • 原因条件の整理：レジストラ移管（引っ越し）後に、移管先へDNSゾーン（既存DNSレコード）が自動で引き継がれず、必要レコードが欠落した可能性を前提に調査を開始。
  • 現状確認：移管後ドメインのネームサーバ設定（NS）がどこを指しているかを確認し、運用想定（旧DNSで継続か／新DNSへ切替か）と差分を把握。
  • DNSレコード棚卸し：旧環境で運用していたDNSレコード（A/AAAA/CNAME、MX、TXT（SPF/DKIM/DMARC）、必要に応じてSRV等）を洗い出し、現行DNSゾーンに存在するかを突合。
  • 復旧方針の決定：以下いずれかで復旧する方針を採用（状況により選択）。
    • 旧DNSに戻す：NSを旧DNS事業者へ戻し、短時間で復旧させる（旧DNSが生きている場合）。
    • 新DNSへ正しく移す：欠落レコードを新DNSに再作成し、NSは現状維持のまま復旧させる。
  • レコード再構築（新DNSへ移す場合）：
    • Web：ホームページ到達に必要なA/AAAA/CNAME、CDN/WAF/ロードバランサ等のエンドポイントを再設定。
    • メール：MXの復元、送信ドメイン認証（SPF/DKIM/DMARC）のTXT復元、必要に応じてサブドメインやメール用CNAMEを復元。
    • 付随：自動更新検証（ACME/証明書）や外部サービス連携（Google/Microsoft等）で要求されるTXTレコードの復元。
  • TTL設計：復旧作業中はTTLを短めにし、安定後に通常値へ戻す（DNSキャッシュ影響を低減）。
  • 反映確認：外部からの名前解決（複数のDNSリゾルバ）と、Web表示／メール送受信の実動作で復旧を確認。
  • 再発防止：移管前チェックリスト（DNSエクスポート／レコード一覧化／NS切替手順／切替タイミング）を整備し、移管作業を標準化。

結果

  • 欠落していたDNSレコードを復元し、ホームページの表示およびメール送受信が段階的に復旧した。
  • 送信ドメイン認証（SPF/DKIM/DMARC）も再設定し、メール到達性の低下や迷惑判定のリスクを抑制した。
  • レジストラ移管時にDNSが自動継承されないケースを前提とした手順とチェック項目を作成し、同種トラブルの再発確率を低減した。