/ゾーンが存在しないしないことが推定できる返答  

1. DNS/毒盛/NS毒盛/対策

Contents

  1. DNS/毒盛/NS毒盛/対策
    1. 対策
    2. この対策で十分か
  2. 毒盛攻撃の検知も重要である
  3. 攻撃の検知は有効か
  4. 別の方向の対策
(1) answer sectionが空でない返答(delegation返答ではない返答)を受けとったら、
　answer sectionにある情報だけを受け入れるのが安全です。
  　authority sectionなどに毒が入っているかもしれません。
(2) delegation返答の場合でも、
すでに[[/ゾーンが存在しないしないことが推定できる返答]]を得ている状態であれば、
NSを問い合わせ直すことで毒を排除できます。

すべてのdelegation返答を疑う必要はない。-- ToshinoriMaeno 2017-09-15 23:25:44

DNS/毒盛/対策/NXDOMAIN返答活用に現状でのベストの対策を書きました。(実装はまだ）

この返答を利用することで、余分の手間をかけずにかなりの毒を排除できます。

ワイルドカードを設定しているゾーンからの返答(Answer Section)ありの場合でも、

Kaminsky(2008)のスライドにある攻撃方法は毒盛対策されたキャッシュに対しては成功の可能性は少ない。

攻撃の内容 

  $RANDOM.foo.com についての query を送りつける。(start)

別の返答を考える。(民田スライド　IW2008-H3-07.pdf) 

　$RANDOM.foo.com についての返答はあってもなくてもよい
  foo.com IN NS www.foo.com 　　 [authority section]
  www.foo.com IN A 6.6.6.6       [additional section]

この返答は拒否できるか。

1.1. 対策

キャッシュされているレコードを上書きしない。

キャッシュの効率を少し下げることになるが、authority section, additional section を捨てる。

".com サーバ"に問い合わせた結果が上の返答だったのであれば、 "referralであり、glue である"ということになるが、 そのためには foo.com サーバの情報がキャッシュされていないという前提が必要である。 しかし、そういう前提についてはどこにも触れられていない。

-- ToshinoriMaeno 2009-08-11 06:33:11

1.2. この対策で十分か

これで十分な対策かというと、残念ながらそうではない。

glue レコードを通常の A レコードと区別してキャッシュするという提案もあるが、回避した攻撃も可能である。

当面の対策としては (一年前だったら）

  1. 公開キャッシュサーバをやめる。
    1. キャッシュサーバの使うportをランダム化する。

ことが重要である。

2. 毒盛攻撃の検知も重要である

無用な返答が多数送られてきたら、警告を発して、警戒モードに移る。

DNSSECを普及させたい人達はDNSSECしか解がないようなことを言っているが、 それは嘘である。ほかにも方法はあるし、DNSSECが急速に普及する可能性は小さい。

Kaminsky の指摘と警告があっても対策されていない DNS サーバが多数ある現状では、 「DNS を信用しない」という態度が重要であると考える。 たとえ対策ずみであっても、(ISP 提供の)公開キャッシュサーバは危険である。

3. 攻撃の検知は有効か

多数の問合せは検知できるとしても、時間をかけた攻撃の検知が可能とはかぎらない。

4. 別の方向の対策

それよりも、NSレコードの受け入れ検査をもっと厳しくする方が現実的だし、 TCPを使って DNS query やりとりを行う方が現実的だと思う。

TCPでは負荷が上がり過ぎというひとは、毒盛の危険性を小さく見ているのであろう。 -- ToshinoriMaeno 2014-10-06 06:17:58