CloudflareはDNSレコードの旧い画面を廃止した。新しい画面では、5月の発表のあとに足された、種類の変更（AからCNAMEなど）ができる ── 変える前の値を控え、変えた後に外から答えを聞く13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — 旧い画面が廃止され、レコードの種類を画面で変えられるようになった
   1. 10月30日の変更履歴に書かれたこと
   2. 5月の最初の告知との違い
   3. 画面の見た目の変更
2. 02 なぜ・背景 — 種類を変えるのは、値を変えるより間違いが広がりやすい
   1. 種類を変えると、何が変わるか
   2. CNAMEは、同じ名前に他のデータを置けない
   3. TTLが長いと、変えた結果が見えるのが遅れる
   4. 変更の伝わり方は、一度にそろうとは限らない
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 「dig」は、DNSに答えを聞くコマンド
4. 04 型別 — 適用範囲、書かれていないこと、前と後に確かめる手順
   1. 🅰 適用範囲 — この変更が関係する人
   2. 🅱 この変更履歴が書いていないこと
   3. 🅲 手順1 — 変える前の値を、控える
   4. 🅲 手順2 — いまの答えを、外から聞いておく
   5. 🅲 手順3 — 同じ名前の他のレコードを、数える
   6. 🅲 手順4 — 変更の前に、TTLの扱いを決める
   7. 🅲 手順5 — 変えた後に、権威サーバーとリゾルバーの両方に聞く
   8. 🅲 手順6 — 実際のページを開いて、見る
   9. 🅲 手順7 — 戻し方を、先に書いておく
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 種類を変えずに済ませる方法
   1. 変え方の選択肢を並べる
   2. TTLを短くする代わりに、時間帯を選ぶ
   3. 確認の道具を使う
7. 07 当サイトで確かめたこと — 当サイトはCloudflareを使っていない
   1. 当サイトのDNSの答えを、サーバーの中から聞いた
   2. 外から確かめる、という同じ形の記事
8. 08 このテーマは、ここまで — Cloudflareと、DNS・証明書の記事の流れ
   1. これまでの記事
   2. 今回の記事の位置
9. 09 この記事のまとめ

01 何が書いてあるか — 旧い画面が廃止され、レコードの種類を画面で変えられるようになった

Cloudflareは2026年10月30日、DNSのレコードを管理する新しい画面を、すべてのプランで標準にしたと変更履歴に載せた。旧い（classic）画面は廃止され、ダッシュボードからは使えない。新しい画面では、最初はできなかった既存のレコードの種類の変更が、いまはできる。変更履歴によれば、5月の発表のあとに足された機能である。たとえば、AレコードをCNAMEレコードに変える操作である。この記事は、そのような変更を担当サイトのDNSで行うときに、変える前に何を控え、変えた後に何を外から確かめるかを、13項目にまとめる。Cloudflareを使っていない人にも当てはまる確かめ方を中心にする。

10月30日の変更履歴に書かれたこと

変更履歴の要旨は次のとおりである。5月に告知した新しいDNSレコードの画面が、Enterpriseを含むすべてのプランで既定になった。旧い画面は廃止された。新しい画面は、最初のうちは既存のレコードの種類を変えられなかったが、その後に足されて、いまは変えられる。変更履歴は、足された時期を書いていない。ダッシュボードは、この操作に、複数の変更をまとめて送るAPIを使っている。画面の使い方で問題があれば、契約の担当チームかサポートに連絡する、と書かれている。

5月の最初の告知との違い

5月20日の告知は、希望すれば新しい画面を使えると書き、数週間かけて、まずFreeプラン、次に有料プランで既定になると書いていた。予定の日付も載っていて、5月20日から6月5日がFree・Pro・Business、6月8日から7月3日がEnterpriseで、日付は反映の様子によって変わりうるとも書かれていた。この5月の告知の本文には、種類の変更ができるかどうかの記載が見つからなかった。10月の変更履歴が、最初はできなかったと書いているので、5月から10月の間に追加された機能だと読める。これは筆者の読みである。

画面の見た目の変更

5月の告知によれば、新しい画面は、表の列の幅を変えたり隠したりでき、行を固定でき、絞り込みにAND・ORの条件が使える。入力欄が大きくなり、長い値が途中で切れない。スマートフォン向けの表示や、DNS・プロキシの状態・TTLの短い説明もつく。見た目の話なので、この記事では深く扱わない。

02 なぜ・背景 — 種類を変えるのは、値を変えるより間違いが広がりやすい

種類を変えると、何が変わるか

AレコードはIPアドレスを答え、CNAMEレコードは別の名前を答える。種類を変えることは、その名前の問い合わせへの答えの形が変わることである。IPアドレスの数字を書き換えるより、答えの種類が変わる分だけ、影響の範囲が広がる。たとえば、メールを受ける設定や、サイトの所有の確認に使う文字列が同じ名前にあると、種類の変更が干渉することがある。これは筆者の読みで、次の項で仕様の裏づけを示す。

