CNAMEは不要？Route53でサブドメインを運用するときに知っておきたいDNSの基本

AWSs-kunishima用語解説

どうも、Cloud & Data Platformチームの國嶋です。
今回は、Route 53でサブドメイン運用をする前提として、DNSの基本とNS委譲の仕組みを整理します。

目次

  • 執筆の経緯
  • DNSの基本
  • サブドメインとNS委譲の仕組み
  • まとめ

執筆の経緯

担当案件で構築しているアプリケーションにおいて、サブドメインの発行が必要になりました。
本来であればクライアントにサブドメインを発行してもらうのが望ましいのですが、クライアント側の対応にはリードタイムが長く発生するため、開発環境用のサブドメインについては弊社で発行したものを利用する方針となりました。

作業にあたっては、他メンバーが別案件で残していたメモを参考にし、ひとまず以下の手順を実施しました。

① Route 53 でサブドメイン用のパブリックホストゾーンを作成
↓
② サブドメインの CNAME レコードおよび NS レコードの登録を申請

結果として、開発環境では サブドメイン（xxxx.dev.exapmle.com） にアクセスすると、期待通りに AWS 側のリソースへ到達できる状態となりました。
（例：DNSの名前解決が成功し、対象のALB / CloudFront等へルーティングされ、HTTPSでアクセスできる状態）

しかし当時の私は、DNSの仕組みを十分に理解できておらず、
「なぜこの作業が必要なのか」「各レコードがどのような役割を持っているのか」を説明できない状態でした。
言わば、「手順通りに設定したら動いたが、仕組みは理解できていない」 という状況でした。

それから、クライアントに対して 検証環境・本番環境用のサブドメイン申請を依頼するタイミングが訪れました。
開発環境での手順をもとに「CNAMEやNSレコードを登録してもらえば良さそうだ」とは思いつつも、仕組みを理解しないまま依頼するのは望ましくないと感じました。
特に、どのレコードをクライアント側に登録してもらう必要があるのか、またそれが DNSのどの部分に影響するのか が曖昧なままだったためです。

本記事では、DNSの仕組みを改めて整理し、サブドメイン運用において「どのレコードを、どこに登録すべきか」を説明できる状態を目指します。

DNSの基本

ここでは、DNSの基本として 名前解決がどのようにして行われるのか、そしてその過程で登場する リゾルバ／権威DNS／各レコードの役割 を整理します。

1. DNSとは何か

DNS（Domain Name System）は、www.example.comのような 人間が扱いやすいドメイン名を、通信に必要な IPアドレスに変換する仕組みです。また、ドメイン名をIPアドレスに変換することを名前解決と呼びます。
私たちは普段ドメイン名を利用していますが、最終的には DNS によって IP アドレスが取得され、その IP に対して通信が行われています。

2. 名前解決の全体像

まずは、私たちのPCやスマホがどのように名前解決をスタートさせるのかを見てみましょう。ブラウザで app.example.com にアクセスした際、裏側では次のような流れが起きています。

  1. ブラウザがIPアドレスを要求: 接続のためにIPアドレスが必要になります。
  2. OSがキャッシュを確認: 端末内に以前の記録が残っていればそれを使います。
  3. リゾルバへ問い合わせ: 記録がない場合、端末に設定されている「リゾルバ（DNSサーバ）」へ調査を丸投げします。
  4. 回答の受け取り: リゾルバが調べてきたIPアドレスを受け取り、目的のサーバへアクセスします。

ポイントは、ブラウザ自身がDNSの階層構造を辿って調べているわけではなく、リゾルバが代わりに調べてくれているという点です。

3. リゾルバと権威DNS

DNSの問い合わせでは、役割の異なる2種類のDNSサーバが登場します。

リゾルバ（Recursive Resolver）

リゾルバは、クライアント（PCやスマホ）から問い合わせを受け、代わりに階層的に調べて最終的な回答を返してくれる DNS サーバです。
たとえば以下がリゾルバに該当します。

  • 社内ネットワークのDNSサーバ
  • ISPのDNSサーバ
  • Public DNS（Google DNS 8.8.8.8 など）

権威DNS（Authoritative DNS）

権威DNSは、example.com のような特定のドメインに対して、AレコードやCNAMEレコードなどのDNSレコードを管理しているDNSサーバです。
app.example.com のIPアドレスは？ と問い合わせが来たときに、そのドメインのレコード情報をもとに 最終的な回答（IPアドレスなど）を返します。
Route 53 の Public Hosted Zone（パブリックホストゾーン）は、この 権威DNSとして機能します。

