はじめに
Route 53の画面を見ていて、「消していいのかな？」と思うドメインを見つけたことはありませんか？
私も実際にこの状況に遭遇し、"どう確認すれば、安全と判断できるのか" で迷いました。
本記事では、Route 53で使われているか分からないドメインや設定を、安全に整理する手順を解説します。
記事を読み進める前に
この記事では、以下の前提で話を進めていきます。
- Route 53でホストゾーンやドメインを管理している
- 用途不明なレコードやホストゾーンが存在している
「削除しても問題なさそうだけど、念のため確認しておきたい設定がある」という方は、ぜひこの記事を参考に整理してみてください。
Route 53の基本構造
まずはRoute 53の基本的な役割を簡単に説明します。大きく分けて2つあります。
- ドメイン登録機能：ドメインの取得・更新を管理
- DNS管理機能：ホストゾーンでDNS設定を管理
Route 53
├── [ドメイン登録] example.com
│ └── (レジストラとしてドメインを管理)
│
└── [ホストゾーン] example.com
├── [レコード] www.example.com (A)
├── [レコード] api.example.com (A)
└── [レコード] test.example.com (A)
ドメイン
- example.com のような、インターネット上の住所そのものです
- ドメインを削除すると、DNS による名前解決ができなくなるため、ユーザーが example.com にアクセスしようとしても、本当の住所（IPアドレス）が取得できなくなります
- 住所が分からないため、WebサイトやAPIエンドポイントなど、そのドメイン配下のすべてのサービスがアクセスできなくなります
ホストゾーン
- 特定ドメインのDNS設定をまとめて管理する場所です
- たとえば example.com に対して AレコードやCNAMEなどを登録するのが、このホストゾーンです
- パブリックホストゾーン：外部（インターネット）向けの名前解決を行う
- プライベートホストゾーン：VPC内部でのみ有効なDNS設定を持つ
レコード
- 実際の名前解決ルールを定義する設定項目です
- 「どのドメイン名を、どのIPや別ドメインに紐づけるか」を指定します
| 種類 | 役割 | 例 |
|---|---|---|
| Aレコード | ドメイン名 → IPアドレス | www.example.com → 1.2.3.4 |
| CNAMEレコード | ドメイン名 → 別ドメイン名 | api.example.com → api.elb.amazonaws.com |
| TXTレコード | 任意の文字列（認証・検証用） | SPF/DKIM設定など |
| MXレコード | メールサーバの設定 | example.com → aspmx.l.google.com |
詳しく知りたい方はRoute 53公式ドキュメントを参照ください。
削除までの流れ
削除の判断は、次の5つのステップで進められます。
調査の段階で「明らかに不要」と判断できる場合は、すべてのステップを踏まずに削除して大丈夫です。
- レコードの用途を調べる
- Route 53の設定が使われているか確認する
- HTTPS証明書に使われていないか確認する
- アクセスログで利用状況を確認する
- 保留期間を設けて削除を実行する
それぞれのステップを詳しく見ていきましょう。
1. レコードの用途を調べる
レコードの用途を特定するために、以下の方法で調査します。
チーム内で確認してみる
わざわざ書くほどでもないかもしれませんが、最初にチームへ一言確認しておくのが早いです。
Slackで軽く聞いたり、過去のログを該当のドメイン名などで検索するだけでも、用途や経緯が分かることがあります。
もしこの時点で「もう使っていない」と分かれば、それ以上深掘って調査する必要はなくなります。
IaCコードを検索する
Terraform、CDK、CloudFormation等でインフラを管理している場合は、コード内を検索してみます。
見つかった場合は、コメントやGitのコミット履歴から用途が分かるかもしれません。
注意：使っていないが保有しておくべきドメインもある
「現在は使用していない」と判明した場合でも、ドメイン的に価値があり、持ち続けるべきケースがあります。
以下のような理由で保有している可能性があるため、削除前にチームで確認しましょう。
- 将来のプロジェクトやサービスで利用予定
- 既存ブランドや社名との関連がある
- 第三者による悪用（なりすまし・フィッシング等）を防ぐ目的
- 過去に使用していたサービスの再利用・リダイレクト用
2. Route 53の設定が使われているか確認する
このドメインのDNSが現在もRoute 53を使って解決されているかを確認します。
Route 53がこのドメインのDNSを管理していない場合、そのゾーン上のレコードは既に参照されていない可能性があります。
確認方法
dig NS example.com
判断
NSレコードに awsdns が含まれている場合：
example.com. IN NS ns-123.awsdns-12.com.
example.com. IN NS ns-456.awsdns-34.net.
→ Route 53 がこのドメインの DNS を管理している
この場合、削除はまだ保留にします。
NSレコードに awsdns が含まれていない場合：
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
→ 他社のネームサーバーを使用している、または応答なし
この場合は、Route 53上のレコードは参照されていない可能性が高く、削除候補になります。
nslookup/dig で No answer となる場合
外部から問い合わせても No answer と表示される場合は、該当ドメインが名前解決できない状態になっています。
具体的には、次のようなものが考えられます。
- DNS を別サービスへ移行済みで、Route 53 側が参照されていない
- レコード自体が削除されている
- ホストゾーン自体が削除済み（Route 53 にゾーンが存在しない）
- VPC 内専用の Private Hosted Zone で管理されている
外部から解決できない場合は、Route 53 が現在利用されていない可能性が高いですが、Private Hosted Zone の場合は VPC 内部からも確認しておくと安全です。
3. HTTPS証明書に使われていないか確認する
次に、削除しようとしているレコードが HTTPS証明書の検証に使われていないかを確認します。ACMで発行した証明書は自動更新されますが、この検証用レコードを削除すると更新が失敗します。それにより証明書が失効し、WebサイトがHTTPSでアクセスできなくなります。
注意すべきレコードの特徴
次のような特徴がある場合は、この検証用レコードである可能性が高いです。
| 項目 | 例 | 特徴 |
|---|---|---|
| レコード名 | _a79865eb4...b4e0b96.example.com |
アンダースコア + 約30文字のトークンで始まる |
| タイプ | CNAME |
CNAMEレコード |
| 値 | _xxx.acm-validations.aws. |
.acm-validations.aws.で終わる |
確認手順
- AWSマネジメントコンソール → Certificate Manager（ACM） を開く
- ALB用などはサービスを使用しているリージョンを確認
- CloudFront用の証明書は us-east-1（バージニア北部） を確認
※CloudFrontはグローバルサービスだが、証明書は us-east-1 で管理される
- 検索窓で該当ドメインを入力
- 対象の証明書を開き、ステータスと使用状況を確認する
ACMで証明書が見つかり、発行済みまたは使用中の場合は削除しないでください。証明書が見つからない場合は、過去に使われていた検証レコードの残骸で、削除できる可能性があります。
4. アクセスログで利用状況を確認する
念のため、アクセスログやDNSクエリログを確認しておくとより確実です。
確認方法
削除予定のドメインが過去2〜4週間以内にアクセスされていないかを確認します。
確認できるログの例：
- ALB / CloudFront：S3に出力されたアクセスログを確認
- EC2 / ECS：CloudWatch Logs Insightsでアクセスログを検索
- Route 53：クエリログでDNS問い合わせを確認
クエリログを有効化していない場合は、ALBやCloudFrontなどのアクセスログで代替確認できます。
最近アクセスがあれば削除は控えましょう。アクセスがなくても、年に数回だけ実行される処理で利用されている場合があるため、念のためチームにも確認しておくと安心です。
別途確認が必要なケース
以下のレコードは通常のアクセスログで状況を確認できないため、個別の確認が必要です。
- Private Hosted Zone：VPC内のみで解決される。VPC内で
nslookupを実行して確認 - NSレコード（子ゾーン委任）：削除するとサブドメイン全体が解決不能になる
- MX / TXTレコード（メール関連）：SPF / DKIM / DMARC設定に影響する
5. 削除を実行する
ここまで確認して「削除しても問題なさそう」と判断できたら、実際に削除を行います。
削除対象の整理
削除できる対象は、これまでの調査結果によって異なります。
| 対象 | 状況 | 備考 |
|---|---|---|
| レコード単位 | 特定の設定のみ不要な場合 | Aレコード、CNAME、TXTなど。対象だけ削除すればOK。 |
| ホストゾーン単位 | ドメイン全体をRoute 53で使っていない場合 | 外部DNSに移行済みであれば削除可能。 |
| ドメイン全体 | ドメインそのものが不要な場合 | ドメインを削除すると、関連するホストゾーン・レコード・ACM証明書もまとめて整理できる。 |
| ACM証明書 | HTTPSが不要になった、または別ドメインへ移行した場合 | CloudFrontやALBに紐づいていないことを確認して削除。 |
ドメイン自体を削除できる状態であれば、ホストゾーンやACM証明書など関連リソースも一緒に整理できます。レコード単位で削除するよりも管理をシンプルにできるケースもあります。
削除時の注意点
実際に削除作業をしてみて気づいた点を共有します。
-
削除できるリソースの見落としに注意
誰かがテスト目的で作成したリソースは、普段使わないリージョンにACM証明書があったり、ドメイン取得とホストゾーン管理が別アカウントになっているなど、不規則な構成になっていることがあります。こうしたリソースは見落としやすいので、注意して複数リージョン・複数アカウントを確認すると削除漏れを防げます。 -
ホストゾーン削除時は先にレコードを削除
ホストゾーンを削除する際、AレコードやCNAMEレコードが残っていると削除できません。先にこれらのレコードを削除しましょう。デフォルトで作成されるNSレコードとSOAレコードは、そのままでも削除できます。
Route 53コンソールまたはCLIから削除できます。不安な場合は、削除後1〜2週間は、CloudWatch Logsなどでエラーが出ていないか確認しておくと安心です。
まとめ
この記事では、Route 53で「使われているか分からないリソース」を安全に整理する手順を紹介しました。
レコード単位の確認からドメイン削除まで、順を追って確認すれば、誤って重要な設定を消してしまうリスクを防げます。
この記事が、Route 53の設定を安心して整理する際のヒントになれば嬉しいです。
Discussion