注意
この記事はAIと対話しながらDNS, Route 53 について個人的な疑問や理解の浅かった部分をまとめたものになります。
正直かなりAIに頼り切った記事です。
ですが、自分だけで留めておくのは惜しいなと思うくらい、内容はよいものだと思うので記事として公開しようと思いました。
Route 53を触ることがでてきたときは是非参考にしてください！！！
はじめに
「Route 53 でレコードを足したらサイトが見られるようになった」——動くけれど、なぜ動くのかはモヤッとしたまま。そんな状態だった自分が、DNS の根っこ（権威サーバ・委任・ゾーン）から理解し直して、ようやく Route 53 の挙動を予測できるようになったので、その過程をまとめました。
この記事を読むと、次の疑問に自分の言葉で答えられるようになります。
- そもそも DNS は何をしているのか
- 「権威サーバ」「ゾーン」「委任」とは何か
- なぜ Zone Apex に CNAME は置けないのか
- CNAME と Alias はどう違い、どう使い分けるのか
- CloudFront / ALB に独自ドメインを割り当てる具体的な書き方（IaC・コンソール両方）
対象は「Route 53 を触ったことはあるが、DNS の理屈は曖昧」という方です。
例えに使うドメインは
example.com（架空の会社）で統一します。東京支社にtokyo.example.com、その配下にウェブサーバweb.tokyo.example.comを置く、というシナリオで通します。
1. そもそも DNS とは何か
DNS（Domain Name System）は、ドメイン名と IP アドレスを変換する、世界中に分散した階層型の問い合わせシステムです。
人間が覚えやすい example.com を、コンピュータが通信に使う 192.0.2.1 のような IP アドレスに翻訳します。「電話帳」に例えられますが、実態は 1 冊の本ではなく、世界中に分散した責任者たちのネットワークです。
名前解決の流れ
web.tokyo.example.com にアクセスするとき、裏ではこう動いています。
[クライアント]
│ ① 「web.tokyo.example.com の IP 教えて」
▼
[フルリゾルバ (キャッシュDNSサーバ)]
│ ② キャッシュに無ければ、ルートから順にたどる
▼
[ルートDNSサーバ] →「.com は あっちのサーバに聞け」
▼
[.com の権威サーバ (TLD)] →「example.com は あっちに聞け」
▼
[example.com の権威サーバ] →「tokyo.example.com は あっちに聞け」
▼
[tokyo.example.com の権威サーバ] →「web... の IP はこれだ」
▼
[クライアント] → 取得した IP に接続
ここで主役になるのが 「フルリゾルバ」 と 「権威サーバ」 の2者です。役割がはっきり分かれているのが DNS 理解の最初の鍵です。
| 登場人物 | 役割 | 一言で |
|---|---|---|
| フルリゾルバ | ルートから順に何度も問い合わせ、最終的な IP を突き止める | たどり役 |
| 権威サーバ | 自分の担当範囲だけを即答する／次の担当を紹介する | 回答役・案内役 |
💡 ポイント：権威サーバは「代わりにたどってあげる」ことはしません。自分の持ち分を答えるか、「次はここに聞いて」と紹介するだけ。全工程を走り回るのはフルリゾルバの仕事です。
2. 主なレコードの種類
DNS の「答え」はレコードという単位で保存されています。最初に押さえるべきはこのあたりです。
| レコード | 役割 | 例 |
|---|---|---|
| A | ドメイン名 → IPv4 アドレス | web.example.com → 192.0.2.10 |
| AAAA | ドメイン名 → IPv6 アドレス | ... → 2001:db8::1 |
| CNAME | ドメイン名 → 別のドメイン名（別名） | www → web.example.com |
| NS | このゾーンの権威サーバを示す | example.com → ns-xxx.awsdns... |
| SOA | ゾーンの管理情報（先頭に自動生成） | — |
| MX | メールサーバの指定 | — |
このうち NS と SOA は「委任」と「権威」を理解する核になるので、後で詳しく扱います。
3. 権威サーバとゾーン —— 「責任範囲」という考え方
権威サーバ＝そのゾーンの「正しい答えを持つ責任者」
権威サーバ（Authoritative Name Server） とは、あるゾーンについて「正しい答え」を持っている責任者です。そして Route 53 のホストゾーンは、この権威サーバの役割を担います。
tokyo.example.com をホストゾーン（＝ゾーン）として作った場合、その権威サーバは tokyo.example.com 以下の名前について答える責任を持ちます。
tokyo.example.com ← 答えられる
web.tokyo.example.com ← 答えられる
db.tokyo.example.com ← 答えられる
api.web.tokyo.example.com ← 答えられる（さらに下も含む）
example.com ← 答えられない（親ゾーンの責任範囲）
osaka.example.com ← 答えられない（別の責任範囲）
ポイントは 「責任範囲はゾーン単位で区切られる」 こと。example.com の権威サーバと tokyo.example.com の権威サーバは別々に存在しえます（同じでもよい）。その区切りを作る仕組みが、後述の 委任 です。
4. ゾーンファイルを読む —— Route 53 の「中身」
ゾーンファイルは、1 つのゾーンに属するすべてのレコードを記述したテキストファイルです。Route 53 のホストゾーンは、このゾーンファイルを GUI / API でラップしたものだと考えると一気に腑に落ちます。
tokyo.example.com のゾーンファイルの例：
$ORIGIN tokyo.example.com.
$TTL 3600
@ IN SOA ns-1.awsdns-01.com. admin.example.com. (
2024010101 ; Serial（シリアル番号）
7200 ; Refresh
900 ; Retry
1209600 ; Expire
86400 ) ; Minimum TTL
@ IN NS ns-1.awsdns-01.com.
@ IN NS ns-2.awsdns-02.net.
web IN A 192.0.2.10
db IN A 192.0.2.20
@ IN A 192.0.2.1
読み解きの鍵
-
$ORIGIN：このゾーンの基準名。以降の相対表記はこれで補完される。 -
@：$ORIGINそのもの（ここではtokyo.example.com.）を指す記号。 -
末尾ドットの有無が決定的：
-
web（ドットなし）＝相対表記 →web+$ORIGIN=web.tokyo.example.com. -
ns-1.awsdns-01.com.（ドットあり）＝ FQDN ＝そのまま確定 - もし
ns-1.awsdns-01.com（ドット忘れ）と書くと、ns-1.awsdns-01.com.tokyo.example.com.という誤った名前になる ← 古典的バグ
-
- 各行は
名前 IN レコード種別 値。INは Internet クラスの意味（ほぼ常にこれ）。
⚠️ 末尾ドットの罠：DNS の世界では「末尾ドット付き＝完全な名前（FQDN）」「ドットなし＝相対表記」。Route 53 のコンソールは裏でうまく扱ってくれますが、ゾーンファイルを直接書く場面ではここが事故の温床です。
5. SOA レコードと NS レコードを深掘りする
SOA レコード —— ゾーンの管理情報
SOA（Start Of Authority） は、ゾーンの管理情報を1つだけ持つレコードで、ゾーン作成時に必ず先頭へ自動生成されます。「このゾーンはここから権威が始まる」という宣言です。
| フィールド | 値の例 | 意味 |
|---|---|---|
| MNAME（プライマリNS） | ns-1.awsdns-01.com. |
このゾーンの主たる権威サーバ |
| RNAME（管理者メール） | admin.example.com. |
管理者アドレス。@ を . に置換した表記（実際は admin@example.com） |
| Serial | 2024010101 |
ゾーンの版番号。変更のたびに増やす |
| Refresh | 7200 |
セカンダリが更新確認する間隔（秒） |
| Retry | 900 |
確認失敗時の再試行間隔 |
| Expire | 1209600 |
更新できないまま放置できる限界。超えたら応答停止 |
| Minimum / Negative TTL | 86400 |
「存在しない」という否定応答のキャッシュ時間 |
💡 RNAME がメールアドレスなのに
@ではなく.で書くのは、DNS では@が別の意味（＝$ORIGIN）を持つための歴史的な約束事です。admin.example.com.はadmin@example.comのこと。
NS レコード —— 「権威サーバはこれ」を示す
NS（Name Server） レコードは「この名前の権威サーバはこれだ」と示すレコードで、登場場面が2つあります。ここが委任の核心です。
① ゾーン自身の頂点に置く NS（自分の権威サーバ宣言）
tokyo.example.com. → ns-1.awsdns-01.com. （tokyo ゾーン内）
② 親ゾーンに置く NS（子への委任）
tokyo.example.com. → ns-1.awsdns-01.com. （example.com ゾーン内）
中身は同じでも、置かれるゾーンが違うのがポイント。
- ①は子ゾーン自身が「私の権威サーバはこれ」と言っているだけ
- ②は親が「
tokyoのことはこの NS に聞け」と外に向かって案内している
外部のリゾルバが実際にたどるのは② です。
NS の値はサーバの「名前」であって IP ではない
NS が指すのは IP ではなく サーバの名前（ドメイン名） です。
NS tokyo.example.com. → ns-1.awsdns-01.com. ← 名前であって IP ではない
実際に通信するには、この ns-1.awsdns-01.com. をさらに A レコードで IP に解決する必要があります。
ns-1.awsdns-01.com. → A 205.251.192.1 ← 最終的にはこの IP のマシン
🤔 「サーバの場所を知るのに、また名前解決が必要になる」というニワトリ・卵問題が見えてきますが、これは Glue レコード（後述）で解決されます。
ネームサーバが実際にやっている2つの仕事
① 答えを返す（自分が権威を持つ名前）
リゾルバ:「web.tokyo.example.com の A は？」
▼
ns-1:「192.0.2.10 です」(権威ある回答 = Authoritative Answer)
② 委任先を案内する（自分の子ゾーン）
リゾルバ:「osaka.example.com は？」
▼
example.com の権威:「osaka のことは ns-9.awsdns-xx に聞いて」(Referral = 紹介)
繰り返しになりますが、**権威サーバは原則「再帰しない」**＝代わりに走り回らない。役割が明確に分かれているのが DNS の設計思想です。
6. FQDN（完全修飾ドメイン名）
FQDN（Fully Qualified Domain Name） は、ルートから下まで省略なく完全に書いたドメイン名です。正式には末尾に「ルートを表すドット」が付きます。
web . tokyo . example . com .
│ │ │ │ └─ ルート (root) ← 通常は省略される
│ │ │ └───── TLD（トップレベルドメイン）
│ │ └────────────── 2nd レベルドメイン
│ └────────────────────── サブドメイン
└───────────────────────────── ホスト名
階層は 右から左 に向かって具体的になります。「.com を管理する人 → その中の example → その中の tokyo → その中の web」とたどるイメージです。
FQDN にプロトコルは含まれない
これは混同しやすいポイント。https:// や :443 は URL の構成要素であって、FQDN ではありません。
https://web.tokyo.example.com:443/path?q=1
└─┬─┘ └────────┬─────────┘└┬┘└──┬──┘
プロトコル FQDN ポート パス
（スキーム）
FQDN = web.tokyo.example.com ← この部分だけ
DNS が解決するのは FQDN の部分だけ。「どう話すか（http か https か）」はブラウザの仕事で、DNS は一切関知しません。
7. DNS 委任（Delegation）
委任とは、親ゾーンが「このサブドメインの管理を、別の権威サーバに任せる」と宣言することです。仕組みは 「親ゾーンに、子ゾーンの NS レコードを書く」 ——ただそれだけです。
委任の連鎖を実際にたどる
web.tokyo.example.com を解決する流れで、委任がどう連鎖するかを見ます。
[リゾルバ]
│ ① 「web.tokyo.example.com の A は？」
▼
[ルート(.) 権威サーバ]
│ ② 「.com の NS はこれ」← ルートが .com に委任している
▼
[.com 権威サーバ]
│ ③ 「example.com の NS はこれ」← .com が example.com に委任
▼
[example.com 権威サーバ]
│ ④ 「tokyo.example.com の NS はこれ」← ここで tokyo に委任
│ （★ example.com ゾーン内に tokyo の NS レコードがある）
▼
[tokyo.example.com 権威サーバ] ← Route 53 のホストゾーン
│ ⑤ 「web.tokyo.example.com の A は 192.0.2.10」← 確定回答
▼
[リゾルバ] → 192.0.2.10 へ接続
各段の「NS はこれ」という案内が委任です。委任が連鎖してルートから末端までつながって初めて、世界中から名前解決できます。
委任が切れると起きること（Lame Delegation）
委任で最も多い事故は、親に NS を書き忘れる／間違える ことです。
tokyo.example.com をホストゾーンとして新規作成すると、Route 53 は tokyo ゾーン内の NS（①）は自動生成しますが、親 example.com ゾーンへの NS（②）は自動では作られません。手動で追加が必要です。
やるべきこと：
example.com ホストゾーン に追加
NS tokyo.example.com → ns-1.awsdns-01.com.
ns-2.awsdns-02.net. （tokyo ゾーンの NS 4本をコピー）
これを忘れると、外からは example.com までしかたどれず tokyo.* が一切引けない 「委任切れ（Lame Delegation）」 状態になります。
⚠️ 「ホストゾーンを分けたら委任が必要」 とよく言われるのは、まさにこの②のこと。サブドメイン用に別ホストゾーンを作ったら、親ゾーンへの NS 登録を忘れずに。
補足：Glue レコード（ニワトリ・卵問題の解決）
「NS の値がまた名前」という循環は、ネームサーバ名がそのゾーン自身の配下にあるときに深刻化します。
.com に聞く:「example.com の NS は？」→「ns.example.com です」
「じゃあ ns.example.com の IP は？」→「それは example.com に聞いて」
→ でも example.com に行くには ns.example.com の IP が要る → 無限ループ！
これを断ち切るのが Glue レコード。親ゾーン（.com）が、委任 NS と一緒に そのネームサーバの IP（A レコード）も例外的に保持します。
.com ゾーンが持つ情報:
NS example.com. → ns.example.com.
A ns.example.com. → 205.251.192.1 ← これが Glue（IP を直接渡す）
💡 Route 53 が払い出す NS は
ns-1.awsdns-01.com / ns-2.awsdns-02.net / ...co.ukのように わざと別 TLD に分散しています。これは可用性向上に加え、ネームサーバ名が別ドメインに属するので Glue 不要で素直に解決できるという狙いもあります。
8. DNS を Route 53 はどうラップしているのか
ここまでをふまえると、Route 53 は DNS を置き換える独自技術ではなく、標準 DNS の「権威サーバ」を AWS がマネージドで提供しているだけだと分かります。
| DNS の概念 | Route 53 での対応物 |
|---|---|
| 権威ネームサーバ | Route 53 のインフラ（4台の NS） |
| ゾーンファイル | ホストゾーン |
| ゾーンの委任 | 親ゾーンへの NS レコード登録 |
| A / CNAME / MX レコード | コンソール・API で作るレコード |
| （Route 53 独自） | Alias レコード、ヘルスチェック、加重／レイテンシ／位置情報ルーティング |
つまり：
- 標準 DNS のままな部分：レコードの意味、名前解決の階層、NS 委任の仕組み。世界中のリゾルバは Route 53 を「ただの権威サーバ」として扱う。
- Route 53 が上乗せした部分：高可用な分散インフラ、API 操作、そして標準にはない便利機能（次の Alias など）。
9. Zone Apex とは
Zone Apex（ゾーン頂点） とは、そのゾーンの一番上、ドメインそのものの名前です。「ネイキッドドメイン」「ルートドメイン」とも呼ばれます。
example.com というホストゾーンの場合:
example.com ← ★ Zone Apex（頂点。これ自体）
www.example.com ← サブドメイン（Apex ではない）
app.example.com ← サブドメイン
shop.example.com ← サブドメイン
www が付かない example.com そのものが Zone Apex です。
💡 Zone Apex には 必ず SOA と NS が存在します（ゾーン作成時に自動生成されるあれ）。この「すでに SOA / NS が常駐している」事実が、次の CNAME 問題の原因になります。
10. CNAME と Alias —— ここが最大のハマりどころ
CNAME とは
CNAME（Canonical Name = 正規名） は「ある名前は、別の名前の別名です」と転送するレコードです。
CNAME www.example.com → web.tokyo.example.com
意味:「www.example.com を聞かれたら、web.tokyo.example.com として解決し直して」
解決の流れ：
リゾルバ:「www.example.com の A は？」
▼
権威:「それは CNAME で web.tokyo.example.com の別名だよ」
▼
リゾルバ:「じゃあ web.tokyo.example.com の A は？」 ← もう一度引き直す
▼
権威:「192.0.2.10 です」
利点は、転送先の IP が変わっても CNAME 側はノータッチでよいこと。IP が動く AWS リソースを指すのに向く理由がこれです。
CNAME の致命的な制約
ルール:「CNAME がある名前には、他のレコードを一切共存させられない」
これが Zone Apex で問題になります。
example.com（Zone Apex）には、すでに SOA と NS が必ず存在する
↓
そこに CNAME を置こうとすると…
↓
CNAME は「他レコードと共存禁止」→ SOA / NS と衝突 → 規格違反で置けない！
✅ www.example.com → CNAME 置ける（SOA も NS も無い）
❌ example.com → CNAME 置けない（SOA / NS が既に居る）
でも実務では example.com（www なし）で CloudFront や ALB を使いたい。IP は固定できないから A レコードも書けない。詰みます。 これを解決するために AWS が用意したのが Alias です。
Alias とは
Alias は Route 53 独自の拡張で、CNAME のような「名前で転送する」便利さを持ちつつ、A（または AAAA）の顔をして応答するものです。
CNAME: 外部リゾルバに「別名です、引き直して」と返す（追加の問い合わせが発生）
Alias: 外部リゾルバに「A レコードです、IP はこれ」と直接返す
（Route 53 が裏で AWS リソースの IP を解決して埋める）
リゾルバ:「example.com の A は？」
▼
Route 53（Alias 設定済み）:
裏で CloudFront の現在の IP を自分で調べる
→「A レコードです。192.0.2.50 です」と即答（あたかも普通の A のように）
▼
リゾルバ:そのまま IP を使える（引き直し不要）
外向きには普通の A レコードに見えるので、「CNAME は他レコードと共存禁止」という制約に引っかからない → Zone Apex にも置ける、これが最大の利点です。
CNAME と Alias の違い・使い分け
| 観点 | CNAME | Alias |
|---|---|---|
| 正体 | DNS 標準のレコード | Route 53 独自拡張 |
| 応答の見え方 | 「別名です」（要・引き直し） | A / AAAA として直接 IP 応答 |
| Zone Apex に置ける？ | ❌ 置けない | ✅ 置ける |
| 指せる対象 | 任意のドメイン名 | 主に AWS リソース（CloudFront/ALB/S3 等）と同一ゾーン内レコード |
| 料金 | 問い合わせ課金あり | AWS リソース向けは無料 |
| 問い合わせ回数 | 2 回（引き直す分多い） | 1 回（速い） |
| 外部の他社サービスを指す | ✅ 得意 | ❌ 基本不可 |
使い分けの判断フロー
指したい先は AWS リソース（CloudFront/ALB/S3/別の Route 53 レコード）？
│
├─ YES → Alias を使う
│ （Zone Apex でも サブドメインでも OK、無料、速い、IP 追従）
│
└─ NO（他社サービス・外部ドメインを指す）
│
├─ Zone Apex に置きたい → 詰む。CNAME 不可・Alias も AWS 外は不可
│ → サブドメインに逃がす等の回避が必要
│
└─ サブドメインで良い → CNAME を使う
（例: www.example.com → shops.myshopify.com）
実務の原則：
AWS リソースを指すなら → 迷わず Alias（サブドメインでも Apex でも）
AWS 外のドメインを指すなら → CNAME（ただしサブドメインのみ）
11. CloudFront / ALB に独自ドメインを割り当てる
前提：CloudFront も ALB も「自前のドメイン」を持つ
作成すると AWS が自動でドメイン名を払い出します。ただし性質が違います。
CloudFront → d111abcdef8.cloudfront.net （名前は固定、IP は変動）
ALB → my-alb-1234567890.ap-northeast-1.elb.amazonaws.com （IP が動的に変わる）
両方とも 背後の IP が変動する ため A レコードで固定 IP を直書きできません。だから Alias を使うのが定石 です。
Alias レコードの登録内容（重要）
Alias は値に IP を書きません。代わりに ターゲット（DNSName）とそのターゲットの HostedZoneId を指定し、TTL も書きません。
// 通常の A（TTL と ResourceRecords を持つ）
{
"Name": "example.com.",
"Type": "A",
"TTL": 300,
"ResourceRecords": [ { "Value": "192.0.2.10" } ]
}
// Alias（TTL も IP も無く、AliasTarget を持つ）
{
"Name": "example.com.",
"Type": "A",
"AliasTarget": {
"HostedZoneId": "Z2FDTNDATAQYW2",
"DNSName": "d111abcdef8.cloudfront.net.",
"EvaluateTargetHealth": false
}
}
ターゲット種別ごとの値（早見表）
AliasTarget の中身は指す相手によって変わります。実務で一番参照する箇所です。
| ターゲット | DNSName | ターゲット側 HostedZoneId |
|---|---|---|
| CloudFront | d111....cloudfront.net |
Z2FDTNDATAQYW2（全世界固定） |
| ALB / NLB | my-alb-xxx.<region>.elb.amazonaws.com |
リージョンごとの固定値（例：東京 ALB Z14GRHDCWA56QT） |
| S3 静的サイト | s3-website-<region>.amazonaws.com |
リージョンごとの固定値 |
| API Gateway | d-xxx.execute-api.<region>.amazonaws.com |
リージョンごとの固定値 |
| 同一ゾーン内の別レコード | 対象レコード名（例 web.example.com） |
自分のホストゾーン ID |
💡 CloudFront だけ
Z2FDTNDATAQYW2で世界共通。それ以外はリージョン依存と覚えると楽。CloudFormation なら!GetAttで動的に取得できるので、固定値の手書きはコンソール／CLI 中心です。
CloudFormation（IaC）での書き方
CloudFront に割り当てる
Parameters:
HostedZoneId:
Type: AWS::Route53::HostedZone::Id
Description: example.com のホストゾーンID
DomainName:
Type: String
Default: www.example.com
Resources:
CloudFrontAliasRecord:
Type: AWS::Route53::RecordSet
Properties:
HostedZoneId: !Ref HostedZoneId
Name: !Ref DomainName
Type: A
AliasTarget:
DNSName: !GetAtt MyDistribution.DomainName # d111...cloudfront.net を自動取得
HostedZoneId: Z2FDTNDATAQYW2 # CloudFront 固定値
EvaluateTargetHealth: false # CloudFront は false 固定
# IPv6 も使うなら AAAA をもう1本（CloudFront は IPv6 対応のため推奨）
CloudFrontAliasRecordIPv6:
Type: AWS::Route53::RecordSet
Properties:
HostedZoneId: !Ref HostedZoneId
Name: !Ref DomainName
Type: AAAA
AliasTarget:
DNSName: !GetAtt MyDistribution.DomainName
HostedZoneId: Z2FDTNDATAQYW2
EvaluateTargetHealth: false
CloudFront 側でも 代替ドメイン名（Aliases）の登録と ACM 証明書（us-east-1 必須） の紐づけが必要です。
MyDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Aliases:
- !Ref DomainName # ★ これが必要
ViewerCertificate:
AcmCertificateArn: !Ref CertArn # ★ us-east-1 の ACM
SslSupportMethod: sni-only
# ... 他の設定
ALB に割り当てる
ALB はターゲット側 ID を GetAtt で取れるので固定値は不要です。
AlbAliasRecord:
Type: AWS::Route53::RecordSet
Properties:
HostedZoneId: !Ref HostedZoneId
Name: app.example.com
Type: A
AliasTarget:
DNSName: !GetAtt MyLoadBalancer.DNSName # my-alb-xxx.elb...
HostedZoneId: !GetAtt MyLoadBalancer.CanonicalHostedZoneID # ★ GetAtt で取得
EvaluateTargetHealth: true # ALB は true 推奨（ヘルスチェック連動可）
CloudFront と ALB の差分まとめ
| 項目 | CloudFront | ALB |
|---|---|---|
| ターゲット HostedZoneId |
Z2FDTNDATAQYW2（固定） |
!GetAtt ...CanonicalHostedZoneID |
| DNSName | !GetAtt Dist.DomainName |
!GetAtt LB.DNSName |
| EvaluateTargetHealth | false |
true 推奨 |
| 証明書のリージョン | us-east-1 必須 | ALB と同一リージョン |
| ドメイン登録先 | Distribution の Aliases
|
リスナー／証明書側 |
💡
EvaluateTargetHealthは「ターゲットが不健全なときこの DNS 応答を返さないか」のフラグ。フェイルオーバー構成で効きます。CloudFront は仕組み上 false 固定です。
マネジメントコンソールでの設定手順（ALB の例）
1. Route 53 コンソール → 「ホストゾーン」を開く
2. 対象ホストゾーン（例: example.com）をクリック
3. 「レコードを作成」ボタン
4. レコード名を入力（例: app → app.example.com になる）
※空欄なら Zone Apex (example.com) 自体になる
5. レコードタイプ: A を選択
6. 「エイリアス」トグルを ON にする ← ここが最重要
7. 「トラフィックのルーティング先」で:
→ 「Application Load Balancer へのエイリアス」を選択
→ リージョンを選択（例: アジアパシフィック 東京）
→ 一覧から対象の ALB を選択（自動で出てくる）
※CloudFront の場合は「CloudFront ディストリビューションへのエイリアス」を選び、
ディストリビューションを選択（リージョン選択は不要）
8. 「レコードを作成」で確定
💡 コンソールの「エイリアス ON → リソース種別を選ぶ」UI が、CloudFormation の
AliasTarget（DNSName + HostedZoneId）に対応します。コンソールは ID を裏で自動入力してくれますが、IaC では明示的に書く、という対応関係です。
12. 初回構築でハマりやすいポイント
- CloudFront の ACM 証明書は必ず us-east-1（バージニア北部）で作る 東京リージョンで作ると CloudFront から選べない。
-
Route 53 の Alias だけでなく、リソース側でもドメインを認識させる CloudFront の
Aliases/ ALB リスナーの証明書。Route 53 だけ設定しても動きません。 - サブドメイン用に別ホストゾーンを作ったら、親ゾーンへの NS 登録（委任）を忘れない 忘れると Lame Delegation で一切引けなくなる。
まとめ
最後に全体像を一枚で。
DNS = ルートを頂点に、NS レコードによる「委任」を連鎖させた階層構造
│
├─ 各ゾーンの先頭に必ず SOA（管理情報）と NS（自分の権威宣言）がある
├─ ゾーンファイルがその実体
└─ Route 53 のホストゾーン = それをマネージド化した権威サーバ
│
├─ Zone Apex（ドメインそのもの）には SOA/NS が常駐
│ → CNAME は「共存禁止ルール」で置けない
│
└─ AWS 独自拡張 Alias が壁を越える
→ A の顔をして AWS リソースの変動 IP を自動追従
→ CloudFront / ALB への割り当ては Alias が定石
- DNS の主役は「権威サーバ（回答役）」と「フルリゾルバ（たどり役）」の分業
- 委任とは「親ゾーンに子の NS を書く」こと。これが連鎖して世界中から引ける
- Zone Apex に CNAME が置けないのは SOA/NS との共存禁止が原因。Alias がそれを解決する
- Route 53 は DNS を置き換えるのではなく、標準 DNS の権威サーバをマネージド化＋便利機能を上乗せしたもの
DNS の根っこさえ押さえれば、Route 53 の挙動はほぼ予測できるようになります。