トップ 最新 追記

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


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

2017-08-07 総務省の注意喚起は FUD

DNSSEC に関する一連の注意喚起で混乱中の皆様へ

総務省をはじめとする一連 (NISC,JPRS,JPNIC,JPCERT/CCあるいはそれらを元にした報道) の DNSSEC KSK ロールオーバーに関する注意喚起を鵜呑みにしてはいけません。総務省データ通信課の高村信企画官は注意喚起文書の文面が嘘も方便あるいは FUD であることを認め、さらには注意を喚起するためには「Terrible Story (恐ろしい話) が必要だった」とまで発言されています。(先日の記事参照)
彼らの説明や対策は DNSSEC 推進のための余計な方策が組み込まれているために、非常に複雑なものになっている一方で説明すべきことを説明していないために専門家が読んでも理解不能な文書になっています。DNSSEC推進やフラグメントの問題などネットワーク健全化の話は今回の問題とは分けたほうがすっきりしてわかりやすくなると進言もしたのですが、高村氏は「政府は DNSSEC 推進の立場にあり、それを盛り込まないわけにはいかない」と発言し、それを拒否しました。(いつ政府が DNSSEC 推進だと決まったのでしょう? 今のところ go.jp では 4 ドメインくらいしか DNSSEC 署名がなされていないように見えます。NISC.GO.JP や NPA.GO.JP, IPA.GO.JP, KANTEI.GO.JP ですら無署名です。)

彼らとは別な立場からは彼らの説明とはもっと異なるシンプルな問題回避策がありますので、混乱している方々のためにここに記したいと思います。

まず第一に DNSSEC はほとんど安全に寄与しないどころか害ですらあります。DNSSEC推進、そして今回の対策はその害を拡大するものです。(参考: 「DNSSEC はなぜダメなのか」)

一連の注意喚起(特に総務省)は、

  1. DNSSEC を有効にせよ (総務省)
  2. ルートの鍵更新に追従せよ
  3. UDP のサイズ制限を拡大せよ
  4. 9/19 に増大する KSK 応答を受け取れなくなり、名前解決に障害が発生する可能性があるので、サーバのみならずネットワーク機器などを洗いざらい調査せよ

などというものです。これらがどうおかしく、どう対処するのが本当は適切なのか説明します。

第一の適切な対処: DNSSEC 署名の検証は無効にしましょう

総務省の言い分はDNSSEC を有効にせよというものです。これは現在有効にしていなくてもこの機会に有効にして鍵を更新しておかないと、将来本格利用してもらうときに再度困ったことになるからというのが総務省の説明でした。いらぬお節介が過ぎるでしょう。DNSSEC の害は 「DNSSEC はなぜダメなのか」に書いたとおりです。DNSSEC 署名の検証は無効にし、さらに DNSSEC も無効 (これが詳しくない人には意味不明だと思いますが専門的には DO bit off) にするとよいでしょうがクライアントが必要としていたり、実装上無効にできない実装もあったりするようです。でも検証しなければ問題はないと ICANN の文書にもあります。(問題あるかのように書かれている文書は書き方が悪いかミスリードの意図がある)

第二の適切な対処: DNSSEC の署名を検証したい方は鍵更新について専門の文書に従いましょう (よく勉強して)

早い時期から DNSSEC に手を出しておかしな設定をしたような経緯がない組織では問題になるようなことはないでしょう。最近の実装は普通にインストールして普通にアップデートしていれば問題はないはずです。そもそも DNSSEC の仕組みがわかっていない組織が DNSSEC に手を出すべきではありません。障害対応が出来なくなるでしょう。

第三の適切な対処: UDP サイズ制限は小さくしましょう

DNSSEC を推進する方々はなぜか UDP を使わせたがります。そして 大きな応答も UDP で扱えるよう、キャッシュ DNS サーバで UDP のサイズ制限 (Unbound だと edns-buffer-size:) を大きくしましょうというのが注意喚起が要求していることなのですが、これこそがマッチポンプで問題を生じさせる話なのです。UDP サイズを大きくすると IP フラグメントが発生しやすくなり、もし通信経路上にフラグメントを適切に扱えない機器があったら障害が発生するかもしれないわけです。(ただ今回は Ethernet の 1500 バイトやフレッツの 1438-1454 バイトを越えるわけでもなく、心配すべきは例えば IPv6 や VPN を使っている人くらいなのではないでしょうか。騒ぎすぎです。)
今回はむしろ UDP サイズ制限は小さくするべきです。今回注意喚起にある MTU 1280 バイトに収まるサイズにすると IP フラグメントの発生する可能性はずっと小さくなり、通信経路を全部心配する必要もなくなります。例えば 512 バイトにしてしまえば、DNSSEC 登場以前の DNS のように 512 バイトを越える応答は DNS の仕組み (truncate) に従って UDP よりずっと安全な TCP に切り替わってくれるはずです。(ただしこの場合、ファイアウォール等で TCP 53 が止められていないことを確認することが重要です。TCP のサポートは RFC でも必須となっています。TCP に未対応のドメインが少数あるかもしれませんが、そういうところは DNSSEC にも未対応でしょうし、もし大きな応答を返すようなら自業自得で責められるべきでしょう。)
なぜ、これを一連の注意喚起を出した人たちは説明しないのでしょう。TCP だとルートサーバの負荷が増えるとか ANYCAST で問題がでるかもしれないとか理由がないわけではありませんが大した問題には思えません。ルートサーバの負荷が問題なら DNSSEC やらなきゃいいのに。本音は TCP だと DNSSEC の必要性が薄れるからなのではないでしょうか。

第四の適切な対処: ネットワークの調査・対策は急ぎません

第三の対処で総務省等の注意喚起とは逆に UDP のサイズ制限を小さくしておけば、経路全体を心配する必要がなくなります。今回の注意喚起を機会に調べるのは大変結構なことではありますが、杞憂でいらぬ騒動をさせられる現場の人たちがかわいそうです。慌てず予算と他の仕事に余裕のあるときに調べれば良いのではないでしょうか。なお、フラグメントはセキュリティポリシーで止められているかもしれません。第一フラグメント便乗攻撃などといった攻撃も心配されますし、甘いチェックでセキュリティ機構をすり抜ける IP フラグメントは他のリスクを招き寄せるからです。

以上は、DNSSEC 推進をもとにした注意喚起に反対の立場から書かせてもらいました。推進の立場の文書とあわせて、自分の頭で考えてみることが一番大切なことです。もちろんご相談には応じますけれど。


追記(8/24):この件でセミナーを企画しました。

追記(9/11): セミナーの資料 「DNSSECの仕組みとKSKロールオーバへの対応」 を公開しました。

追記(9/2): Unbound の edns-buffer-size の推奨値が間違っていたことがわかりました。おかしいと思った。(Unbound-Users ML より)

参考リンク

本日のツッコミ(全4件) [ツッコミを入れる]

Before...

tss [本文中、MTU と UDPサイズを混同してしまっている部分がありますが、細かく書きなおしませんのでご自分で換算してく..]

tm [「DNS 署名検証チェック」はおかしいので、 「DNSSEC署名検証の有無判定」あたりにしたら。w (リンク先はDN..]

tss [採用させて頂き TYPO も直しました。ありがとうございます。]


最近の日記

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