1. 返答中のNS

偽のNSレコードを送りつける攻撃手法を検討する。 DNS/毒盛再考 DNS/毒盛/NS毒盛

DNS query に対応する返答に現れるNSレコードはすくなくとも以下のななつの状況で使われている。

  1. NS query に対する返答:(権威あるサーバからのAnswer)
    • 返答がCNAMEレコードである場合は別途取り扱う必要がある。-- ToshinoriMaeno 2019-03-16 07:27:57

      • 委譲を確認するために存在するNSはこれによるべきだと考える。 -- ToshinoriMaeno

2015-09-16 21:54:32

  1. 本来の委譲(委任): (Answer Section なし) /委譲返答 で上位のゾーンサーバが委譲を示すために使う。

  2. 委譲を確認する: (Answer あり) (オレオレ)権威をもつゾーンサーバであることを「確認する」ために返す。 (根拠なし)
  3. NS移転を示す: (Answer の有無は不明) (オレオレ)権威をもつゾーンサーバがNS移転、追加を示すために返す。 (間違った用法)
  4. 問い合わせ削減用: (Answer あり) ゾーンサーバが効率改善のためにおまけとして付ける。 (これなら、多少意味がある)
  5. 余計なお世話: (Answer なし) キャッシュ兼用サーバがキャッシュされた(権威を持たない)データ(多くは上位ゾーン)を返す。
    • キャッシュ兼用でなくても、root を返すものもあるかもしれない。
  6. 否定返答のAuthority Section中に含まれるもの

1、2 以外の NS は無用な返事であると言える。

3 はあった方がいいかもしれないが、信用するのは危険である。補助情報による確認が必要だろう。

4,5,6 はないほうがよい。受け取っても捨てるのが安全である。

1.1. 検討

これらの使い方がどういう文書で裏付けられた根拠をもつのか、それとも実装が勝手にやっているだけなのか、 これから調べます。

DNS/毒盛/キャッシュ内のNSレコード  

1.2. 無用な NS

上方参照(余計なお世話)の典型はBINDが標準設定で返すと聞いたルートサーバ情報だ。 (こんなものを受け入れるリゾルバーがいまもあったら見てみたい。) 捨てられだけのものを送るのはネットワーク帯域の無駄使いでしょう。

1.3. 毒盛に使われる NS

2008年のKaminsky講演で使われたスライドに現れるNSは「委譲」、「移転」とは別ものだと考える。

「滲透しない」というひとがいるのも一部はDNSゾーンサーバの移転方法が関係している。 これも「移転」返答の処理に不良があるケースかもしれない。

DNS/毒盛/NS毒

Ghost Domain Names (鬼域名、幽霊ドメイン名)脆弱性は委譲ではなく、 「NSの移転」の処理に脆弱性(不良)があったのを攻撃されたものです。(ISCはDNSの本質的問題だと修正しない態度だった)

1.4. 委譲返答中の NS

委譲(委任)を示す返答中のNS RRSet がもっとも重要であることは言うまでもないでしょう。 毒盛の対象として、一番狙われるものです。(でも、「なにが委譲なのか」はきちんと理解されているかどうかあやしい)