dnschecker を使った DNS レコードのトレース手順｜間違った答えがどの段階から来ているかを外からたどる

DNS の答えがおかしいとき、dnschecker（dnschecker.org）で世界各地の結果を見るだけでは「どこが間違っているか」までは分かりません。名前解決は「親ゾーンの委任 → 権威サーバー → 各地のキャッシュサーバー → 手元」という段階を経て届くので、dnschecker で見える一番外側から順に内側へさかのぼり、答えが食い違い始める段階を見つけるのがトレースの考え方です。この記事では、dnschecker と手元の dig を組み合わせて、その段階を突き止める手順を説明します。

コマンドでルートから委任を1段ずつたどる方法（dig の +trace など）は手順5で補助的に使いますが、この記事の中心は「Web ツールで外から見た結果を出発点にする」流れです。

名前解決の段階と、dnschecker で見える範囲

答えが届くまでの段階を整理しておきます。

1. 親ゾーンの委任：.com や .jp などのゾーンに、「example.com の権威サーバーはこれ」という NS（DNSSEC を使うなら DS も）が登録されています。レジストラの管理画面で設定するネームサーバーがこれです。
2. 権威サーバー：DNS 事業者のサーバーで、あなたが登録したレコードの値を返します。
3. キャッシュサーバー：プロバイダーや公開 DNS のサーバーで、権威サーバーの答えを TTL の間だけ保存して使い回します。
4. 手元：OS やブラウザのキャッシュ、社内 DNS などです。

dnschecker の一覧に並ぶのは、3 の各地のキャッシュサーバーの答えです。1 と 2 は直接は見えないので、結果から推測するか、別の手段で確かめます。どの段階で答えが変わったのかを意識すると、見当違いの場所を直す無駄が減ります。

手順0：期待する値を書き出す

トレースを始める前に、「本来どう返るべきか」をメモします。

• 対象の名前と種別（例：www.example.com の A）
• 新しい値と、変更前の値
• 変更した日時と、変更前のレコードに設定していた TTL
• ネームサーバーを変えた場合は、新旧のネームサーバー名

これが無いと、表示された値が正しいのか古いのか判断できません。サーバー移転の作業メモや、DNS 事業者の管理画面から書き写しておきます。

手順1：dnschecker で各地の結果を分類する

dnschecker のトップページにある DNS の伝播を確認する機能で、対象の名前と種別を入れて検索します。画面の構成や表示の印はサイト側の更新で変わることがあるため、凡例も合わせて見てください（2026年10月現在）。

結果は次の4つのどれかに分けられます。

• すべて古い値：権威サーバーの値がまだ変わっていない可能性が高い状態です。手順4へ進みます。
• 新旧が混在：キャッシュの入れ替わりの途中である可能性が高い状態です。手順4で権威サーバーが新しい値を返していれば、変更前の TTL の分だけ待ちます。
• 多くの地点で失敗：委任か DNSSEC の問題を疑います。手順3と手順6へ進みます。
• すべて新しい値なのに手元では古い：手元の段階の問題です。OS やブラウザのキャッシュ、社内 DNS を確認します。

手順2：CNAME をたどる

対象の名前に CNAME を設定している場合、表示される IP アドレスは CNAME の置き換え先の名前のものです。種別を CNAME に切り替えて検索し、各地でどの名前に置き換えられているかを見ます。

置き換え先が CDN やホスティング事業者の名前なら、最終的な IP アドレスはその事業者のゾーンで決まります。置き換え先の名前を改めて A で検索し、その名前の段階で食い違いがあるかを調べます。CNAME が自分の設定どおりなのに IP がおかしいなら、直す場所は自分の DNS ではなく事業者側の設定（サイトの紐付けやプランの設定など）です。

手順3：NS の見え方を確かめる

種別を NS にして、ドメイン名（www を付けないもの）で検索します。表示されるのは、各地のキャッシュサーバーが覚えている権威サーバーの一覧です。

• 手順0でメモした新しいネームサーバーが並ぶ：委任は切り替わっています。
• 新旧のネームサーバーが混在：委任の変更が広がっている途中です。親ゾーンの NS の TTL は1日〜2日程度に設定されていることが多く、A レコードの変更より時間がかかるのが普通です。この間は旧事業者のゾーンを消さずに残しておきます。
• 想定外のネームサーバーが並ぶ：レジストラの設定を見直します。レジストラと DNS 事業者が別の会社の場合、DNS 事業者側でゾーンを作っただけでは委任は変わりません。

