dnschecker（dnschecker.org）の結果が期待と違うとき、見るべきなのは「どの地点で、どう違うか」という症状の形です。一部だけ古いのか、すべて違うのか、多くの地点で失敗しているのかによって、疑う原因と確かめる場所が変わります。この記事では、dnschecker で見える症状を5つに分け、それぞれの原因を起こりやすい順に並べて、手元の dig での確かめ方と直し方を説明します。
dnschecker は Web サービスで、名前に「コマンド」と付けて探されることがありますが、公式のコマンドラインツールは確認できません（2026年10月現在）。この記事では、dnschecker の画面で症状を掴み、原因の確認は手元の dig で行う流れをとります。
デバッグを始める前の準備
最初に、次の3つを書き出します。これが無いと、表示された値が正しいのかどうかを判断できません。
- 対象の名前と種別、設定したはずの値
- 変更した日時と、変更前のレコードに設定していた TTL
- そのドメインのネームサーバー（DNS 事業者）
次に、判断の基準となる「権威サーバーの今の答え」を手元で確かめます。
dig example.com NS +short
dig @ns1.example.net www.example.com A +norecurse +noall +answerns1.example.net の部分には、1行目で表示されたネームサーバー名を入れます。複数あれば1台ずつ聞きます。以下の各症状は、この答えと dnschecker の結果を見比べて読みます。
症状1：一部の地点だけ古い値を返す
1. キャッシュの残り時間が切れていない：最も多い原因です。変更前の TTL が 3600 秒なら、変更から最大で1時間ほど古い値を返すキャッシュサーバーが残ります。権威サーバーが新しい値を返していれば、待つことで解決します。特定の公開 DNS の残り時間は dig @8.8.8.8 www.example.com A +noall +answer の TTL の欄で分かります。
2. 権威サーバーの一部が古い：NS に並ぶ権威サーバーのうち1台だけ同期が遅れていると、そのサーバーに聞いたキャッシュサーバーだけが古い値を覚えます。各権威サーバーに SOA を聞き、シリアル番号がそろっているかを比べます。
dig @ns1.example.net example.com SOA +norecurse +short
dig @ns2.example.net example.com SOA +norecurse +short3. 地域によって答えを変える設定：位置情報で答えを変える DNS や CDN を使っている場合、地点ごとに値が違うのは正常な動作です。事業者のドキュメントで、どの地域にどの値を返す設定かを確かめます。
症状2：すべての地点で期待と違う値を返す
1. 編集したゾーンが使われていない：DNS 事業者の管理画面でレコードを変えても、レジストラに登録されたネームサーバーが別の事業者を指していれば反映されません。dnschecker の種別を NS にして、表示されるネームサーバーが編集した事業者のものかを確かめます。
2. ホスト名の入力ミス：管理画面の「ホスト名」の欄にドメイン名まで入れると、www.example.com.example.com のような名前ができてしまう事業者があります。dig @ns1.example.net www.example.com.example.com A +norecurse で、その誤った名前にレコードがあるかを確かめると原因が分かります。
3. CDN のプロキシを経由している：Cloudflare などでプロキシを有効にしたレコードは、設定した IP アドレスではなく CDN 側のアドレスが返ります。これは意図した動作で、元のサーバーのアドレスは管理画面で確かめます。
4. 保存されていない、または別のレコードが優先されている：同じ名前に CNAME と A を両方置くことは DNS の決まりでできません。事業者によってはどちらかが無視されたり、保存時にエラーになったりします。
症状3：多くの地点で失敗の印が出る
1. レコードが存在しない：作ったばかりのサブドメインを、作る前に一度引いていると、「存在しない」という答えがしばらくキャッシュされます（否定応答のキャッシュ）。保持される時間は SOA の最後の値と SOA 自体の TTL の小さい方です。dig ... SOA の出力で確かめ、その時間だけ待ちます。
2. DNSSEC の検証の失敗：DNS 事業者を移したのに親ゾーンの DS を古い鍵のまま残していると、検証を行うキャッシュサーバーは値を返さず SERVFAIL にします。検証を止める +cd を付けたときだけ値が返るなら、この原因です。
dig @8.8.8.8 www.example.com A
dig @8.8.8.8 www.example.com A +cd直すには、新しい事業者の鍵に合う DS をレジストラに登録し直すか、いったん DS を削除します。DS の削除や登録は反映に時間がかかるため、作業前に事業者の手順書を読んでください。
3. 権威サーバーが応答しない：NS に登録したサーバーがゾーンを持っていない、または停止していると、そのサーバーに当たった問い合わせが失敗します。各 NS に直接聞いて、応答が返らない、あるいは aa フラグの無い答えが返るサーバーが無いかを確かめます。
症状4：地点ごとに値がばらばらだが、どれも正しい
A レコードを複数登録している場合、答えに並ぶ順番は問い合わせごとに入れ替わることがあります。CDN を使うと、地域ごとに近い拠点のアドレスが返ります。どちらも不具合ではありません。返ってくる値が登録した値の範囲に収まっているかで判断します。
症状5：dnschecker ではすべて新しいのに、手元だけ古い
この場合、問題は手元の段階にあります。手元の OS が使っている DNS と、公開 DNS の答えを比べます。
dig www.example.com A +short # 手元の設定に従う
dig @1.1.1.1 www.example.com A +short # 公開 DNS に直接聞く公開 DNS が新しく、手元の設定に従う方が古ければ、OS やブラウザのキャッシュ、ルーター、社内の DNS が古い値を持っています。hosts ファイルに古い IP アドレスを書いたまま忘れている例も、サーバー移転の検証のあとによく見られます。
種別ごとに起きやすい見間違い
- MX：優先度の数字と送り先の名前が一緒に表示されます。送り先の名前は A や AAAA を持つ名前である必要があり、CNAME を指すのは避けます。
- TXT：長い値は複数の文字列に分けて表示されることがあります。SPF のレコードが同じ名前に2つあると、受け取る側でエラーとして扱われる原因になります。
- AAAA：サーバー移転で A だけを変え、AAAA を旧サーバーのまま残すと、IPv6 の利用者にだけ旧サイトが表示されたり、SSL 証明書の発行が失敗したりします。WordPress の移転後は A と AAAA の両方を確かめてください。
まとめ
- 最初に期待する値・変更日時・旧 TTL を書き出し、権威サーバーの答えを
+norecurseで確かめて基準にします。 - 一部だけ古いならキャッシュの残り時間か権威サーバーの同期、すべて違うならネームサーバーやホスト名の入力、多くが失敗ならレコードの有無・DNSSEC・権威サーバーの応答を疑います。
- 地点ごとに値が違っても、CDN や複数の A レコードなら正常な場合があります。
- dnschecker で新しいのに手元だけ古いときは、OS・ブラウザ・ルーター・hosts ファイルを確かめます。