1. 返答中のNS

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

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

• 1 が Answer Section に現れる以外はすべて Authority Section に現れる。

1. NS query に対する返答:（権威あるサーバからのAnswer）

   • 返答がCNAMEレコードである場合は別途取り扱う必要がある。-- ToshinoriMaeno 2019-03-16 07:27:57

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

2015-09-16 21:54:32

• 現在はNSを問い合わせることはほとんど行われていない。qname minimisationの実装が進めば、状況は変わるだろう。

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

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

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

• NSレコードを受け入れるときには、/十分な検査をして、毒の危険性を少なくすること。　 受け入れたとしても、どう利用するかという問題もある。

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

• answer の有無、nxdomain などで分けて考察する必要がある。

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

• -- ToshinoriMaeno 2014-06-22 16:15:59

1.1. 検討

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

• まずは RFC 1034 から。 NS の移転のケースは想定されていないらしい。　-- ToshinoriMaeno 2014-03-29 22:16:49

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

1.2. 無用な NS

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

1.3. 毒盛に使われる NS

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

• 民田スライドに現れるものはAnswer section がある返答に「おまけでつけられている NS RRSet」 だから。

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

DNS/毒盛/NS毒

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

1.4. 委譲返答中の NS

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