## page was renamed from DNS/毒盛/2014/雑感 ## page was renamed from DNS/毒盛2014/雑感 ## page was renamed from DNS/毒盛再考/雑感 ## page was copied from To_tss/2014-06-12 <> {{{ 雑感、課題 }}} == キャッシュNSを上書きするとして、毒が入るケースとは == なにを問い合せれば、キャッシュが問い合せを送り出し、どういう返事（本来のものと毒と）が返ってくるか、 よく考えないといけない。　（すべての場合を尽くすのが当面の課題） [[DNS/GhostDomainNames]] が鍵になっている。 [[/幽霊ドメイン名]] == ゾーンサーバからの返事にNSレコードを加えておくのも悪くない == answer section がある場合には additional などはつけない方がいいと思っていますが、 すこし考えなおしています。　（よく考えないと、いろいろ矛盾している） {{{ キャッシュがNSを受け入れて（キャッシュになかったなどで）、以降は上書きされないのであれば、TTL期間は守られる。 }}} 上書きしておいて、上書きされないと考えるのであれば、なにかおかしい。　（tssさんの新発見という可能性がある。） 　 上書きされる条件とはなにかをはっきりさせる必要がある。 ということで、NXDOMAIN返答のときにも、NSレコードをつけて返すのが対策として有効ということになる。（RFCの変更） 　毒盛の機会を大幅に減らすことができるという意味です。 == 効果は疑問か == co.jp のようなNSがないノードについては効果はないでしょう。 キャッシュ内のNSが上書きされるケースがあるなら、意味のない議論かも。 -- ToshinoriMaeno <> 　 == NS 上書きは慎重に == NS の移転などというものは滅多にするものではないので、 NS を簡単に上書きするとしたら、実装に問題があると考える。 上書きしないことを原則にして、必要かもしれないケースを洗い出す方がよさそう。 unbound, Google Public DNS などが参考になるか。　MaraDNS/Deadwood は参考になる。 -- ToshinoriMaeno <> == Google cache の振る舞い == 権威をもったサーバの返事を受け入れているようです。（つまり、毒が入る可能性が高い） -- ToshinoriMaeno <> 私が使っている tinydns では minimum response 風の返事をするようにしていましたが、 　毒盛テストには都合が悪いので、元通りに、answer があっても authority/additional section をつけるように戻しています。 -- ToshinoriMaeno <> == RFC 2308 == [[DNS/RFC/2308]] も勉強しなおす必要がある。　ネガティブキャッシング