ドメインとDNSを切り替える前に知っておくこと——Aレコード・CNAME・TTL

DNSの切り替えは、設定画面で値を書き換える作業そのものより、その前の準備で段取りが決まります。私が先に確認するのは、いま何のレコードが載っているか、変えるのはどの行だけか、古い値がいつまで残るか、の3つです。Aレコード・CNAME・TTLの意味が分かると、この3つを自分で見積もれるようになります。

AレコードとCNAMEは「向け先の書き方」が違う

RFC 1035によると、Aレコードの中身はIPv4のアドレスで、CNAMEの中身は別のドメイン名です。つまり、Aレコードは住所をそのまま書き、CNAMEは「あの名前と同じ」と書く形だと考えています。

レコード	書くもの	例
A	IPv4アドレス	example.com → 192.0.2.1
CNAME	別のドメイン名	www.example.com → example.net

実務で引っかかりやすいのが、example.com のようなサブドメインなしの名前（apex）です。RFC 1034の3.6.2節には、CNAMEがある名前には他のデータを置かないとあります。apexにはSOAやNSが置かれるので、標準の形ではCNAMEと同居できません。公開先の案内が分かれるのはこのためで、たとえばVercelのドキュメントはapexをAレコード、サブドメインをCNAMEで設定する形を案内しています。一方、CloudflareのCNAME Flatteningのように、apexにCNAMEを設定でき、問い合わせにはIPアドレスを返す仕組みもあります。どちらを使うかは、DNSを管理しているサービスと公開先の案内を見て決めます。

TTLは「古い値が残ってよい時間」

RFC 1034はTTLを、レコードをキャッシュに保持できる時間の上限と定義しています。単位は秒なので、3600なら1時間、86400なら24時間です。

ここから、切り替えの段取りに関わることが2つ分かります。

• 新しい値が行き渡るまでの時間は、書き換えたあとの値ではなく、書き換える前のTTLに左右されます
• TTLを下げる作業も、古いTTLが切れるまで全体には効きません

たとえばTTLが86400のレコードは、当日の朝に短くしても間に合いません。RFC 1034にも、変更の前にTTLを下げて不整合を抑え、変更後に元へ戻す考え方が書かれています。私はこの「下げる日」を、切り替え日から逆算して進行表に入れる作業として扱っています。

もう1つ、新しく作るサブドメインにも待ち時間があります。RFC 2308によると、「その名前は存在しない」という応答もキャッシュされ、その期間はSOAレコードのTTLとMINIMUMの小さいほうで決まります。設定前に確認のつもりで引くと、その結果がしばらく残る場合があります。

切り替えの段取りは5段階で考える

段階	やること
棚卸し	A・CNAME・MX・TXTなど、現在のレコードを全部控える
範囲を決める	レコードだけ変えるのか、ネームサーバーごと移すのかを決める
TTLを下げる	切り替え日から古いTTL以上前に短くする
切り替える	値を変更し、権威サーバーの応答を確認する
片付け	表示・メール・証明書を確認し、TTLを戻す

差が大きいのは2段階目です。Vercelのドキュメントには、Webサイト用のAやCNAMEを変えるだけなら他のレコードを移す必要はないこと、ネームサーバーを変える場合はメール用のMXや認証用のTXTも先に写すことが書かれています。メールを別サービスで運用している案件では、この範囲の確認が特に重要だと考えています。

ネームサーバーを移す場合は、確認項目がさらに増えます。Cloudflareのセットアップ手順は、DNSSECが有効なら置き換え前にレジストラ側で無効にするよう案内し、更新を最大24時間待つとしています。手順はサービスごとに異なるので、移行先の公式手順を切り替え日より前に読んでおきます。

また、切り替え直後は古い値と新しい値の両方にアクセスが届く可能性があるので、旧サーバーは古いTTLが切れるまで止めないようにしています。戻す判断の考え方はリリース前チェックリストにまとめました。

明日から試せる一手

担当サイトのドメインで、dig example.com A +noall +answer を実行してみてください。応答に表示される数字がTTLです（キャッシュ経由の場合は残り秒数になります）。あわせて dig example.com NS と dig example.com MX の結果を控えておくと、切り替えの見積もりに使う棚卸しの出発点になります。