## page was renamed from DNS/実装/リゾルバー計画/response == DNS/実装/リゾルバー計画/response == <> <> [[DNS/実装/python/dnslib/リゾルバー]] [[../data-structure]] [[../query]] root-serverから順に問い合わせドメイン名に到達するまでのゾーンをたどる。 　zone cutsの存在を調べながら、降下していくことにする。（qname minimisation) 内部処理するドメインについての返答生成も含む。 response生成と関連データ構造の更新とがある。 == response 処理 == [[/respense]] 　delegation返答を疑え。 　　1. unbound風にdelegation返答は権威あるNSを確認する。 　　　　しかし、これだけでは偽delegationを排除できない。 　　2. 事前に受け取ったSOA返答から、 　　　　zonecut非存在が分かる名前へのdelegationは毒であると判断する。 　　3. delegation返答を再確認する。random nameを付けて、NSを問い合わせてみる。 毒盛対策を中心に考える。特にゾーンサーバからの不正なデータを除去する。 　Kaminsky流の攻撃でも、NS毒盛やCNAME毒盛が排除できることを目標とする。 === Answer Section === query名以外のownerをもつanswer recordは捨てる。 　どういう場合に余分のレコーダがanswer sectionについてくるのか。 　　CNAMEだけではないか。 ==== CNAME ==== in-baliwick検査では不十分である。（毒の場合） 　query名以外のownerをもつanswer recordは捨てる。 (重要)CNAMEレコードのownerは他タイプのレコードを持てない。 　CNAME answerの場合の検査。 　（CNAMEがキャッシュにあれば、問い合わせは発生しないはず） === Authority Setion === Answer Sectionが空でない場合のAuthority/Additional Sectionは捨てる。 　この場合のAuthority Sectionなどがどういう意味を持つのかの規定はない。 NXDomain返答中のSOAの扱いは今後、考慮する。 　 === NoData 返答 === Kaminsky流攻撃ではNXDomain返答しか返らないわけではない。 　返ってくるはずのSOAでzone cutの不在が分かる。 ==== negative response ==== SOA cuts information (Maeno) === delegation === NS毒の排除 　nonceを付けて、問い合わせ直すのがよい。 　　delegation返答が得られたら、権威サーバに権威あるNSを問い合わせ直すこと。 == cache overwrite == RFC2181にあるような判断を避けるための原則 　キャッシュになにを置くの判断が問題だ。 特に(権威のない）delegation返答はキャッシュしないというのが大事だと思う。 　nonceつきの再問い合わせのあと、権威サーバに問い合わせしたものをキャッシュにいれる。 　問題はTTLだ。Ghost Domain Names を発生させないための工夫が必要になる。