## page was renamed from DNS/返答/返答中のNS ## page was renamed from DNS/毒盛/返答中のNS ## page was copied from DNS/NSレコード/返答中のNS ## page was renamed from DNS/NSレコード/DNS返答中のNS <> ---- <> <> = 返答中のNSレコード = <> [[../delegation返答]] を含め、 偽のNSレコードを送りつける攻撃を検討する。 [[DNS/RFC2181/s5]] ranking DNS query に対応する返答に現れるNSレコードはすくなくとも以下のむっつ（６）の異なる状況で使われている。 1. NS query に対する返答: 現在はNSを問い合わせることはほとんど行われていない 2. [[DNS/委譲|本来の委譲]]（委任）:　[[DNS/委譲返答]] で上位のゾーンサーバが委譲を示すために使う 3. 委譲を確認する：　（オレオレ）権威をもつゾーンサーバであることを確認するために返す。 4. NS移転を示す： （オレオレ）権威をもつゾーンサーバがNS移転、追加を示すために返す。 5. 問い合わせ削減用：　ゾーンサーバが効率改善のためにおまけとして付ける。 6. 余計なお世話：　キャッシュ兼用サーバがキャッシュされた（権威を持たない）データ（多くは上位ゾーン）を返す。 キャッシュ兼用でなくても、root を返すものもあるかもしれない。 これら以外にも現れるかもしれない。(禁止はされていない。w) 1 で Answer sectionに現れる以外は Authority Section に現れる。 3に分類されるのだろうが、NXDOMAIN, NoData 返答中にも現れることがある。(主たる目的は毒盛だろう。) １、２ 以外は無用な返事であると言える。毒盛に使われる。 　これらを受け入れるときには、十分な検査をして、毒の危険性を少なくすること。 　受け入れたとしても、どう利用するかという問題もある。 ３ はあった方がいいかもしれないが、信用するのは危険。 　answer の有無、nxdomain などで分ける必要があるのかも。 -- ToshinoriMaeno <> == 検討 == これらの使い方がどういう文書で裏付けられた根拠をもつのか、それとも実装が勝手にやっているだけなのか、 これから調べます。 　まずは RFC 1034 から。 NS の移転のケースは想定されていないらしい。　-- ToshinoriMaeno <> キャッシュを上書きすることを認めているように読んでいるひとがいるのはRFC2181だが、 　RFC2181はセキュリティに関しては考慮していないことがはっきりしている。 　 キャッシュの上書きは毒盛される危険性があることを承知の上での意見であれば、議論にのります。 {{{ サーバがキャッシュしているデータとRRSetを構成するようなデータが返答中にある場合、 　サーバは返答中の RRsを無視するか、現在キャッシュにあるRRSetを捨てさるか、適当な方を選択する。 }}} 返答を優先すべき理由は存在しないと考える。ただし、RRSetだけを根拠にすることが間違っているのだろう。 -- ToshinoriMaeno <> 　たとえば、delegationに使われたNS(とglue)は返答に使うキャッシュには保存すべきものではない。 ---- 上方参照（余計なお世話）の典型はBINDが標準設定で返すと聞いたルートサーバ情報だ。 （こんなものを受け入れるリゾルバーがいまもあったら見てみたい。） 捨てられだけのものを送るのはネットワーク帯域の無駄使いでしょう。 2008年のKaminsky講演で使われたスライドに現れるNSは「委譲」、「移転」とは別ものだと考える。 　民田スライドに現れるものはAnswer section がある返答に「おまけでつけられている NS RRSet」 だから。 「滲透しない」というひとがいるのも一部はDNSゾーンサーバの移転方法が関係している。 これも「移転」返答の処理に不良があるケースかもしれない。 Ghost Domain Names (鬼域名、幽霊ドメイン名）脆弱性は委譲ではなく、 「NSの移転」の処理に脆弱性（不良）があったのを攻撃されたものです。（ISCはDNSの本質的問題だと修正しない態度だった） 委譲（委任）を示す返答中のNS RRSet がもっとも重要であることは言うまでもないでしょう。 毒盛の対象として、一番狙われるものです。（でも、「なにが委譲なのか」はきちんと理解されているかどうかあやしい）