キャッシュなしの名前解決

サーバのIPアドレスを変更したのに、一部の端末だけ古いサーバへつながる。その原因は、DNSの設定を更新した場所と、利用者が実際に参照する情報の場所が違うことにあります。名前を問い合わせる順序と、キャッシュの残り時間を追えば、変更後の挙動を説明できます。

この記事で理解すること

FQDN、ドメイン、ゾーンとDNSサーバの役割を区別する。
レコードの種類から、何をどの順序で調べるかを判断する。
TTLと負のキャッシュを使って、変更がすぐ届かない理由を説明する。

架空の会社がapp.example.comで業務サイトを公開し、example.com宛てにメールを受け取る事例を使います。example.comと文書用IPアドレスは説明のための値です。実際のDNS設定の観測結果や本番ログではありません。

DNS・FQDN・ゾーン：名前と管理範囲を分ける

DNSは、階層的な名前に対応するレコードを分散して管理・問い合わせする仕組みです。WebサイトのIPだけでなく、メールの配送先や権威サーバなども扱います。FQDNは名前空間のルートまで含めた完全な名前で、厳密な表記ではapp.example.com.のように末尾のドットがルートを示します。

ドメインはある名前を根に持つ名前の部分木です。ゾーンは、ある権威DNSサーバが管理するデータの範囲です。子ドメインの管理を別のサーバへ委任すると、親のゾーンと子のゾーンに分かれます。「example.com以下だから必ず同じ担当サーバ」という理解は成り立ちません。

情報・役割	意味
ラベル	app、example、comのような名前の構成単位
権威DNSサーバ	担当ゾーンの正式なレコードを応答する
再帰リゾルバ	利用者の代わりに必要な問い合わせを進め、結果をキャッシュする
NSレコード	ゾーンの権威サーバを示す
SOAレコード	ゾーン管理情報や負のキャッシュに関わる値を持つ

端末の設定で指定するDNSサーバは、通常は再帰リゾルバです。権威DNSへ直接全ての名前を問い合わせることとは異なります。同じ製品が両方の機能を提供できても、役割は分けて理解します。

名前解決の順序：キャッシュがない場合から考える

ブラウザは接続先名のIPアドレスを得る必要があります。ここでは端末側のキャッシュ等に使える情報がなく、再帰リゾルバにも対象名の使えるキャッシュがない場合を考えます。リゾルバはルート、com、example.comの権威サーバを順にたどり、最終的な回答を得ます。

キャッシュなしの名前解決

ルートからcomへの問い合わせは「ルート等」にまとめた概略図です。委任の情報を利用して担当サーバへ進みます。

再帰問い合わせは最終的な結果を求める問い合わせです。一方、リゾルバが権威サーバをたどるときは、回答や次に尋ねるサーバの情報を受け取って進みます。ルートDNSが全サイトのIPアドレス一覧を持っているわけではありません。

委任先のDNSサーバ自身の名前を解決するために、親側にグルーレコードが必要になる場合があります。委任とアドレス取得が循環しないようにする情報です。実際には途中のNSやアドレスもキャッシュされるため、毎回ルートから全段階を問い合わせるわけではありません。

A・AAAA・CNAME・MX：レコードの意味を読む

種類	この例の値	用途
A	app.example.com → 203.0.113.80	名前にIPv4アドレスを対応付ける
AAAA	app.example.com → 2001:db8::80	名前にIPv6アドレスを対応付ける
CNAME	portal.example.com → app.example.com	別名を正式な名前へ対応付ける
MX	example.com → 優先度10 mail.example.com	ドメイン宛てメールの配送先名を示す

CNAMEを受け取ったリゾルバは、必要に応じて参照先名のAやAAAAを調べます。CNAMEはIPアドレスを直接入れるレコードではありません。通常のDNS規則では、同じ所有者名にCNAMEと他種のデータを共存させません。事業者が提供する別名風の独自機能は、通常のCNAMEと区別します。

MXの値は配送先サーバの名前です。その名前のA・AAAAなどを調べて接続先を得ます。優先度の数値は小さい方を優先します。同じ優先度の選び方や配送失敗時の試行はメール側の処理に関わり、DNSだけがメールの配送を実行するわけではありません。

AとAAAAは別のレコードです。Aを変更しても、AAAAが古い接続先を指したままならIPv6で旧サーバへ接続する利用者が残る可能性があります。接続先の選択はクライアントの方式にもよるため、IPv4の観測だけで全利用者の経路を断定しません。

キャッシュとTTL：変更時刻ではなく取得時刻を追う

TTLはDNSレコードをキャッシュで利用できる時間を秒単位で表します。リゾルバがレコードを取得した後、利用できる残り時間は減っていきます。権威DNSで値を更新しても、既に取得されたレコードのキャッシュを直接書き換えることにはなりません。

10時20分にAを変更した例

目的と処理する場所を対応付けて読みます。

