背景

株解説や銘柄分析、紹介等をしている自分のサイトにて、

【XServerアカウント】■重要■ [無料独自SSL]SSLサーバー証明書(www.moneychat.life) 更新未完了のお知らせ
サーバーID「-----」で利用中の下記SSLサーバー証明書に関し、
当サポートで有効期限の延長をするための更新作業を行いましたが、
正常に完了することができませんでした。

というお知らせが届き、超恥ずかしい話、今思えばちゃんとDNSなどを理解していなかったなと反省し、改めて学習をしたので、まとめておきます。学習メモですので、間違っているところとか、応用点とかあれば、コメントで教えていただければ幸いです。

私自身、工学部出身でも就職したことがあるわけでもないので、「DNSという分散システムの責務分離」を構造として教わる・学ぶ機会がほぼ無かったですし、エンジニアでも雰囲気でDNSを触っている人は非常に多いんじゃないかなと思います。

XサーバーとRoute53は「役割」が完全に違う

結論から、今回のケースでは、

サービス	役割
Xサーバー	Webサーバー（計算・保存・実行）
Amazon Route 53	DNS（名前 → IP の変換）

通信の流れ上、DNSは入口、サーバーは処理担当という感じ。

Route 53とは

Amazon Route 53 とは、グローバルに分散された、DNS（Domain Name System）のこと。

DNSとは、人間が読むURL（今回は、moneycha.life）を、コンピュータが理解できるIPアドレスに変換するサービス（DNS）のこと。

Route：通信の行き先を決める
53：DNSの標準ポート番号（UDP/TCP 53）

👉 名前からして「ネットワークの中枢」を担うサービス。

今回のケースでは、https://moneychat.life/media を開いたとき、ざっくりいうと：

ブラウザ「moneychat.lifeってどこやねん？」
DNSサーバ「IPは 93.184.216.34 だぜ」
ブラウザ「OK、そのIPに接続するわ」

といった感じ。

とはいえ、Route 53 がやっているのは、「DNS = IP変換」だけではなく、例えば、

ドメイン登録
1. moneychat.life を購入・管理
2. com .net .jp など色々扱う
DNS
1. moneychat.life → IPアドレス
2. サブドメイン（sub.moneychat.lifeなど）
トラフィック制御（ここが強い）
3. 負荷分散
3. 障害時の自動切り替え
3. 地域ごとの振り分け

みたいな感じで、単なるDNSではなく「インフラ制御装置」としても機能。

DNSレコードとは

DNSレコードとは、「ドメイン名に関するルールや情報をDNSサーバに登録した1行の設定」。
で、まあこんな感じで、色々設定をする必要があるのだが、

レコード	役割
A	ドメイン → IPv4
AAAA	ドメイン → IPv6
CNAME	別名
MX	メール
TXT	認証・設定
NS	DNSサーバ指定

例えば、
名前: example.com
種類: A
内容: 93.184.216.34

とあれば、「example.com はこのIPだよ」という宣言になる。
DNSレコードがないと、基本的に通信不可ということになる。

レコード別簡単解説

Aレコード（最重要） は、
👉 ドメイン → IPv4アドレス
という役割がある。これがないと、Webサービスが存在しないのと同じようなもの。

AAAAレコード は、
👉 ドメイン → IPv6アドレス
という役割で、これがないと、

IPv6環境では通信不可
一部モバイル網で遅延 or 失敗

ということが起こるかもしれない。
IPが、IPv4アドレス とIPv6アドレス の二つもあってややこしいですが、
一言でまとめると、
「IPv4は最初の設計で数が足りなくなり、IPv6は作り直しとして生まれた。しかし互換性がないため完全移行できず、今も併存している。」
ということのようです。
ここについて詳しくはまた別途学習し、まとめたいと思います。

CNAMEレコード は、
👉 ドメインの別名定義
例えば、www.example.com → example.com
みたいな。これがないと、www.example.com が開かない。

MXレコード は、
👉 メールの配送先を指定
例えば、example.com → mail.example.com
これがないと、

メールが届かない
送信元から拒否される

といったことが、起こりうる。

TXTレコード は、
👉 認証・ポリシー宣言
で、

SPF（送信元認証）
DKIM（改ざん防止）
ドメイン所有確認

といった用途がある。これがないと、

メールが迷惑メール扱い
なりすまし可能
SaaS連携不可

といったセキュリティ崩壊が起こりうる。

NSレコード は、
👉 どのDNSサーバが正かを指定
していて、これがないと、

