予定より大幅に遅れてしまいましたが、本記事は DNS温泉 Advent Calendar 2019 第20日目相当の記事です。タイトルにもあるように "DNSDNS Resolution" の補足・Extra Chapterとしての側面も持ちます。
また、本記事はどのような帽子をかぶっての発言でもない、個人としての記事であることを予めご了承ください。
内容は DNSSECにまつわる議論の偏り、またanti-DNSSECの主張 についてです。
背景: DNSSEC章の締め方が正直気に入らなかった
"DNSDNS Resolution"のDNSSEC章の最後に、DNSSECの問題との戦い方について、以下のように書きました:
突き詰めていくとDNS自体信用ができなくなるような極論ではありますが、そこまで気にするのであれば標準化活動やKey Ceremonyに参加するため名乗りを上げることを通してDNSSECのエコシステムに関わっていく道を取れば介入できないこともないでしょう。
正直これを書くにあたっても「どうせDNSSEC反対論者を完全に満足させることはできないだろう」ということで割と含みをもたせた表現にしてしまったと思っていたのですが、DNS温泉やIETFのDNSシーンに関わっていく中で、 そもそもこの主張自体が根本的に誤りである ということに気づくに至りました。
DNSSECにまつわる議論は「党派性」が強い
まず、DNSSECの標準化を行っている人々は必然的にpro-DNSSECです。もちろんDNSSECの問題に対して改善提案をしたいという人はいるかもしれませんが、DNSSECの改善を議論する場で「根本的にDNSSECは誤りである、DNSSECをやめろ（ひいてはDNSをやめろ）」という主張が受け入れられることはないでしょう。また、DNSSECの技術を解説するリソースを書いている人々も、ほぼpro-DNSSECと見てよいでしょう。少なくとも私が本編を書くにあたって引用した記事はICANN、JPRS、JPNICなど、「DNSやIPアドレスなどの現状のインターネットの仕組みを維持し普及を推進する側」の立場の人が書いた記事です。これについて問題があるとは私は思いません。実際に日本で最もDNSSECについて力を注いできた組織が書いている記事なのだから技術的にはかなり正確であると考えられるでしょう*1。とはいえ、このような性質を持つために、anti-DNSSEC論者が何を問題視し、なぜDNSSECに反対しているのか、ということは紹介されることはありません。必然的にDNSSECにまつわる議論は「党派性」を帯びてしまうわけです。
DNSSECと比較できそうな技術
DNSSECが保証するとされる「ドメイン管理者が意図した接続先に正しくつなげること」*2と近いことを保証する技術として、TLS(とPKI)、BGPにおけるRPKI(Resource Public-Key Infrastructure)があります。これらと比較対照することでDNSSEC反対論者がいかなることを問題視しているかの一端がわかるのではないかと思います。
信頼のあり方について、再
DNSSECのトラストアンカーは最終的にはルートゾーンのKSKしか存在せず、TLSの証明書のように複数の証明書発行機関が競争にさらされておりかつブラウザベンダーの監視下に置かれているのとは対照的に（監査は存在するけれど）競争のほぼ存在しない唯一のトラストアンカーである、という点が必然的に危うさをはらんでいる、という点はDNSDNS Resolution本文中に触れたとおりです。これが本格的に問題になるとすれば、DNSSECが本来意図した目的を飛び越えた力を持ち出したときでしょう。Against DNSSECと題された記事*3では、特定のゾーンは政府がコントロールしているため実質的にDNSSECは政府が支配権を持つPKIであること、DANE(DNS-based Authentication of Named Entities) とDNSSECを組み合わせると政府は実質的に証明書発行機関と同じ力を持ててしまう、と問題を提起しています。政府とは独立な証明書発行機関があることによってインターネットの検閲から守られているのに、DNSSECがTLS証明書と同じくらいの力を持ったとき、それを台無しにしてしまう恐れがあるといえるでしょう。
性能への影響
DNSSECとRPKIが比較されがちなこととして、「仮にインターネットにあまねくDNSSEC/RPKIが広まった*4場合、インターネットが壊れる」と言われることがあります。現状ではサポートしているクライアントとサーバーが少ないためにパフォーマンス問題が無視できていますが、これが広く使われるようになった場合、すべてのインターネットアクセスでBGPでのルート確定・DNSの名前解決をする際に公開鍵暗号という高コストな演算が走ることになり、現在のインターネットと比べて「安全性」は向上するけれど、パフォーマンスは無視できないほどに落ちることとなります。
まとめ
「で、だからDNSSECをやめろというのか？」
私はDNSSECをやめろというつもりは今のところはありません。DNSSECがあることによってDNSのリソースレコードの値が信頼できるものになる、ということの価値を否定することは私にはできません。本編中に紹介した楕円曲線暗号の導入も含めた運用上の問題があることは事実で、それらの解決を通してインターネットの安全性が少々でもマシになるのならばよいでしょう、という考えです。ただ、DNSSEC反対論者の意見をまるごと無視することはできないと考えていますし、DNSSECを取り巻く議論の偏りについても無視を決め込むことが少なくとも個人名義で執筆する同人誌/記事としては誠実とは思えなかったので*5、本記事にて本編執筆時点での誤りについて言及し、本問題についてある程度光を当てる必要があると感じた次第です。
もちろんDNSSEC反対論者の主張はこれ以外にもあります。"why not dnssec"などで検索すると日本語以外の本問題に関する言及が見つかるでしょう。
DNSSEC vs DNSCurve/DNSCryptについてはもともとDNSDNS Resolution書くときにも「まあRFCになってないんでええやろ」とスキップしたのに加えて、今回の記事以上に調べ物が必要なので改めて勉強してから出直します。
おまけ: サブタイトルの元ネタ解説
PARANOiA RevolutionはDanceDanceRevolution X3 vs 2nd MIXのボス楽曲で、現在シングルプレイモードにあるLv19譜面を持つ6つ*6の楽曲の1つ。PARANOiAシリーズは多くのDDRシリーズで最高難易度を誇る楽曲として君臨し、その集大成とも言えるリミックスである。EXPERT譜面は「すべての過去が譜面になった」*7と称されるように過去のボス楽曲の譜面を部分ごとに引用して貼り合わせた譜面となっている。
サブタイトルとして選択したのはその訳が「偏執狂の革命」であり、ともすれば偏執的な側面もあるanti-DNSSEC陣営の主張を紹介するのにふさわしいと思ったため。セキュリティやトラストなんて、偏執的でないとやってらんないですよ。
ニコニコ大百科の記事が名文なのでそちらもぜひご覧になってください。
