## page was renamed from DNS/キャッシュ毒盛 = DNS/キャッシュ毒盛 = <> <> [[DNS/毒盛]] 現状のDNSキャッシュ(リゾルバー）には比較的簡単に偽情報を注入することができる。 == 注入の手口,あるいは条件 == 1. リゾルバーが外部に問い合わせるきっかけを与える。(与えられることが条件） 2. 本来の返答より先に偽の返答を送りつける。(送信元を騙る） 3. リゾルバーが偽返答を本来の返答だと思う。(返事の内容） Kaminskyはリゾルバーが問い合わせを発生するきっかけを外部から与えられることを指摘した。 　しかし、どういう情報が入れやすいかについての解説は見当たらないので、以下にまとめておく。 -- ToshinoriMaeno <> [[DNS/毒盛]]　[[DNS/毒盛/キャッシュ毒盛]] == 防御 == 手口に書いたみっつの項目についての対策を考える。 1. 信頼できない相手からの問い合わせは拒否する。(アクセス制限) 2. ゾーンサーバ側の問題なので、対応できない。（送信元の確認くらいか。） 3. 正当な返答かどうか確認 ここでは3番目の項目について、特にNS毒について、検討する。 == NS 毒 == 入れやすい毒のひとつにNSレコードがある。特に以下の二つが課題である。 1. delegation (Muellerの指摘) 2. NS移転情報によるキャッシュの上書き 後者は毒の可能性のあるレコードによって、キャッシュにあるレコードを上書きするという危険な動作をしていることが 理由であるので、実装の不良であると考える。 　この動作をとめることで、解消する。（利用上の不利益もほとんどない） 　　　https://tools.ietf.org/html/draft-weaver-dnsext-comprehensive-resolver-00 従って、重要なのはdelegation返答に含まれる毒を検出することだと言える。 　delegation返答は簡単に信用せず、問い合わせ直すなど、慎重な対応が望ましい。 -- ToshinoriMaeno <> === 否定返答を使った防御 === 本来の返答がNXDOMAINやNo Nameなどの否定的返答である場合には、 　query nameが属するゾーンに責任をもつSOAレコードが付随するはずなので、 　中間的ノード名にはNSレコードが存在しないことが確認できる。 現状のリゾルバーはこの情報を利用していないために毒盛されやすい。 -- ToshinoriMaeno <> === 肯定返答を使った防御 === wildcardレコード設定を行っていると、Answerあり返答になることもあるから、 SOA情報は毒見には使えない。（このことから、wildcard設定があると防御しづらいと言える。） ただし、返答があったという事実はSOAレコードと同様にzone cutの不在を示すので、 この情報を毒見に使えると思う。（親子ゾーンの同居時は別途検討する必要がある。否定返答と同様） -- ToshinoriMaeno <> == 系列ゾーンの同居の検討 == 親子同居については、子ゾーンはゾーンとして独立していないものとみなすことで対応できる。 　つまり、子ゾーンへのdelegationが返ることはないので、毒である。 親の親（祖先）などと同居している場合にはすこし話がややこしい。 　祖先からは親へのdelegationが返ってくることがあるからだ。(zone cutの存在） -- ToshinoriMaeno <> com/net NS (*.gtld-servers.net) gtld-servers.net NS (*.nstld.com) というややこしい関係を設定しているのが、verisign