SOAレコードを変更した、あるいはゾーンを編集したのに新しい値が見えないときは、「権威サーバーに変更が入っているか」「すべての権威サーバーにそろっているか」「キャッシュDNSが古い答えを持っているだけか」の3段階に分けて確かめると、待てば直る状態なのか、手を入れないと直らない状態なのかを判断できます。この記事では、反映待ちの間に見るべき値（シリアル番号と残りTTL）と、その読み方、待っても直らないときの原因の探し方を説明します。
SOAの各フィールドの意味や誤設定の直し方そのものは扱わず、「変えたはずなのに見えない」状態の確認に絞ります。
反映待ちの正体を3段階に分ける
DNSの変更が「反映されない」と感じるとき、実際には次のどこかで止まっています。
- プライマリ（変更を入れたサーバー）: 編集したゾーンが読み込まれていない
- セカンダリ（他の権威サーバー）: ゾーン転送が行われず、古いゾーンのまま応答している
- キャッシュDNS（利用者が問い合わせる側）: 以前の答えをTTLの間保持している
1と2は待っても直らないことがあり、3は時間が経てば解消します。そのため、反映待ちの間にまずやるべきことは「1と2に問題がないことを確かめ、3だけが残っている状態にする」ことです。ここが確認できれば、あとは残り時間を読んで待つだけになります。
ステップ1：プライマリに変更が入っているか
最初に、変更を入れたサーバーに直接問い合わせます。+norecurse を付けると、そのサーバーが自分のゾーンから答えた内容だけが返ります。
# 権威サーバーの一覧を確認
dig +short NS example.com
# 変更を入れたサーバーに直接問い合わせる
dig @ns1.example.com example.com SOA +norecurse +multiline確認するのはシリアル番号です。編集前より増えていれば、プライマリは新しいゾーンを読み込んでいます。増えていない場合は、ゾーンファイルの保存忘れ、シリアル番号の上げ忘れ、再読み込みの失敗が考えられます。BINDなら named-checkzone で構文を確かめてから rndc reload example.com を実行し、ログに読み込みエラーが出ていないかを見ます。
マネージドDNSでは事情が異なります。たとえば Amazon Route 53 は、SOAのシリアル番号を変更のたびに増やす仕組みになっていないため、レコードを変えてもシリアル番号が同じままなのが通常の動きです（2026年10月現在）。Route 53 で変更が適用されたかどうかは、変更リクエストの状態で確かめます。
# 変更リクエストの状態を確認（Status が INSYNC なら全権威サーバーに適用済み）
aws route53 get-change --id /change/your-change-idCloudflare など、シリアル番号を自動で更新するサービスもあります。どちらの方式かはサービスの資料で確かめ、シリアル番号だけで判断しないようにします。
ステップ2：すべての権威サーバーにそろっているか
プライマリが新しくても、セカンダリが古いままだと、利用者によって見える値が変わります。すべての権威サーバーのシリアル番号を並べて比べます。
dig example.com +nssearch各サーバーのSOAが1行ずつ表示されます。シリアル番号が1台だけ古い場合は、そのセカンダリへのゾーン転送が止まっています。自前のBINDでセカンダリを運用しているなら、セカンダリ側で次のように状態を確かめます。
# セカンダリでゾーンの状態（シリアル、次回の更新確認予定など）を表示
sudo rndc zonestatus example.com
# 次の定期確認を待たずに、プライマリのSOAを今すぐ確認させる
sudo rndc refresh example.comセカンダリは通常、プライマリからのNOTIFYを受けて更新を確認し、NOTIFYが届かなかった場合はSOAのREFRESHの間隔で確認します。REFRESHが数時間に設定されていると、NOTIFYが失敗したときにはその時間だけ古いゾーンのまま応答することになります。rndc refresh で更新されない場合は、プライマリとセカンダリ双方のログで、NOTIFYの拒否やゾーン転送の拒否（allow-transfer や also-notify の設定漏れ、ファイアウォールでTCP 53番が閉じているなど）が出ていないかを確認します。
ステップ3：そもそもそのサーバーが使われているか
権威サーバーがすべて新しい値を返しているのに反映されない場合は、ドメインのレジストリに登録されたNSが、変更を入れたDNSサービスを指しているかを確かめます。DNSサービスを乗り換えた直後や、レジストラの管理画面でネームサーバーを変更し忘れた場合に起こります。
# ルートから順にたどり、実際に参照されている権威サーバーを確認
dig +trace example.com SOA出力の最後の段で答えているサーバーが、変更を入れたサービスのものかを見ます。違うサービスが答えている場合、いくら待っても反映されません。レジストラ側のネームサーバー設定を直す必要があります。
ステップ4：キャッシュの残り時間を読む
ここまで問題がなければ、残っているのはキャッシュだけです。公開DNSに問い合わせると、答えのTTL欄に「あと何秒キャッシュされるか」が表示されます。
dig @8.8.8.8 example.com SOA +noall +answer
dig @1.1.1.1 example.com SOA +noall +answer何度か実行してTTLの数字が減っていけば、それはキャッシュからの答えです。数字が0になった後の問い合わせで新しい値が返ります。待ち時間の上限は、変更前のSOAレコードのTTLです。変更の直前にTTLを短くしても、すでにキャッシュされている答えは元のTTLの間残ります。
Google Public DNS や Cloudflare の 1.1.1.1 には、特定の名前のキャッシュを消してもらうためのページが用意されています（2026年10月現在）。ただし、消せるのはそのサービスのキャッシュだけで、利用者のプロバイダのDNSやOS・ブラウザのキャッシュには効きません。
追加したレコードが「存在しない」と返る場合
SOAの変更とあわせて新しいレコードを追加し、それが見えない場合は、ネガティブキャッシュを疑います。追加前に誰かがその名前を問い合わせていると、「存在しない」という答えがキャッシュされます。その保持時間は、SOAレコードのTTLとSOAの最後のフィールド（MINIMUM）のうち短い方です。
dig @8.8.8.8 new.example.com A答えが空で、AUTHORITYセクションにSOAが表示されていれば、そのSOAの横のTTLがネガティブキャッシュの残り時間です。
待っている間にやらないこと
- 値を何度も変え直さない: 途中で値を変えると、キャッシュに残る答えが複数の版に分かれ、どの変更が反映されたのか判断できなくなります
- ローカルの結果だけで判断しない: 自分のPCのキャッシュが古いだけのこともあります。OSのDNSキャッシュを消すか、公開DNSや権威サーバーに直接問い合わせた結果で判断します
- TTLを極端に短くしたまま放置しない: 反映待ちを短くする目的で下げたTTLは、作業が終わったら元に戻します。短すぎるTTLは権威サーバーへの問い合わせを増やします
WordPressのサーバー移転と重なるとき
サーバー移転の作業中にSOAやゾーンを変更している場合、DNSの反映を待たずに新しいサーバーの動作を確かめておくと、反映後のトラブルを減らせます。curl の --resolve を使うと、名前解決の結果を一時的に指定して新しいサーバーに接続できます。
curl -sI https://example.com/ --resolve example.com:443:203.0.113.10応答コードと証明書のエラーが出ないことを確かめます。反映待ちの間は、旧サーバーと新サーバーの両方にアクセスが来る可能性があるため、旧サーバー側で投稿やコメントを受け付けたままにしないよう、更新作業を止めておくか、移転後に差分を取り込む手順を用意しておきます。作業前のバックアップは両方のサーバーで取っておきます。
まとめ
- 「反映されない」はプライマリ・セカンダリ・キャッシュDNSの3段階に分けて確認する
- プライマリには
+norecurseで直接問い合わせ、シリアル番号が増えているかを見る。Route 53 のようにシリアル番号を増やさないサービスもある dig +nssearchで全権威サーバーのシリアル番号を比べ、古いセカンダリがあればrndc refreshとログで原因を探すdig +traceで、変更を入れたDNSサービスが実際に参照されているかを確かめる- キャッシュはTTL欄の残り秒数で待ち時間を読む。追加したレコードが見えないときはネガティブキャッシュも疑う