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