DNS問い合わせが迷子
解決自体が不可能

など、ドメインが無効化されてしまう。

他にも、SOAレコード などがあり、
ゾーンの管理情報
の役割を担っている。

ここまでをまとめると、
DNSレコードが存在しない場合、名前解決が失敗し、クライアントはIPアドレスを取得できない。その結果、サーバが稼働していても通信は開始されない。
ということになるでしょう。

Xサーバーで表示されるTXTをRoute 53に登録する

XサーバーでSSL設定をする際に、Xサーバーで表示されるTXTをRoute 53に登録する必要がありました。
この行為は、「このドメインは本当に私が管理しています」という証明を、DNSを使って行っているということ。

Amazon Route 53
- ドメインの公式なDNS管理者（権威DNS）
エックスサーバー
- Webサーバ・SSLを発行したい側
Let's Encrypt
- CA（認証局）
- 証明書を発行する主体
ブラウザ / OS
- 「この証明書は信用できるか？」を判断する側

SSL証明書は「誰でも」発行できてはいけない。

もし確認なしで発行できたら、

警告
他人のドメインで、偽のSSL証明書を作り、なりすましサイトを作る。

みたいなことができてしまう。
それを防ぐ仕組みが「ドメイン所有権確認」。

ここでは、TXTレコードは、「DNSを使った本人確認（身分証明）」をしている。

なぜ TXT レコードなのか

ここで、なんで TXT レコードなのかという疑問が湧いた。
結論から言うと、

NOTE
DNSレイヤで任意の文字列を安全に公開できる唯一の手段であり、
HTTPやTLSに依存せず、
到達以前にドメイン所有権を証明できる。
そのため CA は DNS-01 チャレンジに TXT レコードを用いる。」

から。例えば、TXTは、

_acme-challenge.moneychat.life TXT
"abc123xyz456"

みたいな感じなわけですが、

自由な文字列
他用途と衝突しない
解釈は外部ロジックに委ねる

というので、認証に最適。
また、通信全体を簡単に見直すと、

DNS通信
TCP接続
TLS（SSL）
HTTP通信

というような流れなので、DNSは「HTTPやSSLより前」に存在している。
「DNS over HTTPS（DoH）」というのもあるが、これはまた別記事にて。

話を戻すと、
おれ「このドメイン（今回は、moneychat.life）のSSLを発行したい」
Xサーバー「じゃあ、この文字列をDNSに登録してください」
ということで、
おれ「Route 53にTXTを登録しますね」「しました！」
認証局「本当にTXTあるかな？」→「ある！」→「SSL発行OK」

みたいな流れになっているというわけだ。

本題：DNS名前空間の未完結によるSSL自動更新失敗

ここまで御託をだらだら書いてすみません。
しかし、上記をある程度理解していないと、どんな問題になにをして対処したのか、自分でも説明できない状態になってしまうので、あまりまとまりのない文章と構成になってしまったが、記録しました。

おれのサイトの身に何が起きていたのか！？

Xサーバー上で運営しているサイトに対し、
SSLサーバー証明書（Let’s Encrypt）が自動更新されない

そのたびに

SSLをOFF→ON
Xサーバーに表示されたTXTレコードをAmazon Route 53 に登録
一定時間待つ

という手動対応が繰り返し発生。

結論としては、

DNSの名前空間が「未完結」 だった。

moneychat.life
→ Aレコードあり
www.moneychat.life
→ DNSレコードが存在しなかった（NXDOMAIN）

なぜそれがSSL更新失敗につながるのか

Let’s Encrypt の更新フローは、

CA（Let’s Encrypt）は証明書に含まれるすべてのFQDN（完全修飾ドメイン名）について
ドメイン所有権検証（Domain Validation）を行う
その検証は
a. DNS（TXTレコード）
b. HTTP
のいずれかで行われる

👉 1つでも検証に失敗すると、更新全体が失敗する。

今回の状態は、

moneychat.life → 検証可能
www.moneychat.life →
- DNS解決不可
- TXTレコードを置く場所自体が存在しない

👉 名前空間の欠損により検証不能。

解決策

ということで、DNS名前空間を完全に定義した。
具体的には、Route53 に以下を恒久的に追加

www.moneychat.life
CNAME → moneychat.life

これにより：

moneychat.life
www.moneychat.life

の両方が常に解決可能となり、証明書に含まれる全FQDNの到達性が保証された、というわけだ。

お疲れ様でした。

わからないところ、間違っているところ、もっといい方法がある場合は、コメントでもDMでも教えてください。