## page was renamed from DNS/毒盛/hitch-hiker/bailiwick-checking ## page was renamed from DNS/毒盛/itch-hiker/bailiwick-checking ## page was renamed from DNS/hitch-hiker/bailiwick-checking = DNS/hitch-hiker/bailiwick-checking = 付録にある p.19, 20 の説明が納得いかないので、検討してみる。 -- ToshinoriMaeno <> 自分なりの結論は「あの図は古いし、誤解もありそうなので、使えない」というものです。 　　BIND (p. 19) はひどすぎる。 ---- この検査はゾーン（権威）サーバからの返答に入ってる毒を検知して捨てるためのものです。 　毒盛攻撃としての「偽返答を検知する」ためのものではない。（典型的毒盛攻撃は[[DNS/毒盛/Mueller手法]]をみよ） 　　（RFC 2181 の ranking も設定間違いを軽減するためでしかない。毒を入れ易くなっているのは本末転倒） <> == answer section の有無で判別 == なぜ。 本来の返答以外にCNAMEの本名情報が含まれていることがある。 　その扱いには注意が必要である。（DNS RFC の問題） answer section ありの場合に authority section を受け入れるのは毒盛の危険が大きい。 　私は捨てるのがいいと思っている。（受け入れのための検査は複雑さを増す）　-- ToshinoriMaeno <> == answer section ありの場合 == authority(+additional) にあるのは委譲（委任）返答ではなく、自称権威サーバ情報である。 　移転（通知）情報と呼ばれることもある。（毒盛の助けになり、害の方が大きいおかしな機能） 　　RFC 1034 では認められているようには読めない。　（DJBは勧めていない。） しかも、キャッシュの上書きすらしてしまう。 1. 上位ゾーンからの委譲情報よりも優先される。　（というおかしな扱い） 2. 同位のNSが返ってくるケースもある。　移転通知であり、キャッシュを上書きする。 == answer section なしの場合 == authority section にサブドメインについてのNSレコードがあることがある。 　委譲（委任）情報の可能性がある。 DNSレコード分散のための仕組みなので、はずせない。 　委譲情報として受け入れてよいかのしっかりした確認が重要である。 　　TCPを使うとか、エントロピーを増やして、問合せしなおすなど。 -- ToshinoriMaeno <> == 親子ゾーン同居のケース == どういう返答があり得るのか、まだ分析できていない。 -- ToshinoriMaeno <> == unbound の検査 == 返答中の out-of-bailiwick 情報をすべて捨ててから、処理を始めるように読める。