4. 名前解決が進む仕組み（権威DNSのリレー）

2.名前解決の全体像 で調査を丸投げされたリゾルバは、具体的にどうやって正解を見つけているのでしょうか。それは、「必要な情報を持っている権威DNSへ辿り着くまでのリレー」として理解すると分かりやすいです。
以下は app.example.com を引くときの具体的な流れです。

[クライアント]
  │ app.example.com のIPを知りたい
  ▼
[リゾルバ]
  │ （キャッシュがなければ）階層的に問い合わせを行う
  ▼
[ルートDNS] ──「.com のことは TLD DNS に聞いて」
  ▼
[.com (TLD) DNS] ──「example.com のことは example.com の権威DNSに聞いて」
  ▼
[example.com の権威DNS] ──「app.example.com は 203.0.113.10 です（Aレコード）」
  ▼
[リゾルバ] ──（結果をクライアントに返す）
  ▼
[クライアント] ── 203.0.113.10 にアクセス

このように、リゾルバが「どこに聞けばよいか」を順番に辿っていくことで、最終的な回答に到達します。

図のポイント

  • クライアントは基本的に「リゾルバ」だけに問い合わせる
  • リゾルバが「どこに聞けばよいか」を順番に辿っていく
  • 最終的な回答は 権威DNSが返す

5. ドメインの階層構造と「ゾーン」

名前解決の流れがわかったところで、DNSの管理単位である「ゾーン」について整理します。
ドメイン名は、app.dev.example.com のように右から左へ階層構造になっています。

この階層構造の中で、権威DNSが DNS レコード（A / CNAME / TXT など）を管理する範囲を ゾーン と呼びます。
Route 53 の「ホストゾーン」も、まさにこのゾーン単位で DNS レコードを管理するための場所です。

6. 各レコードの役割（NS / A / CNAME / TXT）

ここからは、先ほど説明した「ゾーン」がどのように管理され、名前解決に反映されるのかを押さえるために、各 DNS レコードの役割を整理します。

NSレコード：このゾーンを管理する権威DNSはどこか？

NS（Name Server）レコードは、
「このゾーンの名前解決は、どの権威DNS（ネームサーバ）が担当するか」を示すレコードです。

言い換えると、NSレコードは
ゾーンと、それを管理する権威DNSを結びつけるためのレコードです。

例：example.com というゾーンを管理する権威DNSを示す場合
たとえば、example.com というゾーンを管理している権威DNSは、
example.com の NS レコードとして次のように定義されています。

example.com の NS レコードの値 = ns1.example-dns.com
                                 ns2.example-dns.com
                                          :

これにより、リゾルバが www.example.com や api.example.com を引くとき、
example.com のゾーンに関する問い合わせは、これらのネームサーバ（権威DNS）へ送られます。

このように NS レコードは、
「このゾーンの正解データ（DNSレコード）を誰が管理しているか」を示す役割を持っています。

Aレコード：ドメイン名 → IPアドレス

Aレコードは、ドメイン名を IPアドレスに紐づける最も基本的なレコードです。

例：

  • app.example.com → 203.0.113.10

名前解決の最後に得たい情報は、基本的にこの Aレコードです。

CNAMEレコード：別名へ転送（名前解決を続ける）

CNAME（Canonical Name）レコードは、
「このドメイン名は別名です」として、解決先を別のドメイン名に置き換えるレコードです。

例：

  • app.example.com → app-alb-123456.ap-northeast-1.elb.amazonaws.com

この場合、app.example.com の問い合わせは別名へ変換され、
最終的には app-alb-123456.ap-northeast-1.elb.amazonaws.com の先の DNS レコードを解決してIPを得ます。

TXTレコード：文字列情報（検証用途でよく使う）

TXTレコードは、文字列情報を保持できるレコードで、以下のような用途で利用されます。

  • ACM（AWS Certificate Manager）のDNS検証
  • SPF / DKIM / DMARC（メールの認証）

今回のサブドメイン運用でも、証明書のDNS検証でTXTレコードが登場することが多いです。

ここまででDNSの基本要素を押さえたので、次章ではこれらを実務でどう使うかとして、サブドメインのNS委譲を見ていきます。

サブドメインとNS委譲の仕組み

前章では、DNSの名前解決の仕組みと、 ゾーン・NSレコードといった基本要素を整理しました。 ここからは、それらの仕組みが 実務でどのように使われるのかを見ていきます。 特に、開発や検証の現場でよく登場するのが、 「サブドメインだけを別の場所で管理したい」というケースです。

