## page was renamed from DNS/毒盛/2014/対策 ## page was renamed from DNS/毒盛2014/対策 ## page was renamed from DNS/毒盛再考/対策 = DNS/毒盛再考/対策 = <> [[DNS/キャッシュ毒盛/対策]] == JPRS 注意喚起 == JPRSはキャッシュサーバの運用者にポートランダム化対策などを呼びかけただけだった。 (2014-04-15) 　http://jprs.jp/tech/security/2014-04-15-portrandomization.html Mueller 手法に言及することをかたくなに避けているように見える。 == 技術資料 == 4/30 の資料　キャッシュポイズニング攻撃対策： キャッシュDNSサーバー運用者向け―基本対策編 　http://jprs.jp/tech/security/2014-04-30-poisoning-countermeasure-resolver-1.pdf 5/30 の資料　キャッシュポイズニング攻撃対策：権威DNSサーバー運用者向け―基本対策編[PDF] 　http://jprs.jp/tech/security/2014-05-30-poisoning-countermeasure-auth-1.pdf （6/30 の資料 ??） == 攻撃の検知 == 攻撃に十分な時間を許せば、攻撃は成功する可能性がある。 　毒盛攻撃の検知が重要である。 　検知したらできるのは、キャッシュのクリアだ。 == キャッシュのクリア == それよりも、定期的に（一日一回程度）キャッシュをクリアする。 == キャッシュ以外の方法での情報入手 == 重要なドメインについてはあらかじめ別途DNS情報を取得しておく。 キャッシュをクリアしたら、別途入手の情報を入れておく。 -- ToshinoriMaeno <> == あまり対策にならないもの == オープンリゾルバーはやめた方がいいが、やめることがキャッシュ毒盛対策だとは思わない方がよい。 -- ToshinoriMaeno <> == キャッシュサーバを設計しなおす == NSレコードを受け入れる条件を見直すだけで、十分な毒盛耐性のあるキャッシュサーバを作ることは可能である。 DNSプロトコルの変更が必要だ、というような意見は現状を容認したい人たちの主張にすぎない。 　もしくはDNSSECを推進したいということかもしれない。 RFCはキャッシュサーバの設計要件を示すものではない。 　現状では毒盛耐性を実装するのはキャッシュ実装者の責任であって、RFC準拠だからというのは責任逃れにすぎない。 -- ToshinoriMaeno <> == DNS/TCP のすすめ == TCP で問い合わせることにより、UDP詐称パケットを受け取る心配はなくなる。 つまり、これまでの心配は解消する。DNSSECもいらない。 @SIG#