1. NS 毒盛

Contents

2008年にKaminskyが指摘した毒盛手法はAdditional Sectionを利用するものであった。(BINDの脆弱性)

おなじ時期にMuellerが指摘したのはAuthority Section (NS)を利用するものだった。ここでは後者について、検討する。

NS毒盛とはなにか。../2014

1.1. 返答中のNSレコード

どんな返答のAuthority Sectionにも含まれうると考えておく。

最近話題になったのはNXDOMAIN返答中に含まれたNSレコードによる毒盛です。/

ゾーンの根元に付随するNSと委譲を示すNS（ゾーンの末端ノードに付随するNS)とがある。 NSはゾーンカット（だけ）に現れるレコードだとも言えます。二つの顔を持っています。

親子関係にある複数ゾーンを同一サーバでサービスしていると、 NSは別の場面でも現れて、話を複雑にします。

きちんと定義がされないままで、現象を指すだけの言葉を広めようとすることの害：

なにを毒として送りつけるかという視点からの分類：/NS　「どこからの返事として送りこむか」は別項目とした。 DNS/返答/referral か　../AncillaryDataAttacks か

キャッシュされているものがなにかによって、話が違ってくる。/Ranking

キャッシュにNSなし --> いわゆる「委任インジェクション」が狙う状態
キャッシュに委譲のNS(親からの情報）　JPRSのいう「移転通知インジェクション」が狙う状態
キャッシュに権威ありNS（Authority Section 由来） tssさんの「/移転インジェクション」で現れる状態
- この場合にも上書きされる実装があったことはGhost Domain Names脆弱性のときに示されている。
権威ありNS（問い合せの結果、Answer Sectionで得られる）のキャッシュ。
- NS毒は取り込まないようだが、glue はどうか。BINDは危ないらしい。-- ToshinoriMaeno 2018-04-12 09:58:20
  - /authanswerの書き換え

RFC2181のRankingを遵守するなら、これらの区別は必要だろう。 RRSetの優先順位が述べられている。

毒も考慮するとしたら、どうするのがより安全かは述べられていない。

これらの情報以外に、/zone cutが存在しないという情報が得られている可能性が大きい。(攻撃時）

委譲を示すNSも委譲する資格のあるサーバからのものかどうかを確認すること。

毒盛する側から見ても、どこからの返事として送りこむかは重要な点だ。

UDPではパケットの送信元を詐称するのは簡単だから、見分けるのは簡単ではない。

delegation responseをもらったら、すなおに受け入れてはいけない。