サブドメインを別の場所で管理したい、とは？

サブドメイン運用では、たとえば次のような状況がよくあります。

  • 親ドメイン example.com はクライアントが管理している
  • しかし dev.example.com は開発チーム側で柔軟に管理したい
    （レコード追加・変更を頻繁に行いたい）

このとき、親ドメイン側に都度

  • app.dev.example.com のA/CNAMEを追加してもらう
  • 検証用のTXTレコードを追加してもらう

という運用にすると、調整コストが高くなり、スピードも落ちます。

そこで利用されるのが NSレコードによる委譲（delegation） です。

NS委譲とは「この範囲はこの権威DNSが答える」という宣言

NSレコードは「このドメイン（ゾーン）の権威DNSはどこか」を示すレコードでした。
つまり、親ドメイン側でサブドメインのNSレコードを登録すると、次のことが起きます。

dev.example.com に関する問い合わせは、親ドメインの権威DNSではなく、
dev.example.com のNSレコードで指定された権威DNS（例：Route 53）へ転送される

これが 委譲です。

以下の図のように、親ドメインとサブドメインで 管理者と権威DNSを分離できます。

例：親ドメイン example.com をクライアントが管理
      サブドメイン dev.example.com を Route 53 に委譲して自分たちが管理

Route 53 での作業イメージ

Route 53 側では、dev.example.com の Public Hosted Zone を作成し、そのゾーンの権威DNS（NS）情報を取得します。あとは、そのNS情報を親ドメイン（example.com）側に登録すれば、dev.example.com 配下の名前解決は Route 53 が応答してくれるようになります。

委譲後の名前解決はどう変わる？

委譲前は、app.dev.example.com の問い合わせは example.com の権威DNSが答える必要があります。
しかし、dev.example.com を Route 53 に委譲すると、問い合わせの流れが以下のように変わります。

  1. リゾルバが app.dev.example.com を引く
  2. .com → example.com の権威DNSへ辿り着く
  3. example.com の権威DNSは 「dev.example.com のことは Route 53 に聞いて」（NSで案内）
  4. Route 53（dev.example.com の権威DNS）が app.dev.example.com のレコードを返す

このように、親ドメイン側が持つのは「委譲先のNS情報だけ」になります。

CNAMEは親ドメイン側に登録する必要がある？

結論から言うと、今回のように NS委譲を行う構成であれば、親ドメイン側にCNAMEを登録してもらう必要はありません。

親ドメイン側が持つべき情報は、dev.example.com の管理先（＝委譲先の権威DNS）を示す NSレコードだけです。

dev.example.com 配下の具体的なレコード（A / CNAME / TXT など）は、委譲先である Route 53 のホストゾーン側で管理します。

たとえば app.dev.example.com を ALB に向けたい場合は、Route 53 のホストゾーンに

  • app.dev.example.com → xxxx.elb.amazonaws.com（CNAME または ALIAS）

を登録すれば完結します。

親ドメイン側は「どこに委譲するか」さえ分かっていればよく、配下のレコードの存在を個別に把握する必要はありません。

まとめ

本記事では、「手順通りに設定すれば動いたが、仕組みがよく分からない」という状態を解消するため、DNSの基本とNS委譲の仕組みを整理しました。

ポイントは、DNSを単なる設定項目の集合として捉えるのではなく、
名前解決がどのように進み、どのレコードがどの役割を担っているのかを流れの中で理解することです。

特にサブドメイン運用においては、

  • どこが権威DNSになるのか
  • どのゾーンを誰が管理するのか

を意識することで、

  • 親ドメイン側に依頼すべき内容は NSレコードのみ
  • A / CNAME / TXT などの具体的なレコードは 委譲先（Route 53）で管理する

という整理が自然に導けるようになります。
「CNAMEが不要」というよりも、「CNAMEを登録する場所が親ドメイン側ではなく、委譲先に変わる」と理解するのがポイントです。

本記事では考え方と仕組みにフォーカスしましたが、
実際に Route 53 上でどのように設定するのか（Hosted Zoneの作成、NSレコードの確認・依頼、ALIAS/CNAMEの設定など） については、別記事で手順ベースにまとめる予定です。

DNSやサブドメイン運用を「なんとなくの手順」ではなく、
理由を理解したうえで設計・依頼できる状態になるための一助となれば幸いです。

新規CTA