この図は通常のTTLに従う単純化した例です。10時20分に権威DNSのTTLを300へ短くしても、10時に受け取った3600秒の期限は通常そのまま残ります。切替前にTTLを短くし、以前の長いTTLが満了する時間を確保してから接続先を変更します。

ブラウザ、OS、アプリ、再帰リゾルバなどにキャッシュが存在し、上限・下限や障害時に古い情報を返す方式もあります。TTLを短くすれば必ず全利用者がその秒数以内に切り替わる、と保証することはできません。旧サーバを一定期間維持し、実際のアクセスと名前解決結果を確認します。

存在しない回答も残る：負のキャッシュ

NXDOMAINは問い合わせた名前が存在しないという回答です。名前は存在していても、問い合わせた種類のレコードがない場合の回答とは区別します。これらの否定的な結果もキャッシュされる場合があり、負のキャッシュと呼びます。

まだ作成していないnew.example.comへアクセスした後でレコードを追加しても、キャッシュされた不存在回答の期限が残っていれば、すぐには新しいレコードを取得しないことがあります。負のキャッシュの時間はSOAのTTLやMINIMUM値などの規則とリゾルバの扱いを確認します。AレコードのTTLだけ見ても十分ではありません。

DNSラウンドロビンの効果と限界

同じ名前に複数のA・AAAAを登録し、応答の順序や利用者の選択によって接続先を分散させる方式をDNSラウンドロビンと呼びます。単純なDNS応答はサーバのCPU利用率や業務処理の負荷を見て、要求ごとに最適な相手を選ぶ仕組みではありません。

同じリゾルバを使う利用者が同じキャッシュを参照したり、クライアントが一定の順序で選んだりするため、台数に比例した均等分散を保証しません。故障サーバのレコードを削除しても古いキャッシュが残る場合があります。DNS更新、監視、クライアントの再試行、ロードバランサの役割を区別します。

名前解決と接続の障害を分ける

同じFQDN・レコード種類を使い、端末が実際に参照するリゾルバの回答と、権威DNSの回答を比較します。名前解決が成功しても、返されたIPへの経路・ポート・TLS・アプリ処理で失敗することがあります。逆にIPを直接指定して開くと、HTTPSの名前検証や仮想ホストが違うため、正常な比較にならない場合があります。

text

架空の調査記録
権威DNS：app.example.com A 203.0.113.81
社内リゾルバ：A 203.0.113.80 TTL 1200
観測：社内では旧IPを受け取る
解釈：使える旧キャッシュが残る可能性
次の確認：取得時刻、TTL、端末側キャッシュ

演習1：サーバの役割

条件：端末は社内DNSへ問い合わせ、社内DNSが権威サーバをたどって回答する。

問い：社内DNSの役割は何か。

解答例：再帰リゾルバ。端末の代わりに問い合わせを進め、回答を返す。

根拠と誤答の確認：担当ゾーンの正式なデータを持つ権威サーバとは役割が異なります。

演習2：MXの次の処理

条件：example.comのMXは優先度10 mail.example.com。

問い：接続先IPを得るために何を調べるか。

解答例：mail.example.comのA・AAAAなどを調べる。

根拠と誤答の確認：MXの値自体をIPアドレスとして使うわけではありません。

演習3：TTLの残り

条件：10時00分にTTL3600で旧IPを取得。10時20分に権威側を更新。通常のTTLに従う。

問い：旧キャッシュは何秒残るか。

解答例：2400秒。取得から1200秒経過し、3600−1200が残る。

根拠と誤答の確認：変更時刻からさらに3600秒待つという計算ではありません。

演習4：TTL短縮の順序

条件：切替直前にTTLを3600から300へ変更した。古い回答を10分前に取得したリゾルバがある。

問い：そのリゾルバが必ず5分以内に切り替わるか。

解答例：保証できない。既に取得した3600秒の旧TTLが残るため。

根拠と誤答の確認：短いTTLを前もって取得させ、以前のTTLが満了する期間を確保します。

演習5：新規名が引けない

条件：不存在回答をキャッシュした後、その名前のAを追加した。

問い：直後も失敗する理由は何か。

解答例：負のキャッシュの期限が残り、権威DNSへ再問い合わせしない場合があるため。

根拠と誤答の確認：AのTTLだけを短くしても、既存の負のキャッシュは直接消えません。

演習6：故障サーバの削除

条件：Aを二つ登録して分散。故障した一つを権威DNSから削除した。

問い：直ちに全接続が正常になるといえるか。

解答例：いえない。古い回答のキャッシュやクライアントの選択が残るため。

根拠と誤答の確認：レコード削除と全利用者への反映は同時ではありません。

参照資料とこの記事の範囲

事例・図・演習は教材用に独自に作成しました。技術仕様とIPAの公開資料を照合し、特定年度の問題本文を前提にせず学べる構成にしています。

DNSと名前解決｜FQDN・レコード・キャッシュ・TTLを一つの流れで理解する