1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AWS上でホストゾーンを誤って消してしまった時の対処法

Posted at

はじめに

  • お名前ドットコムで取得したドメインをAWSのホストゾーンに設定していたケース
  • 表題の通り、AWSでホストゾーンを誤って消してしまった場合の対処法を説明
  • 記事を書いた理由としては、自分自身が誤って消してしまったときに戻し方がわからず苦労した箇所があったため

記事の内容

  • 誤ってAWS Route53のホストゾーンを消してしまったお馬鹿さんがホストゾーンを復元する方法

前提

  • 復元するホストゾーンの要件
    • 外部のドメインレジストラ(お名前ドットコム等)で発行されたドメインを指定
    • SSL認証済み
    • EC2インスタンスへのルーティング
  • そもそもホストゾーンとは何ぞやって人や、ドメイン取得からホストゾーンへの登録、ホストゾーンからアプリ(例としてEC2)への割り当て等々の方法が知りたい人は、以下の記事が分かりやすかったのでお勧めです

環境

利用サービス

  • お名前.com
  • AWS Route53

実施環境

  • Windows 11
  • Microsoft Edge

本題の目次

  • ホストゾーンを削除
  • 差分比較
  • ホストゾーンを再作成
  • 原因の説明
  • 対応内容

本題

ホストゾーンを削除

  • ホストゾーンの削除を行おうとすると、以下のような警告がAWSさんから表示されます
  • これに対して警告をしっかり読まず削除してしまったのが今回の事象です(まあ本番環境であればそんなことは中々ないでしょうが。。。)
    スクリーンショット 2025-03-23 235926.png

差分比較

  • 参考までにですが、上記を行った結果、画面表示やnslookupがどうなるかを添付します
    • 画面(対応前)
      スクリーンショット 2025-03-24 001633.png

    • 画面(対応後)
      スクリーンショット 2025-03-24 001807.png

    • nslookup(対応前)

    $ nslookup {FQDN}
     Server:         xxx.xxx.xxx.xxx
     Address:        xxx.xxx.xxx.xxx#xxx
     
     Non-authoritative answer:
     Name:   {FQDN}
     Address: yyy.yyy.yyy.yyy
    
    • nslookup(対応後)
    $ nslookup {FQDN}
    ;; Got SERVFAIL reply from xxx.xxx.xxx.xxx
    Server:         xxx.xxx.xxx.xxx
    Address:        xxx.xxx.xxx.xxx#xxx
    
    ** server can't find {FQDN} : SERVFAIL
    
    • 画面側では「DNS_PROBE_FINISHED_NXDOMAIN」、nslookupのレスポンスとしては「SERVFAIL」って言われてますね
    • どっちも、DNSの名前解決に失敗したよって意味だと思ってもらえれば大丈夫です

ホストゾーンを再作成

  • ということで、これを解決するために、消してしまったホストゾーンを再作成します
    • AWS Route53>ホストゾーンから「ホストゾーンの作成」を選択
      image.png
    • 登録したいドメイン名を入力して、「ホストゾーンの作成」を選択
      スクリーンショット 2025-03-24 003222.png
    • 以下の画面のようにNSレコードとSOAレコードが自動生成されます
      スクリーンショット 2025-03-24 003442.png
      ここで自分はこう思いました
      「お名前ドットコムで過去に入力したAWSのNSレコードの情報を、
      ここに記入してやれば名前解決してくれるのでは。。。?」
      まあうまく行かなかったからこれを書いているんですが、、、、


      具体的にやったこととしては(やったら面倒くさくなるので推奨しません)以下のように外部ドメインレジストラの管理画面に以前登録していたデータを確認し、それを上記のホストゾーンのNSレコードに貼り付けました
      スクリーンショット 2025-03-24 004006.png
      しかし、nslookupしてみても、名前解決ができている様子はありませんでした。。。
      反映に時間を要する可能性もあるとのことでしたが、半日ほど放置してもダメでした・・・

原因の説明

  • 素直に構築するときと同じことをやればよかっただけなのですが、一応上記でうまく行かない原因を記載
  • 断定はできていないのですが、おそらく以下の2点が原因になります

公式サイトより抜粋

ホストゾーンを作成する場合、Route 53 はホストゾーンに一連の 4 つのネームサーバーを割り当てます。ホストゾーンを削除して新しいゾーンを作成すると、Route 53 は他の一連のネームサーバー 4 つを割り当てます。通常、新しいホストゾーンのネームサーバーは、以前のホストゾーンのネームサーバーと一致しません。新しいホストゾーンのネームサーバーを使用するようにドメイン設定を更新しないと、ドメインはインターネット上で利用できなくなります。

  • NSレコード編集画面
    image.png

  • 要約すると、Route53のホストゾーンには作成時に4つのNSが割り当てられ、それらを一覧表示しているだけで、それを変えたからと言ってNSを作るわけじゃないよ。ただ、ホワイトネームサーバーのような許可されたNSの設定を行うユースーケースは存在する?ということでした

  • つまりは、Route53のホストゾーンで自動作成されたNSレコードは、特別な場合以外は変えるな(変えても意味がない)ってことですね。間違ってたら教えてください

対応内容

  • 上記から、ホストゾーン側のNSレコードを編集しても意味がないので、ホストゾーンに生成されたNSレコードの情報を外部のドメインレジストラ側に書き込む必要があります
  • そのため、原因の冒頭にも記載の通り最初に構築した手順を実施することが対処法となります
  • ただ、今回の目的上既存のリソースを削除する必要もあり最終的には以下のような対応を行いました
・ホストゾーンの再作成
・ALBのリスナーの再作成(SSL証明書を割り当てていたため)
・SSL証明書の再作成とホストゾーンへの再割り当て
・ALBをホストゾーンのAレコードに割り当て

終わりに

  • AWSリソースは無暗に消さないようにしようね()

その他参考にした記事

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?