MoinQ: DNS/リゾルバー/計画/response

1. DNS/実装/リゾルバー計画/response

DNS/実装/python/dnslib/リゾルバー ../data-structure

../query

• root-serverから順に問い合わせドメイン名に到達するまでのゾーンをたどる。

• zone cutsの存在を調べながら、降下していくことにする。（qname minimisation)

内部処理するドメインについての返答生成も含む。

response生成と関連データ構造の更新とがある。

2. response 処理

/respense

• delegation返答を疑え。
  1. unbound風にdelegation返答は権威あるNSを確認する。
     • しかし、これだけでは偽delegationを排除できない。
  2. 事前に受け取ったSOA返答から、
     • zonecut非存在が分かる名前へのdelegationは毒であると判断する。
  3. delegation返答を再確認する。random nameを付けて、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 を発生させないための工夫が必要になる。