新しいサブドメインを作成します。管理画面にはレコードが表示され、同僚はサイトにアクセスできるのに、あなたのコンピューターではまだ NXDOMAIN と表示されます。変更は失敗したのでしょうか。必ずしもそうではありません。リゾルバーは、ある名前が以前は存在しなかったことを記憶している場合もあります。この保存された否定応答は、それ自体が一つの独立した状態です。
2026年十月21日に更新された Cloudflare の DNS トラブルシューティングガイドは、まさにこのケースを説明しています。これは現在の技術的な解説であり、新しい DNS 製品の発表ではありません。この区別が重要なのは、日常的な「キャッシュ」という言葉の下に、DNS の応答、ブラウザーのコンテンツ、キャッシュされたウェブファイルという、まったく異なる複数の保存先が埋もれてしまうからです。
以前の「存在しない」がまだ保存されている可能性
再帰リゾルバーは、あなたに代わって名前を調べます。以前に否定応答を受け取っていた場合、その応答を一定時間再利用することがあります。その間に権威ネームサーバーでレコードが作成されても、リゾルバーが同じ瞬間にそれを知るとは限りません。
作成したばかりの A レコードの新しい TTL は、この既存の否定状態をさかのぼって短くすることはありません。ネガティブキャッシュには、ゾーンの SOA 情報が関わります。RFC2308 では、開始値を SOA の TTL と SOA.MINIMUM のうち小さいほうとしています。保存された応答に実際に残っている時間は、さらに別のものです。
私たち自身の計算例では、架空の数値のみを使います。否定エントリーが当初 300 秒間有効だとします。120 秒後に、実際の DNS レコードが作成されます。するとリゾルバーには、古い応答がまだ 180 秒残っている可能性があります。これは時間の関係を示すためのものであり、Cloudflare やあなたのドメインで計測された時間ではありません。
二つの読み取り専用クエリで、情報源とキャッシュを切り分ける
一つ目の問いは、担当する権威ネームサーバーが何と答えるかです。二つ目は、あなたのデバイスが実際に使っている再帰リゾルバーが何と答えるかです。応答が異なれば、障害の範囲を絞り込めます。ただし、それだけでネガティブキャッシュが自動的に証明されるわけではありません。入力ミスや誤った委任も除外する必要があります。
dig @YOUR-AUTHORITATIVE-NAMESERVER neu.example.com A
dig @YOUR-RECURSIVE-RESOLVER neu.example.com A
dig @YOUR-RECURSIVE-RESOLVER neu.example.com A +noall +authorityプレースホルダーは、実際に特定したサーバーに置き換えてください。コマンドは読み取り専用のテンプレートであり、ここでは実行していません。応答コード、名前、レコードタイプ、そして存在する場合は SOA の詳細を、あわせて確認してください。似た綴りのホストに対する応答は、比較対象として適切ではありません。
時刻と使用したリゾルバーも記録しておきましょう。そうしないと、気づかないうちに異なる経路を比較してしまう可能性があります。ローカルの DNS キャッシュを消去しても、上流のリゾルバーに保存された応答が自動的に削除されるわけではありません。だからこそ、ブラウザーを再起動しても、観察している状態には効かないことがあるのです。
DNS と CDN は異なる問いに答える
DNS は名前の解決を助けます。一方、CDN キャッシュは特定の HTTP コンテンツを用意しておくものです。キャッシュされた画像やスタイルシートを削除しても、以前は不明だった名前が今は存在することを DNS リゾルバーに伝えることにはなりません。その対処は、問題のある層とただ合っていないのです。
2026年十月12日に最終更新された Cloudflare の Cache 入門ガイドでも、プロキシ経由と DNS のみの違いが説明されています。DNS のみのホストのコンテンツは、DNS がそこで管理されているというだけでは Cloudflare のキャッシュを通りません。したがって、DNS レコードが存在することは、コンテンツが実際にキャッシュされている証拠にはなりません。
DomainStudio から実際の応答まで
「 KENJTEC DomainStudio ai」では、タイプ、ターゲット、TTL を指定してご自身の DNS レコードを管理できます。実装されている経路では、ゾーン管理に Cloudflare を使用しています。変更後も、名前解決は実際の DNS 応答で判断してください。「保存された」と「すでにすべてのリゾルバーで見えている」は別のことです。
したがって、待ち時間を一律の成功の約束で置き換えることはできません。まず綴り、担当するネームサーバー、権威応答を確認してください。そのうえで初めて、残りのキャッシュ時間が有用な説明になります。こうして「DNS はとにかく時間がかかる」が、すべての観察が正しい技術的な層に属する、追跡可能な診断に変わります。
出典と情報の時点
調査および記録は2026年十月25日時点のものです。 DNS の一般的な問題 · Cache を使い始める · RFC2308 — DNS クエリのネガティブキャッシュ。