CNAMEは、同じ名前に他のデータを置けない

DNSの基本の仕様であるRFC 1034は、CNAMEが置かれた名前には、他のデータを置かないのが原則だと書く。仕様の文面は、CNAMEがある場所には、他のデータが「あるべきではない」という強さである。理由は、正式な名前と別名で、データが食い違わないようにするためだと書かれている。同じ名前にMXやTXTがあるときにAからCNAMEへ変えると、この原則に当たる。Cloudflareの画面がこの場合にどう扱うかは、今回の変更履歴には書かれていない。

なお、Cloudflareには、ゾーンの頂点（example.comのような名前そのもの）でCNAMEを使えるようにする、CNAMEフラットニングという仕組みがある。文書によれば、CNAMEをたどってIPアドレスを答えとして返す仕組みで、すべてのCNAMEに対して有効にすると、CNAMEそのものが返らないため、第三者によるドメインの所有確認が通らなくなることがある。

TTLが長いと、変えた結果が見えるのが遅れる

TTLは、答えを覚えておく時間である。Cloudflareの文書によれば、プロキシを通すレコードのTTLは自動で300秒に固定され、プロキシを通さないレコードでも自動は300秒である。プロキシを通さないレコードのTTLは、Enterprise以外では60秒から1日の範囲で決められる（Enterpriseは30秒から）。文書は、TTLが長いほど、更新が反映されるまで時間がかかる、と書く。また、手元の端末のキャッシュが、5分より長く古い答えを持つこともある、とも書く。

変更の伝わり方は、一度にそろうとは限らない

まとめて変更するAPIの文書は、削除、更新、作成の順に実行され、1つのデータベースの取引として処理されると書く。同時に、変更の伝わり方は一度にそろうわけではないとも書く。画面で「保存した」の表示が出た瞬間に、世界中のどこから聞いても新しい答えになる、という意味ではない。

03 用語 — 出てくる言葉を、先にそろえる

「dig」は、DNSに答えを聞くコマンド

この記事の手順で使うdigは、DNSの答えを手元から聞いて、画面に出すコマンドである。名前、種類（A・CNAMEなど）、聞く相手のサーバーを指定できる。コマンドの使い方は、この記事では筆者が実際に使った形だけを書く。Windowsの標準の環境には入っていないことが多いので、別の確認の方法（nslookupなど）や、管理会社に頼む方法も代わりに使える。

04 型別 — 適用範囲、書かれていないこと、前と後に確かめる手順

🅰 適用範囲 — この変更が関係する人

状況	画面の変更	この記事の手順
DNSをCloudflareで管理している	関係する	全部使う
DNSを他の会社（レジストラ、レンタルサーバー）で管理している	関係しない	前後の確かめ方は使える
DNSの管理を制作会社や顧客に任せている	相手次第	変更の前に控えを求める

🅱 この変更履歴が書いていないこと

次の点は、10月30日の変更履歴には書かれていなかった。書かれていないことは、推測で埋めない。

• 種類を変えたとき、TTLとプロキシ状態がどう引き継がれるか
• 同じ名前にCNAMEと両立しないレコードがあるとき、画面が止めるのか、変更を通すのか
• 旧い画面にあって、新しい画面で足りなくなった機能があるか
• 種類の変更を、まとめて送るAPIで行うときの、件数の上限

🅲 手順1 — 変える前の値を、控える

Cloudflareの文書によれば、DNSレコードの画面の「Import and Export」から「Export」を選ぶと、現在のレコードを書き出せる。APIでは、ゾーンのexportの口にGETを送る。書き出したものは、ゾーンファイルの形で、レコードごとに、プロキシ状態を示す印（cf-proxied）が付く。再び取り込むときは、この印が取り込み時の設定より優先される。Cloudflare以外を使っている人は、そこの管理画面の書き出し機能か、画面のスクリーンショットで控える。

🅲 手順2 — いまの答えを、外から聞いておく

変える前に、いまの答えを、変える名前ごとに聞いて、メモに残す。聞く相手は2通りにする。権威サーバーに直接聞く方法と、公開のリゾルバーに聞く方法である。コマンドは次の形である。

dig +noall +answer 名前 A
dig +noall +answer 名前 CNAME
dig +noall +answer ドメイン NS
dig @ネームサーバー名 +noall +answer 名前 A
dig @1.1.1.1 +noall +answer 名前 A

1〜2行目は、名前のAとCNAMEの答えを聞く。3行目は、そのドメインのネームサーバーの名前を聞く。4行目は、3行目で分かった権威サーバーに直接聞く。5行目は、公開のリゾルバーに聞く。答えの行には、TTLの秒数も出る。この記事の筆者は、これらの形を実際に使った。

