カスタムドメインは、理由もなく人を尻込みさせる。本当に重要なレコードはほんの数個、追加するまともな順番があり、そして最初は誰もが引っかかるapexの落とし穴が1つあるだけだ。一度覚えれば、二度と考えなくて済む。
全体の形
どのモダンなホストも — Cloudflare Pages、Vercel、Netlify — 同じように動く。ダッシュボードでドメインを追加し（「保留中」と表示される）、DNSレコードをホストのターゲットに向ける。すると、ホストがTLS証明書を自動的にあなたの代わりに発行してくれる。 nginxも、certbotも、証明書ファイルをあちこちにコピーする必要もない。
ホストのターゲットとは、あなたが向ける先となるホスト名にすぎない。
| ホスト | レコードを向ける先 |
|---|---|
| Cloudflare Pages | your-project.pages.dev |
| Vercel | cname.vercel-dns.com |
| Netlify | your-site.netlify.app |
うまくいく順番
- まずホストのダッシュボードでドメインを追加する。そうすればホストがそれを待ち受けることを知る。
wwwは簡単 —wwwから上記のホストターゲットへのCNAMEを追加する。- apexが落とし穴。 裸のドメイン（
example.com）に生のCNAMEを置くことはできない — DNSの仕様に反するからだ。代わりに、DNSプロバイダの CNAMEフラット化（Cloudflareは自動でこれを行う）か、ALIAS / ANAME レコードを使う。 - 正規（canonical）を選ぶ —
www→ apex または apex →wwwのどちらかにリダイレクトする。両方を生かしてはいけない。家は1つ、URLは1つ。 - 検証を待ち、それから喜ぶ前に HTTPS で解決することを確認する。証明書はたいてい数分以内に降りてくる。
人が忘れる2つのこと
- apex対
www— 両方を設定し、それから一方をもう一方にリダイレクトする。これを飛ばすと、example.comは動くのにwww.example.comが証明書エラーを吐く（あるいはその逆）という事態になる。 - メールは同じドメインを共有する —
example.com上のアプリと同じドメインのメールは問題なく共存する。作業中にMXレコードを削除しないようにだけ気をつけよう。
結論
これはDevOpsプロジェクトではなく、10分の作業だ。ドメインを追加し、www 用に CNAME を1つ、apex用にフラット化/ALIAS、正規を選び、HTTPSを確認する。証明書はもうホストの問題だ — まさにそうあるべきだ。アプリはあるがまだドメインがない？それなら、こちらがデプロイの全工程だ。