## page was copied from DNS/リゾルバー/キャッシュ
## page was renamed from DNS/実装/キャッシュ
<<Navigation(children)>>
----
== DNS/リゾルバー/キャッシュ ==
<<TableOfContents()>>

問い合わせで得られた情報をなんらかの形で保存しておき、のちに利用する仕組みである。
　どう利用するかは実装依存だ。(なにを保存しておくかも)　問い合わせの履歴でもある。
{{{
キャッシュになにをどういう形で保存するかは、実装依存です。
　つまり、なにも規定がない。これがいろいろな動作がある理由です。
}}}
[[DNS/実装/キャッシュサーバ]]  [[DNS/毒盛/キャッシュサーバ]]

== リゾルバーの動作 ==
リゾルバーがキャッシュをどう利用しているか。

　問い合わせの生成は？

== キャッシュ ==
なにがキャッシュにあるのか。当初はなんでもひとつのキャッシュに入れていたらしい。(BIND)
  djbdnsも似たようなものだ。

　そのうちNegative Cachingの必要性が判明した。
　　referral (delegation)情報を別に管理するものも出現(patent出願されているようだ）
　
なにをキャッシュに保持すべきか。
　とくにNegative Cachingが問題のようだ。(毒盛対策にも重要なのだが)

qname minimisationに見られるように、zone cutsを保持する必要もある。

Answerにしても、分割した方がいいものもあったり(CNAME)します。
 negative caching も必要でしょうし、 それらから推論できるENT情報も（分けて）保存したい。
 これらをキャッシュと呼ぶかどうかも考えどころです。

== zone cuts ==
zone cut情報がもっとも重要であるようだが。
  問い合わせて得られたdelegationだけではなく、
   NXDomain返答から分かる[[/zone cuts非存在]]もキャッシュに残すのがよい。
    これはまだ誰も指摘していないようだ。
  
-- ToshinoriMaeno <<DateTime(2017-02-17T11:59:53+0900)>>

キャッシュにある情報を[[/上書き]]するのはどういう場合か。


-- ToshinoriMaeno <<DateTime(2016-05-08T09:05:17+0900)>>

== DNS返答 ==
肯定返答と否定検討のキャッシュは方式が異なる。
  RCODE, Answer Section, Authority Section, Additional Section