🏷️

外部ドメインサービス＋Route53＋ACMと学ぶDNSサーバー（ACMが生成するCNAMEの話）

maimy

2023/11/01に公開

はじめに

AWSを使ってドメインとSSL証明書を取得してWebサイトを配信してみよう！としたところDNSに関する知識不足を痛感したので整理がてらまとめます。分かっていたつもりでもいざ構築しようとすると抜け落ちている諸々を知る、いつものやつです。

この記事の流れ

「外部ドメインサービスとRoute53＋ACMでWebサイトをSSL通信で配信するまで」 を説明した後にDNSに関する知識を振り返ることで、なるほど〜となる記事です。

この記事で話さないこと

DNSの詳しい基礎知識
Webサイトが繋がる仕組みの話
AWS各サービスの基礎知識

DNSのややこしい（と私は感じる）行ったり来たり（しているように見える）名前解決の話はしていません。

やったこと

CloudFront+S3による静的Webサイト配信を構築しました。

外部ドメインサービス（お名前.com）で取得したドメインをRoute53で管理
ACMでSSL証明書を発行
CloudFrontのディストリビューションに↑で取得したドメインと証明書を設定

作業内容

前提

お名前.comでドメインを取得しておきます。
S3にファイルをアップロード（今回はNext.jsで簡易的に作成した静的コンテンツをビルドしてアップロード）
S3バケットポリシーでOAC（オリジンアクセスコントロール）にアクセス許可を付与

取得したドメインをRoute53で管理する

Route53でホストゾーンを作成する
お名前.com側でネームサーバーを設定する
お名前.comのドメイン設定でネームサーバーを他社管理のネームサーバーに変更することができます。
「他のネームサーバーを利用」の「ネームサーバー情報を入力」の欄に、Route53のホストゾーン内のタイプがNSのレコードの値を4つ入力します。

CNAMEレコードとAレコードはこの段階ではないかと思います。（画像は、後述する作業を行っているためレコードが存在）

ACMでSSL証明書を発行する

CloudFrontで使用するため、リージョンは米国東部（バージニア北部）us-east-1に指定します。

証明書をリクエスト
- 完全修飾ドメイン名（FQDN）：取得したドメイン名
- 検証方法：DNS検証
- キーアルゴリズム：RSA2048（現在最も広く使用されている）
証明書のCNAMEレコードをRoute53ホストゾーンに登録
DNS検証を指定して証明書をリクエストすると、ACMがCNAMEレコードを生成します。この値をRoute53に登録します。（レコード名にはCNAME名、値にはCNAME値）

※発行済みの画面のためステータスが成功になっています。

CloudFrontにドメインと証明書を設定する

ディストリビューションを作成する
【設定内容】
- オリジンの設定：今回はS3にアップロードした静的ファイルを指定
  - オリジンアクセス：OAC（オリジンアクセスコントロール）を指定。オリジン（S3バケット）へのアクセスをCloudFrontからの認証済みリクエストに制限する。
  - ビューワープロトコルポリシー：（せっかく証明書を発行するしセキュアにしたいので）「Redirect HTTP to HTTPS」または「HTTPS only」を指定します。
ここでドメインと証明書の設定もできますが、次項に書きます。
代替ドメイン（CNAME）とカスタムSSL証明書を設定する（作成時、または作成後でも設定編集可能）
ディストリビューションの設定で代替ドメイン（CNAME）に取得したドメイン名とACMで発行したSSL証明書を指定します。
※代替ドメインを指定するためにはSSL証明書も必須です。

Route53ホストゾーンにAレコードを設定

エイリアスを使用してCloudフロントにルーティングするレコードを登録します。

動作確認

https://［ドメイン名］ にアクセスするとS3にアップロードしたコンテンツが配信されています！
証明書も確認できました。httpsをhttpに変えてみると、httpsにリダイレクトされることも確認。
Route53で名前解決→CloudFront経由でS3のコンテンツを取得。ACM発行のSSL証明書により暗号化された通信を確立、という流れでした。

必要だった前提知識（DNSのこと）

上記作業を進める中で、「よく分からないけど手順通りにやってみよう」となってしまった箇所が以下です。

ホストゾーン？
ネームサーバーの設定？
CNAMEレコードを登録？

用語としてなんとなく知っていたものの、今なぜこの作業を？どういう役割で？と疑問に思ったのでDNS周りの知識を振り返ることにしました。

前提の前提

DNS（Domain Name Sytem）とは：ドメイン名とIPアドレスを紐付ける＝名前解決の仕組み
DNSはドメイン名データベースに問い合わせることで名前解決を行う。このデータベースは複数サーバーに内容を分散している分散型データベースである。
【例】「www.hogehoge.co.jp」（これは完全修飾ドメイン名（FDQN））
- トップレベルドメイン「jp」はセカンドレベルドメイン「co」の上の階層にある。
- 「jp」は「co」というホストを持ち、「co」は「hogehoge」というホストを持ち、「hogehoge」は「www」というホストを持つ。＝各ホストは下の階層に1つ以上のホストを持つ。
一番上の階層は根っこで、ここから世界中のホストを辿ることができる。
これらはツリー構造となっており、この空間を「ドメイン名前空間」と言う。

