Contents
| /キャッシュ内のNSレコード |
1. 返答中のNS
偽のNSレコードを送りつける攻撃手法を検討する。 DNS/毒盛再考 DNS/毒盛/NS毒盛
DNS query に対応する返答に現れるNSレコードはすくなくとも以下のななつの状況で使われている。
- 1 が Answer Section に現れる以外はすべて Authority Section に現れる。
- NS query に対する返答:（権威あるサーバからのAnswer）
返答がCNAMEレコードである場合は別途取り扱う必要がある。-- ToshinoriMaeno 2019-03-16 07:27:57
委譲を確認するために存在するNSはこれによるべきだと考える。 -- ToshinoriMaeno
2015-09-16 21:54:32
- 現在はNSを問い合わせることはほとんど行われていない。qname minimisationの実装が進めば、状況は変わるだろう。
- 委譲を確認する： (Answer あり) （オレオレ）権威をもつゾーンサーバであることを「確認する」ために返す。 （根拠なし）
- NS移転を示す： (Answer の有無は不明） （オレオレ）権威をもつゾーンサーバがNS移転、追加を示すために返す。 （間違った用法）
- 問い合わせ削減用： （Answer あり） ゾーンサーバが効率改善のためにおまけとして付ける。 （これなら、多少意味がある）
- 余計なお世話： (Answer なし） キャッシュ兼用サーバがキャッシュされた（権威を持たない）データ（多くは上位ゾーン）を返す。
- キャッシュ兼用でなくても、root を返すものもあるかもしれない。
- 否定返答の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
1.2. 無用な NS
上方参照（余計なお世話）の典型はBINDが標準設定で返すと聞いたルートサーバ情報だ。 （こんなものを受け入れるリゾルバーがいまもあったら見てみたい。） 捨てられだけのものを送るのはネットワーク帯域の無駄使いでしょう。
1.3. 毒盛に使われる NS
2008年のKaminsky講演で使われたスライドに現れるNSは「委譲」、「移転」とは別ものだと考える。
- 民田スライドに現れるものはAnswer section がある返答に「おまけでつけられている NS RRSet」 だから。
「滲透しない」というひとがいるのも一部はDNSゾーンサーバの移転方法が関係している。 これも「移転」返答の処理に不良があるケースかもしれない。
Ghost Domain Names (鬼域名、幽霊ドメイン名）脆弱性は委譲ではなく、 「NSの移転」の処理に脆弱性（不良）があったのを攻撃されたものです。（ISCはDNSの本質的問題だと修正しない態度だった）
1.4. 委譲返答中の NS
委譲（委任）を示す返答中のNS RRSet がもっとも重要であることは言うまでもないでしょう。 毒盛の対象として、一番狙われるものです。（でも、「なにが委譲なのか」はきちんと理解されているかどうかあやしい）