独自ドメインとDNSをCloudflareで管理する基本
このサイト（pastora.jp）のホスティング移行にあわせて、ドメインのDNS管理もCloudflare側へ寄せることにしました。移行作業の中では地味な部類ですが、DNSは失敗したときの影響がいちばん分かりやすい場所でもあります。設定を間違えればサイトが表示されなくなるし、やり方を間違えればメールが届かなくなる。だからこそ、手を動かす前に「何を・どの順番で・どこまで確認するか」を自分用に整理しておくことにしました。この記事はその整理メモです。ホスティング側（NetlifyからCloudflare Pages）の移行手順はNetlifyからCloudflare Pagesへ移すときのチェックリストにまとめていて、この記事はそのDNS編になります。
そもそも何を移すのか：レジストラとネームサーバは別物
最初に区別しておきたいのが、ドメインの「登録」と「DNSの管理」は別の話だということです。
- レジストラ：ドメインそのものを契約・更新する窓口。ドメインの所有はここで管理する
- ネームサーバ（権威DNS）：そのドメインのレコード（後述）を保持し、問い合わせに最終回答を返すサーバ
- ゾーン：1つのドメインとそのサブドメインのレコード一式を管理する単位。Cloudflareでは、追加したドメインがそのまま1ゾーンになる
CloudflareでDNSを管理する（フルセットアップ）というのは、ドメインの登録先はそのままに、ネームサーバだけをCloudflare指定のものへ切り替える作業です。切り替えが終われば、レコードの編集はすべてCloudflareのダッシュボード側で行うようになります。逆に言えば、切り替え前に旧環境でレコードを直しても、移行後の世界には何も影響しません。この「どちらの画面が正なのか」を取り違えると、直したつもりで反映されない、という混乱が起きます。
レコードの種類：よく使う5つ
DNSレコードは「名前に対して何を返すか」の指示書です。個人サイトの運用で日常的に触るのは、だいたい次の5種類です。
| 種別 | 向ける先 | 用途 | 注意 |
|---|---|---|---|
| A | IPv4アドレス | ホスト名とサーバの対応づけの基本形 | プロキシ対象。向き先のIPを間違えるとサイトが落ちる |
| AAAA | IPv6アドレス | AのIPv6版 | IPv6側だけ古い向き先が残っていると、環境によって不具合が出る |
| CNAME | 別のホスト名 | 別名をつける。ホスティングの向き先指定で多用 | 向き先は名前であってIPではない。連鎖の先まで正しいか確認する |
| MX | メールサーバのホスト名（優先度つき） | そのドメイン宛メールの配送先 | 数字が小さい方が優先。プロキシ対象外（常にDNS only） |
| TXT | 任意の文字列 | SPF／DKIM／DMARC、ドメイン所有権の確認など | 中身はただの文字列なので、消しても見た目は何も変わらない。それが怖い |
Cloudflareではゾーンの頂点（pastora.jp そのもの）をレコード名 @ で表します。また、通常のDNSでは頂点にCNAMEを置けませんが、CloudflareはCNAME flatteningという仕組みで頂点のCNAMEも扱えるようになっています。ホスティング側から「頂点ドメインにCNAMEを設定してください」と案内されるケースでは、この仕様が前提になっていることがあります。
TXTレコードは地味ですが、実務上の事故率がいちばん高いと思っています。メール認証（SPF／DKIM／DMARC）も、各種サービスの所有権確認も、全部TXTに同居しているからです。「用途不明のテキストが1行あるだけ」に見えて、消すと静かに何かが壊れます。詳細は後半のメールまわりの話で触れます。
移行の手順：ゾーン追加からネームサーバ変更まで
公式ドキュメントに沿った大まかな流れは次のとおりです。
- Cloudflareのアカウントでドメインを追加し、プランを選ぶ（これが「ゾーン追加」）
- 既存のDNSレコードが自動スキャンされ、ゾーンに取り込まれる。ただし全レコードの検出は保証されないので、旧環境のレコード一覧と突き合わせて不足分を手で足す
- レジストラ側でDNSSECが有効になっている場合は、先に無効化しておく
- レジストラの管理画面で、既存のネームサーバを削除し、Cloudflareから割り当てられた2つのネームサーバを正確に登録する
- 反映を待つ。公式の案内では最大24時間程度。Cloudflare側のステータスが Active になれば切り替え完了
- DNSSECを使っていた場合は、Cloudflare側で改めて有効化する
ポイントは2と3です。2の突き合わせを省くと、「移行した瞬間に一部のサブドメインやメールが消える」という事故になります。自動スキャンはあくまで出発点で、信用しきらない前提で進めるのが安全です。
注意：DNSSECはネームサーバ変更の前に切る DNSSECが有効なままネームサーバを変更すると、ドメイン自体に到達できなくなるおそれがある、と公式ドキュメントにも明記されています。移行前にレジストラ側で無効化し、ActiveになってからCloudflare側で有効化し直す、という順番を守ります。
プロキシ（オレンジ雲）は何をしているか
CloudflareのDNS画面で特徴的なのが、レコードごとの雲アイコンの色です。オレンジ色（Proxied）にすると、その名前へのWebアクセスはCloudflareのネットワークを経由するようになり、DNSの応答として返るのはオリジンサーバのIPアドレスではなく、Cloudflareのanycast IPになります。その結果、キャッシュやDDoS防御、WAFといったCloudflareの機能がその通信に効くようになります。
グレーの雲（DNS only）は逆で、登録した値そのものを返して通信は直接オリジンへ向かいます。
| 状態 | DNSが返すもの | 効くもの | 向いているレコード |
|---|---|---|---|
| Proxied（オレンジ雲） | Cloudflareのanycast IP | キャッシュ、DDoS防御、WAF、各種ルール、オリジンIPの秘匿 | サイト本体などWebトラフィックを受けるA／AAAA／CNAME |
| DNS only（グレーの雲） | 登録したIPアドレス／値そのもの | 名前解決のみ | メール関連、所有権確認用、Web以外の用途のレコード |
大前提として、プロキシできるのはA／AAAA／CNAMEだけです。MXやTXTは常にDNS onlyになります。また、A／AAAA／CNAMEであっても全部オレンジにすればよいわけではありません。たとえば各種サービスのドメイン所有権確認に使うCNAMEは、DNS onlyにするのが公式の推奨です。確認先のサービスは「登録した値がそのまま返ってくること」を前提にチェックしているので、プロキシを挟むと確認が通らなくなることがあります。メールサーバのホスト名を指すAレコードも同様で、プロキシしてしまうとメール配送が成立しません。
判断に迷ったら、「その名前はブラウザからのWebアクセスを受けるのか」で切り分けるのが分かりやすいです。Yesならオレンジ、Noならグレー。これが基本形だと思っています。
TTLと「浸透」の考え方
DNSの話でよく聞く「浸透するまで時間がかかる」という表現は、正確にはTTL（Time to Live）の話です。TTLは「このレコードの答えを何秒キャッシュしてよいか」という有効期限で、世界中のリゾルバや端末は期限内は古い答えを持ち続けます。だからレコードを書き換えても、キャッシュが切れるまでは人によって見える結果が違います。「浸透待ち」の正体はこれです。
Cloudflareの仕様で押さえておきたいのは次の点です。
- プロキシ済みレコードのTTLは Auto に固定され、値は300秒。変更はできない
- DNS onlyのレコードはTTLを選べる（無料プラン等では60秒から1日まで）。Autoを選んだ場合も300秒
- ネームサーバの切り替え自体は、レジストラ側の反映を含めて最大24時間程度を見ておく
実務的な含意はシンプルで、切り替え直前に慌ててTTLを下げるような小細工は、少なくともプロキシ済みレコードについては効かないということです。その代わり、切り替え作業は「しばらく旧環境と新環境の両方に同じ内容が応答しても問題ない状態」で行うのが大事になります。旧ホスティングを即座に畳まず、切り替えが落ち着くまで残しておくのは、そのための保険です。
メール系レコードは「消すと静かに壊れる」
最後に、移行でいちばん警戒している部分です。サイトのAレコードを間違えれば表示で気づけますが、メール系レコードの事故は発見が遅れます。自分宛のメールが届いていないことには、誰かが連絡をくれるまで気づけないからです。
注意：メール系レコードの欠落は「無言で」壊れる MXレコードが無い・向き先が間違っていると、そのドメイン宛のメールは配送先を失います。さらに、MXの向き先であるメールサーバのホスト名（例：
mail.example.com）自体のAレコードが欠けていても、同じように届きません。そしてSPF／DKIM／DMARCといったTXTレコードを消してしまうと、今度は自分が送るメールが相手側で迷惑メール扱いされたり、なりすまし対策が外れたりします。受信と送信、両方向の事故が「エラー表示なし」で起きるのがメールまわりの怖さです。
対策は地味なものです。移行前に旧環境のレコード一覧をそのまま書き出し、MXとTXTについては1行ずつ新環境と突き合わせる。特にTXTは「何に使っているか分からない行」ほど消さない。所有権確認用のTXTは確認が終われば不要なものもありますが、判定がつかないものは残す側に倒す、というのが自分のルールです。ゾーンをきれいに掃除したくなる気持ちは分かりますが、DNSの掃除は移行のタイミングでやることではありません。
まとめ代わりの判断メモ
- DNS移行の本体は「ネームサーバの切り替え」で、ドメインの登録先は動かさない
- 自動スキャンは信用しきらず、旧環境の一覧と必ず突き合わせる
- オレンジ雲はWebアクセスを受けるレコードだけ。迷ったら「ブラウザが使う名前か」で判断する
- 「浸透」はTTLのキャッシュ切れ待ち。プロキシ済みレコードは300秒固定と割り切る
- メール系（MX／TXT）は消すと無言で壊れるので、突き合わせを最優先にする
DNSは一度安定すれば触る機会の少ない領域ですが、だからこそ移行の瞬間に知識が要ります。このサイトの移行が完了したら、実際に詰まった点があれば追記するつもりです。切り替え後に確認する項目は、ホスティング移行後の確認リストに切り出しています。