手順4：権威サーバーに直接聞く

dnschecker の結果はキャッシュサーバーの答えなので、権威サーバーそのものの値は手元から確かめます。手順3で分かったネームサーバーを1台ずつ指定し、再帰を求めない問い合わせをします。

# 権威サーバーごとに値を聞く（ns1.example.net は例）
dig @ns1.example.net www.example.com A +norecurse +noall +answer
dig @ns2.example.net www.example.com A +norecurse +noall +answer

ここで判断が分かれます。

• 権威サーバーが古い値を返す：変更が保存されていないか、別のゾーン（旧事業者の側など）を編集しています。待っても直らないので、管理画面を見直します。
• 権威サーバー同士で値が違う：ゾーンの同期が遅れているか止まっています。SOA のシリアル番号を並べて比べ、事業者に問い合わせます。
• 権威サーバーが新しい値を返す：権威の段階は正しいので、残りはキャッシュの入れ替わりの問題です。

コマンドを使えない環境では、オンラインの dig 相当のツールで権威サーバーを指定して問い合わせる方法もあります。

手順5：親ゾーンの委任までさかのぼる

手順3で NS の見え方がおかしいときや、多くの地点で失敗するときは、親ゾーンに登録されている委任を確かめます。

# ルートから委任を順にたどる
dig +trace www.example.com

# 親ゾーン（.com の場合）の権威サーバーに、委任の情報を直接聞く
dig @a.gtld-servers.net example.com NS +norecurse

2つ目の問い合わせでは、答えは AUTHORITY セクションに委任の案内として表示されます。ここに並ぶネームサーバーが、レジストラで設定した値です。手順4で確認した権威サーバーと一致しているか、そのネームサーバーが実際にゾーンを持っていて応答するかを確かめます。親ゾーンに登録された NS のうち1台でも応答しないと、一部の利用者だけ失敗する原因になります。.jp など他のドメインの場合は、dig jp NS などで親ゾーンの権威サーバーを調べてから同じように問い合わせます。

手順6：DNSSEC の検証の失敗を確かめる

多くの地点で失敗しているのに、手順4で権威サーバーは値を返す場合は、DNSSEC の検証の失敗を疑います。検証を行うキャッシュサーバーは、署名が合わないと値を返さず SERVFAIL にします。DNS 事業者を移転したのに、親ゾーンの DS を旧事業者の鍵のまま残している場合などに起こります。

# 検証ありとなしで比べる
dig @8.8.8.8 www.example.com A
dig @8.8.8.8 www.example.com A +cd

1つ目が SERVFAIL で2つ目に値が返るなら、検証の失敗です。dnschecker には DS や DNSKEY を確認するためのツールが用意されていることがあり、親ゾーンの DS と権威サーバーの鍵を見比べる手がかりになります。署名の連鎖を図で確かめたい場合は DNSViz のような専用のツールが向いています。

結果の組み合わせから原因を絞る

使うときの注意

dnschecker は公開の Web サービスです。社内専用のホスト名や、公開前のサブドメインを入力すると、その名前を外部に知らせることになるので避けてください。また、結果は検索したその瞬間の答えです。時間をおいて同じ検索をすると、キャッシュの入れ替わりで結果が変わることがあります。短時間に何度も検索すると制限がかかる場合もあるので、確認は必要な名前と種別に絞ります。

まとめ

• トレースは、dnschecker で見える各地のキャッシュの答えから、権威サーバー、親ゾーンの委任へと内側にさかのぼり、答えが食い違い始める段階を見つける作業です。
• 始める前に、期待する値・変更前の値・TTL・ネームサーバーを書き出しておきます。
• CNAME がある名前は置き換え先の段階まで追い、NS の見え方で委任の切り替わりを確かめます。
• 権威サーバーの値は dig の +norecurse で、親ゾーンの委任は +trace や親ゾーンのサーバーへの問い合わせで確かめます。
• 多くの地点で失敗するときは、+cd との比較で DNSSEC の検証の失敗かどうかを切り分けます。

• DNSの伝播が遅いときの確認方法
• NSレコードの役割と設定方法