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