1. はじめに
こんにちは、Mitsuoです。
この記事はRoute53へのDNS切り替えとドメインの移管で必要な作業内容を整理したものです。
2. 対象読書
- DNSの基本的な知識を有している人。
- 案件でドメインの移管作業を控えており、イメージを掴みたい人、また経験があるがおさらいしたい人。
- Route53周りのリソースをTerraformで作成している人。
3. 前提
DNSの切り替えや移管作業は様々なパターンが存在するため、以下の前提で整理しました。
- ドメイン情報は、ドメインレジストラの「お名前.com」にて管理している。
- AWSサービスにリプラットフォームする際に、Route53のパブリックホストゾーンで名前解決出来るようにしたい。
- 加えて、単一のドメインをRoute53に移管したい。
| 作業 | 担当者 | 備考 |
|---|---|---|
| レジストラの管理および関連する作業 | 顧客 | レジストラとの手続き |
| Route53に関する設定 | 自社 | ホストゾーン、レコード作成周り ドメイン移管の手続き(Route53側で実施するもの) |
レジストラ側の設定変更に関しては、ブログで詳細に紹介していないことご了承ください。
4. 全体的な流れ
以下3点が全体的な作業の流れです。
- DNS切り替え
- ドメイン移管
- リリースに伴うレコード変更
この記事では「DNS切り替え」と「ドメイン移管」で必要な作業内容を整理します。
「リリースに伴うレコード変更」は、AWS側のIPアドレス、またはエイリアスレコードへ変更するだけですので、説明は省略します。
5. 作業順序
DNS切り替えの実施後、ドメイン移管を行います。
理由はAWSがDNS切り替え後にドメインの移管を推奨しているためです。
と言うのも、一部のレジストラで移管手続きを開始すると、DNSサービスが停止されるようです。
そのタイミングで名前解決出来ないリスクがあるため、先にRoute53側へDNSの切り替えを済ませておきます。
6. DNS切り替えについて
DNS切り替えの作業範囲は、Route53のホストゾーンおよびレコードを作成し、レジストリ側でRoute53への移譲設定をするまでになります。
詳細の手順は以下の公式ドキュメントを参考ください。
Making Route 53 the DNS service for a domain that’s in use(Route53側のリソース作成)
I changed DNS settings, but they haven’t taken effect(トラブルシューティング)
6.1. チェックリスト(DNS切り替え)
DNS切り替えの進捗を確認するためのチェックリストを作成してみました。
良ければ参考にしてみてください。
担当者や実施日の入力方法はご自由に活用いただければと。
| No. | 手順 | 担当(敬称略) | 実施日 | 補足 |
|---|---|---|---|---|
| 1 | DNS設定の提供 | 顧客 | M/D | ゾーンファイルあるいはレコード情報を提供ください |
| 2 | ドメインと同じ名前のホストゾーンをRoute53に作成 | 自社 | M/D | 例：Terraformにて作成予定です、ドメイン移譲のため、NSのホスト情報を提供いたします |
| 3 | レコード登録状況の複製 | 自社 | M/D | 例：Terraformにて作成予定です、手順1にて受領したレコード情報を基に登録作業を行います |
| 4 | DNSリゾルバでの確認 | 両社 | M/D | FQDNは正規のものを使用してください |
| 5 | NSレコードのTTL値を60に設定 | 両社 | M/D | ドメイン移譲前にキャッシュ期間の変更をお願いいたします |
| 6 | ドメインレジストラのネームサーバーの切替 | 顧客 | M/D | 手順2で渡すNSレコード情報を用いてください NSレコードを登録している場合は、変更前の情報を必ず記録してください |
| 7 | DNSリゾルバでの確認 | 両社 | M/D | FQDNは正規のものを使用してください |
| 8 | ドメインにおけるトラフィックの監視 | 自社 | M/D | 例：クエリログを一時的に有効化いたします |
| 9 | NSレコードのTTL値を元の値に戻す | 両社 | M/D | – |
6.2. チェックリストの詳細(DNS切り替え)
6.2.1. DNS設定の提供
Route53のホストゾーンに設定する情報を顧客から入手するか、要件を確認します。
6.2.2. ドメインと同じ名前のホストゾーンをRoute53に作成、レコード登録状況の複製
- ホストゾーン作成時に自動でNSレコードとSOAレコードが生成されるので、それ以外に必要なレコードを登録してください。
- 自動で生成されるNSレコードの値は、合計4つあり、レジストラ側のドメイン移譲で必要です。
- NSレコードの値をレジストラの管理者に伝えてください。移譲の際に必要です。
- 参考として、Terraform(tfファイル)のサンプルを紹介します。
valiables.tf
# -----------------------------
# Domain
# -----------------------------
variable "domain_name" {
type = string
default = "XXXXXX.XXX"
}
variable "domain_record_ip" {
type = string
default = "NNN.NN.NNN.NNN"
}
route53.tf
# -----------------------------
# Route53 HostZone(Public)
# aws_route53_record: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/route53_zone
# -----------------------------
resource "aws_route53_zone" "primary" {
name = var.domain_name
comment = "Hosted zone for XXXXXX"
tags = {
Name = var.domain_name
}
}
# -----------------------------
# Route53 A Record
# aws_route53_record: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/route53_record
# -----------------------------
resource "aws_route53_record" "a-record1" {
zone_id = aws_route53_zone.primary.zone_id
name = ""
type = "A"
ttl = 3600
records = [var.domain_record_ip]
allow_overwrite = true
}
resource "aws_route53_record" "a-record2" {
zone_id = aws_route53_zone.primary.zone_id
name = "www"
type = "A"
ttl = 3600
records = [var.domain_record_ip]
allow_overwrite = true
}
サンプルは、Aレコードを2つ作成しています。
ネイキッドドメイン(Apex レコード)は「 name = “”」で表現することが出来ます。
6.2.3. DNSリゾルバでの確認
Route53を設定した後に名前解決の状態を確認するようにしています。
以下のコマンドはサンプルですので、FQDNやNSレコードのドメインなど適宜修正してください。
コマンド
fqdn=www.text.example route53ns=ns-xxxx.awsdns-xx.com. echo $fqdn && \ echo $(dig $fqdn +short) "[ORIGIN]" && \ echo $(dig $fqdn @$route53ns +short) "[ROUTE53]"
コマンド実行結果の例(IPアドレスは仮)
www.test.example 192.0.2.100 [ORIGIN] 192.0.2.100 [ROUTE53]
6.2.4. NSレコードのTTL値を60に設定
DNS切替に問題が発生した際のダウンタイムを短縮する為に、現在使用しているDNSサービス及びRoute53の両方で実施してください。
例えば、NSレコードのTTL値が172000秒の場合、問題発生時に最大2日間ドメインが使用できなくなる可能性があります。
NSレコードはホストゾーン作成時に自動で生成されるため、TTLの値をTerraformで指定出来ないです。
6.2.5. ドメインレジストラのネームサーバーの切替
ドメインの移譲作業です。
レジストラのネームサーバーにRoute53のNSレコードを設定します。
切り戻しの発生に備えて、変更前のネームサーバーを顧客側に記録していただくのが良いです。
6.2.6. ドメインにおけるトラフィックの監視
監視方法をどうするか、どの程度確認するのは事前に顧客と合意を取っておいた方が親切かとは思います。
例：数時間間隔でdigコマンドを実行し名前解決の結果、クエリ実行時間を確認する、Route53のクエリログを有効化して確認するなど。
なお、クエリログは比較的多く出力されるため、目視ではなくCloudWatch Logs Insightsのクエリで、レスポンスにNXDOMAINのエラーがあるか等を確認する方が良さそうです。
クエリログの注意点は次の通りです。
CloudWatch Logsのロググループは「Virginiaリージョン」に生成されます。
Route53がCloudWatch Logに対してPutアクションが出来るようにリソースベースポリシーのアタッチが必要です。
クエリログの有効化についてはPublic DNS query loggingを参考にしてください。
6.2.7. NSレコードのTTL値を元の値に戻す
元の値、もしくは希望のTTLの値に設定します。
事前に顧客にヒアリングしておきましょう。
7. ドメイン移管について
DNS切り替え完了後、Route53へドメインを移管させます。
7.1. 事前に確認しておくもの
ドメイン移管を行うためには、以下の前提条件を満たす必要があります。
- 現在のドメインレジストラでの運用期間が60日以上経過していること
- ドメインのステータスが以下の状態でないこと
| ステータス | 説明 |
|---|---|
| pendingDelete | ドメイン名の取り戻し可能期間が終了した後の状態 |
| pendingTransfer | レジストラ変更中の状態 |
| redemptionPeriod | 削除済みドメインのための請戻猶予期間にある状態 |
| clientTransferProhibited | レジストラ変更が禁止されている状態 |
- 最上位ドメイン（※.jpや.com等）がRoute53でサポートされていること。
7.1.1. ドメインのステータス確認
ドメインレジストラの登録日やステータスはwhois情報から確認出来ます。
プライベート設定が有効化されている等、確認できない場合は、レジストラ側の担当者に確認してください。
コマンドと実行結果の例
whois DOMAIN_NAME <一部省略> Domain Name:DOMAIN_NAME Domain ID: D9999999999-LROR Creation Date: 20YY-MM-DDTHH:MM:SSZ Updated Date: 20YY-MM-DDTHH:MM:SSZ Registry Expiry Date: 20YY-MM-DDTHH:MM:SSZ status: ACTIVE <一部省略>
7.1.2. 最上位ドメイン(TLD)のサポート確認
Domains that you can register with Amazon Route 53で、サポート対象の最上位ドメインが確認出来ます。
一覧に無い場合は、ドメインをRoute53に移管することはできないので注意してください。
.jpや.comなどよく使われる最上位ドメインは、もちろんサポートされていますが、ドキュメントを正しいものとしてください。
7.2. チェックリスト(ドメイン移管)
ドメイン移管もチェックリストを作成してみました。
| No. | 手順 | 担当(敬称略) | 実施日 | 補足 |
|---|---|---|---|---|
| 1 | ドメインのアンロック | 顧客 | M/D | – |
| 2 | ドメインのプライバシー保護の無効 | 顧客 | M/D | – |
| 3 | ドメインの登録Emailアドレスの最新化 | 顧客 | M/D | 登録Emailアドレス宛に移管の承認を得る為の検証メールが送信されますので、リンクのクリックをお願いいたします |
| 4 | 認証コードの発行 | 顧客 | M/D | – |
| 5 | 認証コード、連絡先情報の提供 | 顧客 | M/D | 連絡先情報はレジストラ側で登録されている情報になります |
| 6 | Route53コンソールより「ドメインの移管」を実施 | 自社 | M/D | 手順5で受領した情報を用いて移管手続きを進めます |
| 7 | ドメイン移管のステータスを確認 | 両社 | M/D | – |
7.3. 各手順の詳細(ドメイン移管)
レジストラ側の手続きの詳細は【ドメイン】お名前.comから他の登録業者へ移管する方法は？を参考にしてください。
7.3.1. ドメインのアンロック
ドメインをアンロックしていない場合、ステータスが進まないようです。
7.3.2. ドメインのプライバシー保護の無効
プライバシー保護を無効化していない場合、whoisクエリでドメイン移管に必要な情報にアクセスできない為、ステータスが進まないようです。
7.3.3. 認証コード、連絡先情報の提供
Route53のコンソールで実施する移管作業にて必要です。
ドメインの種類によっては、認証コードが必要でなかったり、サポートに問い合わせる必要があります。
詳細はTransferring registration for a domain to Amazon Route 53を確認ください。
7.3.4. Route53コンソールより「ドメインの移管」を実施
次のような画面で遷移します。
Route53のサービスメニューから左ペインにある「登録済みドメイン」を押下する。
移管（イン）、単一のドメインの順に押下する。
※複数ドメインの移管の場合は、「複数のドメイン」を選択する。
移管するドメインをサーチボックスに入力し「チェック」を押下する。
ドメインの可用性に移管可否が表示される。
合わせて移管に必要な手順が表示されるので、問題なければ「次へ」を押下する。
「次へ」を押下する。
移管前のレジストラから受領したドメインの認証コードをテキストボックスに入力し「次へ」を押下する。
ドメインの移管料金が表示される。移管料金はTransfer costである。
ドメインの自動更新を希望する場合は「オン」にチェックする。
「次へ」を押下する。
※移管に伴う所有者情報の変更はTLDによってコストが発生する場合がある。
Amazon Route 53 Pricing for Domain Registrationの資料内にある「Change Ownership Price」の列を参照ください。
連絡先情報を入力し、「次へ」を押下する。
ドメイン登録情報として一般情報、管理者、技術者の3名を登録するが、一般情報と同様で良ければ、入力を省略することが出来る。
また、連絡先情報をWHOISクエリに表示させない事も可能である。
確認画面が表示されるため、内容に問題ないかを確認の上、理容規則に同意し「リクエストを送信」を押下する。
登録者情報のEメールアドレス宛に移管を承認するためのメールが送信される。
※TLDによって変わる場合がある模様。
移管申請後にダッシュボード上でステータスの確認が出来る。
移管完了後、ステータスが「ドメインの移管に成功」に遷移する。
8. 最後に
レコードの登録、削除作業はリリース後も運用作業として行う場合も多いかもしれないですが、移管作業はそこまで頻繁に実施したりする事もなく、かつ顧客が主体となり実施するケースが多いと思うので、流れを整理してみました。
公式ドキュメントの通りに実施すれば基本的には問題ないですが、情報量が多いので流れを掴むメモとして活用ください。
9. 参考資料
Route53
Making Route 53 the DNS service for a domain that’s in use(Route53側のリソース作成)
I changed DNS settings, but they haven’t taken effect(トラブルシューティング)
Public DNS query logging(クエリログ)
Domains that you can register with Amazon Route 53(Route53でサポートされているドメイン情報)
Transferring registration for a domain to Amazon Route 53(ドメインの移管手順)
お名前.com
【ドメイン】お名前.comから他の登録業者へ移管する方法は？
Terraform(Version 4.64.0)
Resource: aws_route53_zone(ホストゾーン)
Resource: aws_route53_record(レコード情報)
Resource: aws_route53_query_log(クエリログ)
ご自身が利用されているTerraformのバージョンのリファレンスを正としてください。
