Title: DNSSEC要不要に関する議論 Author(s): 森 健太郎 (kentaro@jprs.co.jp) 藤原 和典 (fujiwara@jprs.co.jp) 神明 達哉 (jinmei@isl.rdc.toshiba.co.jp) Date: 01/28/2005 ■はじめに IETFにおいて長期に亙りプロトコル的検討が行われているDNSSECではある が、そのインターネット実環境への導入は遅々として進んでいない。 ま た、DNSSEC deploymentを考える際に、その導入コストに見合う効果が得 られるのかという基本的な問いに対して、技術コミュニティの中でもコン センサスが得られていない。この状況を鑑み、ここでは、WIDE dns-wgに おける要不要論を対比させる形で内容の改訂・増補を行い、今後同様の議 論が発生した際の足掛かりとなるべく、議論の整理を試みる。 ■議論 (1) コスト対効果の議論 不要論: DNSのresponseが正当であることが判明した際にも、最終的にはその先の アプリケーションレベルでのセキュリティも必要となることがほとんどで ある(https,sshのhost/user鍵による認証など)。また、DNSの偽response による攻撃を受けた場合も、その後の認証が完遂されれば致命的な事態が 防げることも多い。この状況において、deploymentのための労力をかけて までDNSSEC を普及させることが本当に必要であるか? 対応する必要論: 本来セキュリティは一ヶ所だけ固めれば十分であるとは言えない。DNSの セキュリティはDNSのレベルで解決されるのが望ましい。httpsなどによる 解決策は対症療法的であり、社会インフラとして定着したDNSには、自己 のレベルにおいてintegrity検証機能を有するセキュリティ構造が必要で ある。また、PKIではドメイン名空間とは独立の信頼構造を構築するが、 DNSSECでは、上位レジストリ・ドメイン名登録者間のDNS委任構造と信頼 構造が一致するため、信頼構造の構築手順がより簡潔となる。 DNSサーバ実装のDNSSEC対応については、DNSサーバとして最もshareを持 つBINDが対応したことから考えて、かなりの比率のサーバが潜在的に DNSSEC機能を備える状態にまでは普及するだろう。時間と共にサーババー ジョンは自然に置き換わっていくため、このレベルまでのdeploymentコス トは低いと考えられる。但し、サーバ管理者が実際に設定を行うことにつ いては別の問題となる。 rootからTLD(top level domain)(*1)の階層において、DNSSEC化を行うこ とは登録規模が小さく、登録者(TLD)のDNSに関する専門性が高いため、十 分に現実的である。 このphaseへの到達時期を予測することに難しさはあるものの、DNSSEC Deployment Working Group (*2) など、幾つかの関連団体においても deploymentに関する議論が本格化されつつあり、数年以内にrootから多数 もしくは殆んどのTLDへのDNSSEC的委任が達成され(*3)、引き続き一部の TLDがopt-in 形式により、ドメイン名登録者に対してDNSSEC対応したゾー ン委任を開始する(*4)ことが期待される。 この際、TLDレジストリシステムへのDNSSEC機能の導入は、比較的低コス トで実現できるので、TLDがDNSSEC対応した委任を開始することは十分に 可能である。 root、TLD がDNSSEC対応されれば、有志のドメイン名登録者が、DNSSEC運 用を行うことは容易となる。このような経験を蓄積していくことで、 DNSSECは定着していくと考えられる。 (*1) ここではgTLDとccTLDの双方を含む (*2) http://www.sdl.sri.com/other/dnssec/ (*3) 全てのgTLDとローカルポリシーによって対応したccTLD (*4) この段階は、DNSSEC関連ワークショップ "Building a Road Map for DNSSEC Deployment"(NANOG 31 Meeting併設で開催)において分類さ れた4段階のdeployment phase: Isolated - 数個の署名済みゾーンが存在する状態 Sparse - 多くの署名済みゾーンがばらばらに存在する状態 Dense - 多くの署名済みゾーンが密集して存在する状態 Complete - すべてのゾーンが署名済みになった状態 の"Isolated"と"Sparse"の中間に該当すると考えられる 不要論からのコメント: DNSのセキュリティはDNSで行うというのも、全体としては多少状況が改善 されるにすぎない。この改善度合いに対するコスト対効果の検証を行うべ きであり、要はサーバ管理者に移行へのモチベーションを与えられるかで ある。但し、運用できる環境があるならば、試行してみることは検討に値 する。 必要論からのコメント: 潜在的な危機をどう捉えるかは個人差の問題があり、定量的な評価を行い 難い。しかし、世の中の状況を鑑みるに、将来大規模なサイバーテロのよ うなものが現実に行われる可能性を考えることは杞憂ではないだろう。イ ンフラが準備されていなければ、問題発生時に迅速な対応は行われずに、 より大きな被害を生むことになる。たとえば、DNSSECを用いないDNSに対 しては、相手に気づかれずにフィッシング詐欺などの攻撃を効果的に行う ことができる。DNSSEC本格導入によりこの例をはじめとするDNSに対する 攻撃が減少することが考えられ、攻撃者のオプションを減らすという側面 において、この改善は無駄でない。このような意義を認められるサーバ管 理者(*5)にとっては、移行するモチベーションはあるだろう。これは、他 ユーザに何らかの責任を負う可能性のある組織体にとって、セキュリティ 対応の一貫として自己のDNSサーバにおける対応を完了しておくというこ とが、ビジネス上の責任論的な観点から重要な意味を持つためである。ま た、この際、個人的目的で運用されているようなドメイン名の管理者を含 む、すべてのネームサーバ管理者の移行が必要なわけではない。 (*5) 特にroot、TLD、ISP、政府組織、あるいはe-commerceを行っている 企業のネームサーバ管理者を想定する (2) 鍵の配布に関する議論 不要論: DNSSECが有効となるためには、root zone以下の対象となるすべてのzone がDNSSEC的にsecureであることに加え、検証する側ではその最上位zone (理想的にはroot, あるいはその他のtrusted zone)の公開鍵を持つことが 必要となる。 (2-1) 前者に関連し、「secureなzone」の現実的な範囲として想定するも のが広すぎれば非現実的であり、狭すぎれば役に立たないものとなる。 (2-2) 後者に関して、最上位zoneの鍵を配る方法として何を想定するか? その方法は現実的であるか?(不要論(3)にも関連) 対応する必要論: (2-1) TLD直下のドメイン名がDNSSEC的に委任されている状況を選択でき ることを当面の目標とする(この際の前提として、root zone からTLDsへ のsecureな委任については、近い将来に実現されると考える)。この際、 ゾーン以下全てのドメイン名がDNSSEC的に委任されることは必須でない。 deployment的観点からは、secureなドメイン名がクライアント側で検証で きる状況がまず必要であり、3階層の安全性を確保(*6)できれば十分であ るような場合も数多く存在する。 (*6) root, TLDのゾーンがDNSSEC的にsecureな状態で、TLD直下のある委 任先ゾーンがDNSSEC対応した場合を指す (2-2) サーバ証明書+https程度の信頼性で要求を満足すると見做す。具 体的には下記のようなモデルとなる。 現行のサーバ証明書を用いたhttpsでの配布 (これに加えて新聞等の公共媒体にsignatureを公開) IANA -> RIR -> LIR -> userという経路による鍵の配布 IANA -> TLD -> user (ドメイン名登録インターフェースはsecureかつ信頼できるものと見做す) 一般的ユーザは、OSのデフォルト状態を信頼する 鍵更新については、 Microsoft: Windows Update Apple: Software Update FreeBSD: FreeBSD Update など 不要論からのコメント: (2-1) 3階層だけで十分であるかについては判断がつかない。 (2-2) 最上位zone鍵の配布方法案については現実的である。 必要論からのコメント: (2-1) 商用で利用されるドメイン名などは短いものが好まれる傾向がある ため、3階層でも一定の効果が見込めるとの考えだが、定量的根拠はない。 この議論を続けるためにはリサーチが必要となる。いずれにせよ、root - TLD - TLD直下ドメインまでの階層がDNSSEC化されれば、あとはドメイン 名運用者がDNSSEC対応の範囲を決定すればよい。 (3) クライアントに関する議論 不要論: DNSSECのvalidationを行うためには、stub resolverがsignatureの検証を する必要がある。一方で、validationの処理はかなり複雑な上に負荷が高 く、現状ではクライアント側でBIND 9を導入する以外の方法はない。stub resolver 側へのdeployment scenarioとしてはどのような方法を想定して いるのか?それは現実的なものか? 対応する必要論: (2-1)の2階層の安全性が達成できている段階で、大手ISPのキャッシュサー バがroot公開鍵を導入すれば、ISP傘下ユーザはそのTLDのドメインに対し て、DNSSEC的検証を行うことができる。ここでDNSSECが認知され、有用と 判断されるようであれば、各stub resolver実装について、DNSSECへの対 応を行うモチベーションが与えられる。結局はOSベンダが対応しないと stub resplverへの普及は見込めないので、このような有効性の検証が必 要だろう。但し、より効果的な展開のためには、クライアントアプリケー ションから簡単に利用できる上位互換性を持った検証ライブラリルーチン が過渡的に必要となるかもしれない。 不要論からのコメント: この場合、stub resolverと「大手ISPのキャッシュサーバ」の間はsecure であると仮定することになる。これは、実験サービスとして成り立つかも しれないが、現実的に意味があるかについては下記の理由により疑わしい。 a)「大手ISP」の配下にある公衆ネットワーク(例:インターネットカフェ) 内での攻撃は防げない b)「大手ISP」までがsecureなら、「大手ISP」から先における攻撃は比較 的困難なので、DNSSEC非対応でも実用上は問題とならない 必要論からのコメント: a)については、DNSSEC対応したキャッシュサーバに加え、 (1)スタブリゾルバ - キャッシュサーバ間でTSIGを使う (2)キャッシュサーバでなんらかのユーザ認証を行い通信路を暗号化する のいずれかが解決策として考えつくところではあるが、決定的な案という ものは現段階で存在しない。 (4) NSECレコードに関する議論 この件に関してはdns-wgでは詳細に議論されていないものの、DNSSEC deploymentに少なからず影響を与えるものと考えられるため、著者(筆頭) の見解をまとめておく。 NSECレコード問題: DNSSECでは、検索対象名を前後に挟むように連続している名前のゾーンに おける存在を証明することで間接的に対象名の不在を証明するが、この際 に使用するNSECレコードを順に辿れば、ドメイン名などのゾーン内全ての レコードが芋蔓式に入手できるという状況を指す。 NSECレコード問題は存在しないという論拠: DNSのレコードは公開情報であるからゾーン内のドメイン名が検索できる ことに何らの問題も認められない。従って、NSEC2, NSEC3などの検討は時 間の浪費に過ぎない。 NSECレコード問題は存在するという論拠: 現実問題として、多くのTLDはNSECレコード問題を自らのゾーンをDNSSEC 化する際の致命的問題と認識している。1つにはプライバシー的な問題が あり、また1つにはDoS的な問題がある。NSECを導入すれば、検索者はゾー ン内の1つのドメイン名を知っているだけで、全てのドメイン名を知るこ とができる。これによりいわゆる名簿作りが可能となり、SPAMメールやダ イレクト商法等の活動が容易となることは明白である。TLDゾーンにおけ るドメイン名を、一般の企業とその顧客名というアナロジーで捉え直すと、 ドメイン名リストは顧客名簿に類似する。個人情報保護法的観点で、個人 情報ではない個人データが何らかのルールに基づき集合体となった際には 個人情報と見做されるように、公開情報のドメイン名の集合体であるドメ イン名リストは非公開情報と見做すことができる。社会インフラとなった DNSを上流で管理する責務を持つTLDとしては、これを公開情報と見做し、 自ゾーンにおいてSPAM活動を助長する状況を容認することはできない。従っ て、DNSSEC deployment促進のためには、ドメイン名リストを作成するこ とが不可能であるようなNSECに代わるアルゴリズムを導入することが必須 条件である。 ■今後の展開 DNSSECの要不要は議論のみでなく実証すべき段階に差し掛かっていると考 えられる。ここにおいては、rootゾーンにおけるDNSSEC導入の動きに連動 し、TLDにおいてもDNSSEC化をはかり、システムパフォーマンス、その他 DNSSEC導入障壁となり得る問題についての洗い出しとその評価方法を定め た後に、一定期間の検証を行う必要がある。この際の検証ポイントとして、 上述のNSECレコードによるDNSレコードの芋蔓式取得に関する問題も留意 すべきだろう。この実証段階において、各検証ポイントが実運用レベルの 要件をクリアできるとすれば、その時点でDNSSECの本格導入を検討すべき と考えられる。 Copyright Notice Copyright (C) WIDE Project (2005). All Rights Reserved.