コンテンツにスキップ

名前解決とキャッシュ

同じ名前を続けて問い合わせると、フルリゾルバーは2回目以降、権威 DNS サーバーへ問い合わせずに応答できることがあります。このページでは、その流れを追いながら DNS キャッシュの働きを確認します。

1回目(ルートから委任をたどる)

Section titled “1回目(ルートから委任をたどる)”

フルリゾルバーが www.example.com の A を初めて聞かれたとき、キャッシュにはまだ何も入っていないので、答えもありません。聞かれた答えがキャッシュにない状態をキャッシュミス(cache miss)と呼びます。A は IPv4 アドレスを表す型で、本書で使う RRで扱います。

フルリゾルバーは、あらかじめ持っているルート DNS サーバーのアドレスから始め、委任を1段ずつたどります。最も単純な場合、問い合わせは次の3回です。

  1. ルート DNS サーバーへ問い合わせる ➡ com の権威 DNS サーバーを示す委任応答が返る
  2. com の権威 DNS サーバーへ問い合わせる ➡ example.com の権威 DNS サーバーを示す委任応答が返る
  3. example.com の権威 DNS サーバーへ問い合わせる ➡ www.example.com の A が返る

途中の2回で返るのは委任応答、つまり次に聞く先の案内です。ルート DNS サーバーも com の権威 DNS サーバーも、最終的な答えは持っていません。答えを持っているのは、その名前を含むゾーンの権威 DNS サーバーだけです。

この間、スタブリゾルバーはフルリゾルバーから答えが返ってくるのを待っています。スタブリゾルバーが問い合わせるのは最初の1回だけで、その後の3回の問い合わせはフルリゾルバーが行います。

フルリゾルバーは、得られた情報を捨てずに保存します。保存されるのは最終的な答えだけではありません。途中で得た「com の権威 DNS サーバーはどこか」「example.com の権威 DNS サーバーはどこか」も保存されます。

そのため、次に mail.example.com を聞かれたときは、ルートからやり直さずに example.com の権威 DNS サーバーへ直接問い合わせられます。キャッシュが効くのは、同じ名前を2回引いたときだけではありません。

なお、フルリゾルバーが持つキャッシュは1種類だけではありません。Unbound が何をどこに保存しているかは第4章で説明します。

同じ www.example.com をもう一度聞かれたとき、フルリゾルバーは保存した答えをそのまま返します。この状態をキャッシュヒット(cache hit)と呼びます。この時、権威 DNS サーバーへは問い合わせず、キャッシュにある答えを返します。

1回目と2回目で違うのは、次の2点です。

  • 応答までの時間: 外部への往復がなくなるぶん短くなります
  • 返る TTL: 答えに付いている TTL は、保存してからの経過時間だけ減った値になります1。TTL は次の節で説明します

答えの内容そのものは変わりません。

図1.3 1回目のキャッシュミスと2回目のキャッシュヒットの比較
図1.3 1回目のキャッシュミスと2回目のキャッシュヒットの比較

TTL(Time To Live)は、そのデータを持つ権威 DNS サーバーが付けた値です。フルリゾルバーが決めるものでも、問い合わせた側が指定するものでもありません。

TTL は、その情報をキャッシュしてよい時間の最大値です。短く扱うことは許されており、フルリゾルバーが上限を設けて短く丸めることもあります2。逆に、権威 DNS サーバーが付けた TTL を超えて使い続けることは、通常は想定されていません。

TTL を過ぎると、フルリゾルバーは原則としてもう一度権威 DNS サーバーへ問い合わせます。ただし、問い合わせ先に届かないなどの理由で更新できない場合に、期限切れの情報を返す仕組みもあります3。Unbound がこれをどう扱うかは第4章で説明します。

「名前がない」と「そのレコードがない」

Section titled “「名前がない」と「そのレコードがない」”

「ない」という答えにも2種類あります4。この区別は、第5章で Unbound に名前を答えさせるときに効いてきます。

  • NXDOMAIN: その名前自体が存在しません。example.com ゾーンに nosuchhost.example.com という名前がなければ、この名前への問い合わせは型を問わず NXDOMAIN になります
  • NODATA: 名前は存在しますが、問い合わせた型のデータがありません。www.example.com に A はあるが AAAA はない場合がこれにあたります

この2つは DNS の応答としても別物です。応答のどこを見て区別するかは第3章で扱います。

この2種類の結果も、フルリゾルバーはキャッシュします。通常の答えの保存(positive cache)に対して、求めたデータが得られなかったという結果を保存しておくことをネガティブキャッシュ(negative cache)と呼びます5。ネガティブキャッシュがあるため、存在しない名前を何度引いても、その都度権威 DNS サーバーへ問い合わせ直すことにはなりません。

ネガティブキャッシュが保存するものは2つに分かれます。1つは、権威 DNS サーバーが「ない」と答えた NXDOMAIN と NODATA です。保存してよい時間は、そのゾーンの SOA をもとに権威 DNS サーバーが決めます6。もう1つは、権威 DNS サーバーから答えそのものを得られなかったという結果です7。こちらは保存される時間の決まり方が違うので、本書では「解決失敗のキャッシュ」と呼んで区別します。どちらも第4章で説明します。

dig で同じ名前を2回引き、TTL が減ることを確認します。見るのは ANSWER セクションだけです。出力全体の読み方は第3章で扱います。

ターミナルウィンドウ
$ dig example.com A +noall +answer
example.com. 294 IN A 172.66.147.243
example.com. 294 IN A 104.20.23.154

3秒後に、同じ問い合わせをもう一度送ります。

ターミナルウィンドウ
$ dig example.com A +noall +answer
example.com. 291 IN A 104.20.23.154
example.com. 291 IN A 172.66.147.243

返ってきたアドレスは同じで、TTL だけが294から291へ、経過した3秒ぶん減っています。TTL が減っているのは、この答えがキャッシュから返っているからです。

行の順序が1回目と2回目で入れ替わっている点は、ここでは気にしません。この出力は OS に設定された問い合わせ先へ引いた結果であり8、アドレスも TTL の絶対値も環境と時刻によって変わります。確認したいのは、2回目の TTL が減っていることだけです。

  1. RFC 1035 の 6.1.3. Time ↩

  2. RFC 2181 の 8. Time to Live (TTL) ↩

  3. RFC 8767 の 4. Standards Action ↩

  4. RFC 9499 の 3. DNS Response Codes ↩

  5. RFC 2308 の 1 - Terminology と 5 - Caching Negative Answers ↩

  6. RFC 2308 の 4 - SOA Minimum Field ↩

  7. RFC 2308 の 1 - Terminology と RFC 9520 の 1. Introduction ↩

  8. 2026-10-03 採取。WSL2 上の Ubuntu 22.04 ↩