= NS 毒盛 = <> <> 2008年にKaminskyが指摘した毒盛手法はAdditional Sectionを利用するものであった。(BINDの脆弱性) おなじ時期にMuellerが指摘したのはAuthority Section (NS)を利用するものだった。 ここでは後者について、検討する。 NS毒盛とはなにか。[[../2014]] 多くのNS毒は受け入れられる。ただし、毒として効果の大きいものは限られる。 そして[[/対策]]とは。[[../2016]]　 [[DNS/毒盛/対策/NXDOMAIN返答活用]] == 返答中のNSレコード == [[DNS/1/資源レコード/NS|NSレコード]]はDNS返答のさまざまな状況で現れる。 [[DNS/1/資源レコード/NS/返答中のNS]] どんな返答のAuthority Sectionにも含まれうると考えておく。 最近話題になったのはNXDOMAIN返答中に含まれたNSレコードによる毒盛です。[[/]] == ゾーンファイル中のNSレコード == ゾーンの根元に付随するNSと委譲を示すNS（ゾーンの末端ノードに付随するNS)とがある。 　NSはゾーンカット（だけ）に現れるレコードだとも言えます。二つの顔を持っています。 親子関係にある複数ゾーンを同一サーバでサービスしていると、 NSは別の場面でも現れて、話を複雑にします。 (-- ToshinoriMaeno <>) == 毒盛手法の分類について == きちんと定義がされないままで、現象を指すだけの言葉を広めようとすることの害： 　言葉だけがひとり歩きして、理解するのにはじゃまになります。 一面しか見えていない状態での命名は害も多そうです。 === 毒NS の分類 === なにを毒として送りつけるかという視点からの分類：[[/NS]]　 「どこからの返事として送りこむか」は別項目とした。 [[DNS/返答/referral]] か　[[../AncillaryDataAttacks]] か === 目標の状態による分類 === キャッシュされているものがなにかによって、話が違ってくる。[[/Ranking]] [[DNS/1/資源レコード/NS/返答中のNS/キャッシュ内のNSレコード]] [[DNS/毒盛/対策/zone cutsの非存在]] も重要な情報だ。 1. キャッシュにNSなし --> いわゆる「委任インジェクション」が狙う状態 2. キャッシュに委譲のNS(親からの情報）　JPRSのいう「移転通知インジェクション」 が狙う状態 3. キャッシュに権威ありNS（Authority Section 由来） tssさんの「[[/移転インジェクション]]」で現れる状態 　　この場合にも上書きされる実装があったことはGhost Domain Names脆弱性のときに示されている。 4. 権威ありNS（問い合せの結果、Answer Sectionで得られる）のキャッシュ。 　　NS毒は取り込まないようだが、glue はどうか。BINDは危ないらしい。-- ToshinoriMaeno <> [[/authanswerの書き換え]] https://twitter.com/beyondDNS/status/984349535475412993 == RFC 2181 == RFC2181のRankingを遵守するなら、これらの区別は必要だろう。 RRSetの優先順位が述べられている。 　ただし、2181は「返答が毒ではない」ことを前提の議論になっている。つまり、毒見には使えない。 毒も考慮するとしたら、どうするのがより安全かは述べられていない。 これらの情報以外に、[[/zone cutが存在しない]]という情報が得られている可能性が大きい。(攻撃時） 　現存するリゾルバーでこの情報を利用しているものは見あたらない [[DNS/NSレコードの上書きの害]] === どこからの返事なのか === 委譲を示すNSも委譲する資格のあるサーバからのものかどうかを確認すること。 毒盛する側から見ても、どこからの返事として送りこむかは重要な点だ。 UDPではパケットの送信元を詐称するのは簡単だから、見分けるのは簡単ではない。 == 対策 == delegation responseをもらったら、すなおに受け入れてはいけない。 1. [[/zoneの非存在]]が示されていないか。（攻撃だったら、キャッシュにマークがあるはず） 2. TCPで問い合わせ直す。（nonce付きで） <>