🅲 手順3 — 同じ名前の他のレコードを、数える

種類を変える名前に、他のレコード（MX、TXT、CAAなど）が付いていないかを、画面の一覧と、digの答えの両方で数える。CNAMEにしたい名前に他のデータがあれば、先に整理が要る。数は、変更の前後で比べられるように、メモに書く。

🅲 手順4 — 変更の前に、TTLの扱いを決める

TTLが長いと反映が遅れるので、切り替えの時刻が決まっているなら、変更の前にTTLを短くしておく、というのが筆者の案である。短くしたTTLが効き始めるのは、もとのTTLの秒数だけ待ったあとである。たとえば、いまのTTLが3600秒なら、1時間前までに短くしておく。変更が済んだら、TTLを元に戻すかどうかも決める。

🅲 手順5 — 変えた後に、権威サーバーとリゾルバーの両方に聞く

変更後は、まず権威サーバーに直接聞いて、新しい答えになっていることを確かめる。次に、公開のリゾルバーに聞く。リゾルバーは古い答えを覚えているかもしれないので、TTLの秒数が経ったあとに、もう一度聞く。権威サーバーが新しくて、リゾルバーが古い間は、間違いではなく待ち時間である。TTLが過ぎても古いままなら、変更が反映されていない。

🅲 手順6 — 実際のページを開いて、見る

DNSの答えが正しくても、ページが開くとは限らない。変更した名前のページを、複数開いて、表示が崩れていないか、エラーが出ていないかを見る。まとめて見たいときは、下のチェックリストのあとで紹介する、スクリーンショットのツールが使える。

🅲 手順7 — 戻し方を、先に書いておく

変更の前に、控えたものから、元の状態に戻す手順を書いておく。種類をCNAMEからAに戻すだけで足りるのか、プロキシ状態やTTLも戻すのか。戻すときにも、TTLの待ち時間があるので、「戻すと決めてから、元の答えが見えるまで」の時間を、メモに書いておく。

05 明日、担当サイトで確認できることチェックリスト

以下は、DNSのレコードを変える前と後に確かめることの13項目である。1〜4番目は変更の前の控え、5〜9番目は変更の前の下調べ、10〜12番目は変更の後の確認、13番目は習慣である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。

• 担当サイトのDNSを管理している会社の名前を、台帳の1行に書く（Cloudflareか、他の会社か、不明か）
• Cloudflareで管理しているサイトがあれば、DNSレコードの画面を開いて、旧い画面が出ないことと、レコードの一覧が出ることを、1サイトで確かめる
• Cloudflareで管理しているサイトで、「Import and Export」から書き出しを1回行い、書き出したファイルの置き場を台帳に書く
• Cloudflare以外で管理しているサイトは、レコードの一覧の画面を、スクリーンショットで1枚残して、置き場を台帳に書く
• 種類を変える予定の名前を3つまで選び、名前ごとにAとCNAMEの答えを聞くコマンドを実行して、結果をメモに書く
• ドメインのネームサーバーの名前を聞くコマンドを実行して、画面の管理先と同じ会社の名前かを見る
• 選んだ名前ごとに、同じ名前に付いている他のレコード（MX・TXT・CAA）の数を、画面の一覧で数える
• 選んだ名前のTTLの秒数を、答えの行から読んで、台帳に書く
• 切り替えの時刻が決まっている名前は、変更の前にTTLを短くする日と、元に戻す日を、台帳に書く
• 変更の後に、権威サーバーに直接聞く形で、新しい答えになっていることを、名前ごとに確かめる
• 公開のリゾルバーに聞く形で、新しい答えが見えるまでの時間を、1回目と、TTLの秒数が過ぎたあとの2回目で、メモに書く
• 変更した名前のページを、3ページ開いて、表示とエラーを見て、結果を台帳に書く
• 戻し方の手順を、3行で台帳に書き、書いた日付を添える

06 代替・他の選択肢 — 種類を変えずに済ませる方法

変え方の選択肢を並べる

方法	特徴	気をつけること
画面で種類を変える	1つの操作で、種類が替わる	TTLとプロキシ状態の引き継ぎ方は、変更履歴に書かれていない
新しいレコードを作ってから、古いものを消す	戻しやすい	同じ名前にCNAMEと他の種類は置けない場合がある
削除と作成を、まとめて送るAPIで行う	削除から先に実行されると、文書が書く	変更の伝わり方は、一度にそろうとは限らない
頂点でCNAMEの代わりにフラットニングを使う	頂点でも別名の仕組みを使える	第三者の所有確認が通らなくなることがある

TTLを短くする代わりに、時間帯を選ぶ

