トップ 最新 追記

インターノット崩壊論者の独り言


EPIC2014
Google Public DNS (8.8.8.8, 8.8.4.4) 経由では本サイトにアクセスできないよう措置させて頂いております。

2020-01-24 DNSSEC 推進に本当に必要なこと

「つぶらな瞳で考える、DNSSECの普及に必要な何かは何か?」への暖かいエール

JANOG 45 Meeting (1/22 - 1/24) はとても有意義でした。開催に尽力された方々には感謝の念でいっぱいです。札幌の夜も堪能させて頂きました。(酔って書いてる)

今回一番楽しみにしていたセッションは 2 日目の「つぶらな瞳で考える、DNSSECの普及に必要な何かは何か?」でした。登壇者の皆さん、とても良いセッションでした。ここに再び暖かいエールを贈らせて頂きたいと思います。

「DNSSEC はすべての攻撃は防げないが防御ゼロよりは良い」という心強い推進論を拝聴しました。しかし、

  ドメインの署名率 は 3% (日本は 500?)
  検証しているリゾルバ 24.6% (日本は 9%)

とのことでした。計算してみると、DNSSEC で守られているのは 0.03*0.246=0.7% (日本は 500/1,500,000*0.09=0.3%) ということになりますかね。とても残念な状況ですね。

一方、DNSSEC 対応の TLD 配下のドメインはすべからく第一フラグメント便乗攻撃に対して脆弱になっています。第一フラグメント便乗攻撃に対する防御のエントロピーは 16bit + α、つまりカミンスキー攻撃 (2014) で大騒ぎしてポートランダマイズする前と同じです。(ポートランダマイズは第一フラグメント便乗攻撃に非力)

2014年に JPNIC、JPRS、JPCERT/CC さんたちが以下のような注意喚起を行っています。
<<< JPCERT/CC Alert 2014-04-15 >>> DNS キャッシュポイズニング攻撃に関する注意喚起

なぜカミンスキー攻撃でこのようにインターノットの危機を憂いた方々が DNSSEC 推進にあたって第一フラグメント便乗攻撃を注意喚起して対策を促さないのでしょうか? 0.7% (日本 0.4%) を守るために、99.3% (日本99.7%) が DNSSEC によって脆弱になっている状況をなぜ無視できるのでしょうか?

それから、「DNSSEC の大きな応答による DNS アンプ攻撃は問題としなくて良いのか?」という私の質問に「DNSSEC 以外にも攻撃の踏み台はいくらでもある。」との回答を頂きましたが、、、

JPNIC、JPRS、JPCERT/CC さんたちは、2013 年に、
<<< JPCERT/CC Alert 2013-04-18 >>> DNS の再帰的な問い合わせを使った DDoS 攻撃に関する注意喚起
という注意喚起をしてくださっています。

おかげ様でオープンリゾルバはかなり減ってきています。一方で攻撃者はわざわざオープンリゾルバを探さなくても、増加中の DNSSEC 署名サイト、DNSSEC 署名 TLD を踏み台にすることができます。しかもこれらは安易にブロックするわけにはいきません。より悩ましい攻撃の踏み台となりつつあります。推進すればするほど脅威となります。これを無視するのはダブルスタンダード以上の問題ではないでしょうか。

結論:

DNSSEC はキャッシュポイズニングで悪意あるサイトに誘導されるのを防ぐのに有効なのは同意です。(DNSSEC は失敗プロジェクトという私の普段の主張 は今回棚上げしておきます)
そうであるならば、、、

  1. DNSSEC 署名ドメインもキャッシュポイズニングされると、名前が引けなくなる DoS となります。 その検知と対策方法を示すべきです。
  2. JP の運用は危険です。私の指摘に壇上から支持頂きましたが NSEC3 の opt-out 運用をやめるべきです。また当然ながらフラグメント対策も必要ですね。
    (彼らは何をすべきかわかっているはずだがなぜか放置状態)
  3. 第一フラグメント便乗攻撃への注意喚起を行うべきです。我々が示したように対策は色々あります。JPRS の藤原さんの提案もあります。
    (現状は署名していないドメイン、検証していないキャッシュサーバは非常に脆弱です)
  4. DNSSEC は TCP でやってください。
    大きな UDP でキャッシュポイズニングや DNS アンプ攻撃の脅威となることを避けるべきです。TCP でやればいいじゃないですか。
    (第一フラグメント便乗攻撃を懸念して従来のデフォルト EDNS0 buffer size 4096 byte を今年予定されている DNS Flag Day 第二弾 (公式,RIPE78) で 1232 byte にしようとしているようですが未練がましい大きさですね。伝統的な DNS に戻って UDP は 512 byte までとして、DNSSEC は TCP でやればいいじゃないですか。)

これらを進めるのは DNSSEC 推進にとって不都合な真実だったりするのでしょうか? ぜひ問題点を解決しつつ 100% 近いドメインが署名し、100% 近いリゾルバが検証するよう頑張って頂きたいと思います。とても難しいと思うし、できなかったら却って危険なわけですけれど前向きがよいですよね。


参考: DNSSEC はなぜダメなのか


最近の日記

2008|04|05|06|07|08|10|11|
2009|02|03|04|06|07|09|10|11|
2010|01|03|06|09|10|11|12|
2011|01|02|03|05|06|07|10|11|
2012|03|06|07|10|11|12|
2013|02|03|04|05|06|08|09|10|11|
2014|01|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|07|08|09|10|11|12|
2016|01|06|08|12|
2017|03|07|08|09|12|
2018|04|08|10|11|
2019|01|02|07|11|12|
2020|01|02|03|05|06|07|08|
2021|02|03|09|12|
2022|02|03|05|06|
2024|02|

リンク

Copyright by T.Suzuki