【AWS】ドメインを取得しDNS管理を最適にしたい
はじめに
個人ドメイン .dev を取得し、AWS Route53 で DNS 管理を構築した際の記録です。ドメインの基本的な仕組みから、実際の取得・設定手順まで解説します。
名前解決と DNS の基礎
名前解決とは
名前解決は、人間が理解しやすいドメイン名（例：example.com）をコンピュータが使用する IP アドレス（例：192.168.1.1）に変換する仕組みです。
DNS の解決フロー
- ローカルキャッシュ確認 - ブラウザや OS のキャッシュを確認
- ローカル DNS サーバー - ISP や社内の DNS サーバーへ問い合わせ
- ルート DNS サーバー - 最上位の DNS サーバーへ問い合わせ
- TLD（Top Level Domain）サーバー - .com、.dev などの TLD サーバーへ
- 権威 DNS サーバー - 実際のドメイン情報を持つサーバーから回答取得
ドメイン管理戦略の検討
要件
-
.devドメインの取得 - メールアドレス
@.devの使用（AWS WorkMail 連携） - 複数のサブドメイン管理（例：subdomain.example.dev）
- 将来的な拡張性の確保
検討した構成
1. GCP Cloud DNS 管理案
example.dev (Cloud Domains)
└─ Cloud DNS
├─ 基本レコード管理
└─ subdomain.example.dev → AWS Route53へ委譲
メリット：GCP 内で完結
デメリット：AWS WorkMail との統合が複雑、管理が分散
2. AWS Route53 管理案（採用）
example.dev (Cloud Domains)
↓ カスタムネームサーバー設定
Route53 Hosted Zone
├─ A: example.dev → 任意のサーバー
├─ MX: @example.dev → AWS WorkMail
├─ A: subdomain.example.dev → 任意のサーバー
└─ その他すべてのサブドメイン
メリット：
- AWS WorkMail とのシームレスな統合
- 一元管理による運用簡素化
- 豊富な AWS サービスとの連携
ホストゾーンとネームサーバーの関係
ホストゾーンとは
ホストゾーン（Hosted Zone）は、特定のドメインに関する DNS レコードを管理するコンテナです。Route53 では、1 つのドメインに対して 1 つのホストゾーンを作成します。
ネームサーバーの役割
ネームサーバーは、ドメイン名の問い合わせに対して実際に IP アドレスを返答するサーバーです。ホストゾーンを作成すると、Route53 が自動的に 4 つのネームサーバーを割り当てます。
.dev ドメインとの関係
インターネット
↓ 「example.devのIPアドレスは？」
.devレジストリ（Google管理）
↓ 「example.devのネームサーバーはns-xxxx.awsdns-xx.orgです」
Route53ネームサーバー
↓ ホストゾーン内のレコードを参照
↓ 「example.devのIPアドレスは192.0.2.1です」
ユーザーへ回答
重要なポイント：
- ドメインレジストラ（Cloud Domains）：ドメインの所有権を管理し、どのネームサーバーを使うかを指定
- ホストゾーン（Route53）：DNS レコードを保存する場所
- ネームサーバー：実際に DNS クエリに応答するサーバー
実装手順
1. Route53 で Hosted Zone 作成
まず、AWS Route53 で Hosted Zone を作成します。これによりネームサーバーが割り当てられます。
# AWSコンソールで実行
# Route53 → Hosted zones → Create hosted zone
# Domain name: example.dev
作成後、以下のようなネームサーバーが割り当てられます：
- ns-xxxx.awsdns-xx.org
- ns-xxxx.awsdns-xx.com
- ns-xxxx.awsdns-xx.net
- ns-xxxx.awsdns-xx.co.uk
ホストゾーン作成時に自動生成されるレコード
Route53 でホストゾーンを作成すると、以下の 2 種類のレコードが自動的に生成されます：
NS レコード（Name Server）
- 役割：このドメインの権威ネームサーバーを指定
- 内容：上記の 4 つのネームサーバー情報
- 用途：ドメインレジストラ（Cloud Domains）に登録し、DNS クエリを Route53 に誘導
SOA レコード（Start of Authority）
- 役割：ドメインの管理情報を記録
-
内容：
- プライマリネームサーバー
- 管理者のメールアドレス
- シリアル番号（更新のたびに増加）
- 更新間隔などのタイミング情報
- 用途：DNS ゾーンの同期や更新管理に使用
これらは削除・変更してはいけません。Route53 が自動的に管理します。
2. Cloud Domains でドメイン取得
Google Cloud Domains でドメインを取得する際、カスタムネームサーバーを指定します。
# GCPコンソールで実行
# Cloud Domains → Register domain
# ドメイン: example.dev
# DNS設定: Use custom name servers
# Route53で取得したネームサーバーを4つすべて入力
3. DNS 設定の追加
Route53 でレコードを追加：
# Aレコード（ウェブサイト）
example.dev. A 192.0.2.1
# MXレコード（メール）
example.dev. MX 10 inbound-smtp.us-east-1.amazonaws.com
# サブドメイン
subdomain.example.dev. A 192.0.2.2
重要なポイント
DNS 伝播の考慮
- ネームサーバーの変更は最大 48 時間かかる場合がある
なぜ Cloud Domains で.dev ドメインを取得するのか
Route53 では.dev ドメインを直接取得できません。これは.dev ドメインが Google が管理する特別な TLD（トップレベルドメイン）だからです。そのため：
- ドメイン取得：Google Cloud Domains（.dev の取得が可能）
- DNS 管理：AWS Route53（AWS WorkMail との統合が容易）
という役割分担をすることで、AWS で管理したい目的を実現しています。
まとめ
ドメイン取得と DNS 管理は、適切な戦略と手順で行えば難しくありません。重要なのは：
- DNS 管理サービスを先に決定し、準備する
- ドメイン取得時にネームサーバーを正しく設定する
- 将来の拡張性を考慮した構成を選択する
今回の構成により、AWS WorkMail との統合やサブドメイン管理が簡単になり、運用負荷を大幅に削減できました。
Discussion