ドメインのサーバーアドレスを変更したのに、自宅では新しいサイトが開き、携帯電話では以前のサーバーにつながる状況を考えてみましょう。同じ名前を入力していても、二つの端末が異なるDNSキャッシュを経由すれば、一時的に結果が違うことがあります。ページを再取得するHTTPキャッシュと、接続先のアドレスを調べるDNSキャッシュでは、確認する対象そのものが異なります。
本稿では架空の図書館ホストwww.library.exampleを使い、名前解決とキャッシュの関係を見ていきます。名前や時刻表は説明用に作った例で、実在するサービスの応答を測定したものではありません。DNSがアドレスを知らせる過程、変更の反映が遅く見える理由、名前解決より後の失敗を分けて考えることが目的です。
1. DNSには名前ごとに複数の種類の答えがある
DNSはドメイン名に結び付いた情報を、種類別のレコードとして提供します。AはIPv4アドレス、AAAAはIPv6アドレスを表し、一つの名前に複数のアドレスがある場合もあります。CNAMEは別の名前を指す別名、MXはメールを受け取るサーバー、NSはそのゾーンの権威ネームサーバーを示します。そのため、同じ名前を問い合わせても、要求するレコードの種類が違えば答えも異なります。
CloudflareのDNSレコードの説明にあるように、CNAMEの値はIPアドレスではなく別の名前です。アドレスが必要なら、その名前の解決が続くことがあります。また、https://www.library.example/booksでDNSが扱うホスト名はwww.library.exampleです。/booksというパスやページ本文をDNSに登録するわけではありません。CNAMEを設定しても、ブラウザーのアドレス欄を変更するHTTPリダイレクトが自動的に発生することはありません。
2. 再帰リゾルバーが権威サーバーを見つける過程
端末の名前解決機能は通常、設定された再帰リゾルバーに答えを求めます。再帰リゾルバーは必要な情報がキャッシュにあればそれを使い、不足していれば他のDNSサーバーへ問い合わせ、最終的な答えかエラーを返します。DNS用語の標準RFC 9499は、このように代わりに解決する役割と、自分が担当するゾーンの情報を持つ権威サーバーを区別しています。サーバーがどの役割で応答しているかに応じて、答えの出所を読む必要があります。
キャッシュも中間の転送先もない単純な流れなら、リゾルバーはルートからトップレベルドメインのサーバーを案内され、そこから対象ゾーンの権威サーバーを案内されます。最後の権威サーバーから、目的のレコードや別名を得る仕組みです。一つのルートサーバーが全ウェブサイトのIPアドレスを保管しているわけではありません。実際には保存済みの委任情報から始めたり、別のリゾルバーに転送したりするため、アクセスのたびに必ずこの全手順を繰り返すとは限りません。
3. TTLはキャッシュの残り時間であり、世界共通の時計ではない
レコードのTTLは秒単位で伝えられるキャッシュ寿命の情報です。通常のキャッシュ応答では、保存していた時間に応じて残り時間が減ります。例えばリゾルバーが10時ちょうどにTTL 300秒のアドレスを保存したなら、同じ保存内容を10時2分に返すときの残りTTLは約180秒です。以下の時刻表は、再問い合わせ、事前更新、期限切れ応答の提供を行わないリゾルバーを一つ想定しています。
| 仮の時刻 | 権威サーバーのアドレス | このリゾルバーの処理 |
|---|---|---|
| 10:00 | 以前のアドレス | 以前のアドレスをTTL 300秒で保存 |
| 10:01 | 新しいアドレスに変更 | 保存内容にはまだ240秒が残る |
| 10:03 | 新しいアドレス | 残り120秒間は以前のアドレスを再利用できる |
| 10:05以降の最初の問い合わせ | 新しいアドレス | 期限切れの保存内容の代わりに再問い合わせし、新しいアドレスを得ると仮定 |
別のリゾルバーはこのレコードをもっと遅く保存したか、まだ一度も見ていないかもしれません。更新時点が異なるため、全世界の利用者が一斉に切り替わる瞬間をTTL一つで決めることはできません。キャッシュは期限前にデータを捨てることもあり、ウェブページを再読み込みしても共有リゾルバーの保存内容まで消えるわけではありません。TTLはDNS応答の再利用を理解する手掛かりであり、ウェブ接続や画面更新全体の制限時間ではありません。
4. TTLを下げる時点と「存在しない」という答えのキャッシュ
以前のアドレスをTTL 3,600秒で受け取ったキャッシュは、運営者が今TTLを60秒に下げても、その事実を即座には受け取りません。予定されたアドレス変更なら事前にTTLを調整し、以前の長い寿命で保存された応答が残る時間を考慮します。低いTTLは変更を頻繁に確認させられますが、問い合わせの負担と権威サーバーへの依存も増やします。全サービスに同じ短い数値を適用するより、変更計画と障害対応を一緒に検討します。
名前が存在しないというNXDOMAINや、名前はあるが要求した種類のレコードがないNODATAもキャッシュされる場合があります。ネガティブキャッシュの標準RFC 2308は、権威サーバーのSOAレコードのTTLとSOAのMINIMUM値のうち小さい方を、否定応答のキャッシュ寿命に使うと定義しています。そのため、なかったホストを追加した直後にも、以前の「存在しない」という答えが残ることがあります。新しいAレコードのTTLだけを見て、その答えの寿命も同じだと思うと原因を見落とします。
5. 同じ名前・種類・サーバーにそろえて確認する
確認記録には、問い合わせた正確な名前、AやAAAAなどの種類、問い合わせ先のDNSサーバー、時刻をまとめて書きます。digがインストールされた環境なら、dig example.com Aのように名前と種類を指定できます。実際の問題を調べるときは、example.comを自分が確認するホストに置き換えます。このコマンドは実行手順の例であり、本稿で実行したり応答時間を測定したりした記録ではありません。
応答の状態と、ANSWER内の名前・種類・値・TTLを一緒に見ます。同じリゾルバーに同じ問い合わせを繰り返してTTLが減るかを見ても、値が増えたからといって直ちにエラーとは判断しません。事前更新されたか、複数のキャッシュノードの別のノードが応答した可能性もあります。AとAAAAの結果を混ぜずに別々に記録すれば、どちらのアドレス系統に違いがあるか区別しやすくなります。
運営者なら、使用中の再帰リゾルバーの答えと管理ゾーンの権威サーバーの答えを、同じ名前・種類で比較できます。差があれば、キャッシュの残り時間、権威サーバー間のデータの一致、委任設定を順に調べます。一つの公開リゾルバーの答えを全利用者の状態に一般化しません。社内ネットワークの内部DNSやブラウザー独自のDNS設定は問い合わせ経路を変え得るので、比較するときは接続環境も記録します。
6. DNSのエラー、接続のエラー、例外を分けて読む
NXDOMAINは名前がないという応答で、NODATAは要求したレコードの種類がない場合です。一方、SERVFAILはサーバーが問い合わせを処理できなかったという失敗で、タイムアウトは決められた待ち時間内に答えを受け取れなかったという観察です。これらをすべて「ドメインが削除された」と解釈してはいけません。応答コードがあったのか、どのサーバーに尋ねたのかを先に残すことで、次に確認すべき対象を決められます。
TTLが過ぎても以前の答えが見えるからといって、常に規則違反とは限りません。RFC 8767のserve-stale方式は、権威サーバーから更新できない例外的な状況で期限切れ情報を利用し、可用性を高める方法を定義します。全リゾルバーが同じ設定でこれを使うという意味ではありません。単一のTTL値で変更の反映時間を断定するより、実際に使ったリゾルバーの動きを確認します。
最後に、アドレスが正常に解決できても、ウェブサイトへの接続成功が保証されるわけではありません。そのアドレスまでのネットワーク、TLS証明書、ウェブサーバー、アプリケーションは別の段階です。DNSの答えは期待どおりなのにページが開かないなら、次の接続段階へ調査範囲を移します。名前解決の答えとウェブ応答を別々に記録すれば、ページキャッシュを消したりDNS設定をむやみに変えたりする前に、失敗した箇所をより正確に絞り込めます。