ネームサーバー（NS）

名前解決を行うサーバーのこと。自身の直下にあるホストの情報（ドメイン名とIPアドレスの紐付け）を知っている。上記例で言うと、「jp」や「co」等にはそれぞれネームサーバーがある。「hogehoge」にもある。
実際にWebサイトを構築する際は、独自または使用しているネームサーバーにホスト登録を行うことで名前解決が可能になる（今回の記事で行っているのはこれ）

ゾーン（ホストゾーン）

ネームサーバーが管理している範囲のこと。「ネームサーバーにホスト登録」とは「ホストゾーンにレコードを登録」とも言える。Route53での言い回しは後者。

リソースレコード

ネームサーバーが保持する情報のこと。（ネームサーバーがデータベースであるとしっかり考えるとここも腑に落ちる）
単にドメイン名とIPアドレスの紐付けだけではなく、様々な情報を持っている。その一つとして、リソースにはいくつかのタイプがある。
（例）

A：IPアドレス（IPv4形式）
AAAA：IPアドレス（IPv6形式）
NS：各リソース（ドメイン）が保持するホストを管理するネームサーバー＝下階層のネームサーバー
次にどのサーバーに問い合わせたら良いかを示す
CNAME：各リソース（ドメイン）の別名
SOA：ゾーンに関する情報
TXT：コメント等の文章

疑問の答え

ホストゾーンとネームサーバー設定
Route53はホストゾーンを作成するとネームサーバーが割り当てられ、既存ドメインのネームサーバーとしての役割を果たします。

お名前.comで設定したネームサーバーはRoute53ホストゾーンに割り当てられたものでした。つまりお名前.comで取得したドメインのネームサーバーとして、Route53で作成したホストゾーンが使われるということです。

ホストゾーンにCNAMEレコードを登録
ACMが生成したCNAMEレコードを証明書が欲しいドメインのホストゾーン（お名前.comで設定したネームサーバー＝Route53ホストゾーン）に登録することでDNS検証が行われます。
今回の作業を図にまとめると以下のようになります。

もう一つの謎を解く

今回、一番のハマりポイントはACMでの証明書発行リクエストが保留のままになったことでした。
原因はリクエスト後にACMが生成するCNAMEレコードをRoute53ホストゾーンに登録していなかったこと。DNS検証を指定しているにも関わらずこの作業が抜けていたために、ドメインの所有・管理を立証できませんでした。
単に作業不足だったのだと設定最中では思いましたが、公式F&Qの「DNS検証」の内容を読むと原因をさらに深掘りすることができました。

よくある質問 - AWS Certificate Manager | AWS

Q:DNS 検証とは何ですか?

DNS 検証では、ドメインの所有権は CNAME レコードを DNS 設定に追加することで検証できます。DNS 検証によって、ACM からパブリック SSL/TLS 証明書をリクエストする際にドメインの所有を立証しやすくなります。

CNAMEレコードの追加がDNS検証に必要だということが分かる。

Q.ACM はどのようにして CNAME レコードを構成しますか?

DNS CNAME レコードには、名称とラベルの 2 つのコンポーネントがあります。ACM が生成した CNAME の名称のコンポーネントは、下線文字 (_) と、それに続いて、お使いの AWS アカウントとドメイン名に関連付けられた文字列であるトークンで構成されています。ACM は、ドメイン名の前に下線とトークンを加えて名称コンポーネントを構成します。ACM は、同じく AWS アカウントとドメイン名に関連付けられた別のトークンの前に付加された下線から、ラベルを作成します。ACM は、AWS が検証に使用する DNS ドメイン名 (acm-validations.aws) の前に、下線とトークンを付加します。

リクエスト後にコンソールに突然現れているCNAMEの謎が解ける（ACMが生成していたことを知る）。

まとめ

一言で：ACMのDNS検証はホストゾーンにCNAMEレコード追加を忘れない！

AWSは手順通りにぽちぽちすれば何でもいい感じにやってくれるため、実際何をしているの？という部分の理解が浅くても使おうと思えば使えてしまいます。
このことを逆手に取ってみると、クラウドが触れたら土台となる基礎も分かるし基礎が分かっていればクラウドも扱いやすい。
AWSの資格勉強をしていても常々感じています。記憶力よりも基礎力があった方が効率よく学べるし、AWSの勉強が基礎力を鍛えることにも繋がっている。そして実際に構築すると抜け落ちていた知識を埋めることができ、さらに試験問題もぐっと解きやすくなります。良い循環。
学習サイクルがいい感じに回っているので、またこうしてまとめていきたいです。

GitHubで編集を提案

Fusic 技術ブログPublication

さまざまな個性を受け入れて有機的につなぐ社内環境を整える。あらゆる事業機会の創出と実現を繰り返し、世の中に対する視点を絶えず増やして成長していく。あっと驚くような角度から発展できるポイントを見つけ、そこにいい感じにフィットする形でテクノロジーを組み込んで、世の中をちょっとずつ、時には大胆にアップデートしつづけていく。