TTLを短くする手間をかけずに済ませたいときは、アクセスの少ない時間帯に変更する方法もある。ただし、この方法は、古い答えを覚えているリゾルバーに、TTLの秒数だけ古い答えが残ることを防げない。時間帯を選ぶのは、古い答えの間に当たる人を減らすための工夫で、反映を早める工夫ではない。

確認の道具を使う

変更後のページの見た目を、まとめて確かめたいときは、当サイトの🔧 WEBサイトのスクリーンショットをまとめて撮るツール — 指定したURLの見た目を記録するが使える。変更した名前のURLを並べて、変更前と後に撮っておくと、あとで見比べられる。リンクの漏れを、サイトの中から探したいときは、🔧 WEBサイト内のリンク漏れチェックツール — 内部のリンクが切れていないかを調べるがある。どちらも、DNSの答えそのものは見られない。DNSの答えは、digで聞く。

07 当サイトで確かめたこと — 当サイトはCloudflareを使っていない

当サイトは、Cloudflareを使っていない。そのため、当サイトで、Cloudflareの新しい画面を開いたことも、種類を変えたこともない。この記事の画面についての説明は、すべて変更履歴と文書に書かれていることの要旨である。

当サイトのDNSの答えを、サーバーの中から聞いた

2026年11月2日の午前に、当サイトのサーバーの中から、digで当サイトのドメインを聞いた。ドメインのネームサーバーは、ドメインの事業者のDNSサーバー3台で、TTLはどれも3600秒だった。サイトのホスト名には、Aレコードが1つあり、TTLは3600秒だった。AAAAレコードとCNAMEレコードは、答えとして返らなかった。同じドメインのほかのホスト名にもAレコードが1つあり、TTLは3600秒だった。IPアドレスの数字は、ここには書かない。

TTLが3600秒ということは、当サイトのAレコードを変えた場合、古い答えを覚えているリゾルバーが、最長で1時間は古い答えを返しうる、というのが筆者の読みである。実際にAレコードを変える予定があるわけではない。

外から確かめる、という同じ形の記事

当サイトでは、外から見える状態を確かめる話を、何度か書いてきた。記事「圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方」では、サーバーが止まったあとの確かめ方を書いた。記事「PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法」では、期限の日に当サイトで確かめたことを書いた。DNSでも同じで、画面の「保存しました」ではなく、外から聞いた答えで判断する。

08 このテーマは、ここまで — Cloudflareと、DNS・証明書の記事の流れ

これまでの記事

当サイトでは、2026年10月に入って、Cloudflareの機能の変更と、DNS・通信に関わる確認を、何度か取り上げた。

• DNSの信頼の鍵の入れ替えは、「DNSのルートの鍵が10月11日に替わる。多くのサイト運営者は何もしなくてよい ── 使っているDNSが新しい鍵を信頼しているかを確かめる13項目（2026年10月時点）」で書いた。
• CloudflareのWAFのルールの更新の読み方は、「CloudflareのWAF更新で、PHPの5つのルールは検知が更新されてもBlockのままで、Nuxt Image / IPXの新しいルールは既定で無効だった ── 更新の表を動作・既定の状態・説明の文で読み分ける13項目（2026年11月時点）」で書いた。
• Cloudflareが非公開のIPの配信元を中継する構成は、「Cloudflareは非公開IPの配信元を中継する構成を一般提供にした。使うにはCloudflare Oneの接続などの条件がある ── 多くのサイトに効く「配信元に直接つながる道」が残っていないかを確かめる13項目（2026年11月時点）」で書いた。
• WAFの守りが届かない所の確かめ方は、「CloudflareはWAFを突破できるか試す公開の催しを始め、同じ記事に「更新の代わりにならない」と書いた ── 事業者が自分で試す理由から、自社のWAFの守りが届かない所を確かめる13項目（2026年10月時点）」で書いた。
• ブラウザの外の通信を含む、信頼の経路の確かめ方は、「認証局eMudhraの中間証明書8枚の秘密鍵が漏れた。テスト用サイトによればブラウザは遮断済みで、残るのはブラウザの外の通信 ── 自社と担当サイトの信頼の経路を確かめる13項目（2026年10月時点）」で書いた。
• 証明書の更新の設定は、「Let's Encryptの証明書は2027年2月10日から標準で64日になる ── 更新の設定の「日数の決め打ち」とARI対応を確かめる13項目（2026年10月時点）」で書いた。

今回の記事の位置

これまでの記事は、Cloudflareの機能が何をするかを扱っていた。今回は、画面の操作が増えたときに、変える前と後をどう確かめるかを扱った。担当サイトの一覧を作る話は「PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）」にある。DNSの管理先と、TTLの秒数を、その一覧に2列足すと、DNSを変える日の準備が早くなる。