HOME >> 情報セキュリティ >> 調査・研究報告書 >> 情報セキュリティ技術動向調査(2008年下期) >> 2 DNSSEC技術動向

情報セキュリティ技術動向調査(2008年下期)

2 DNSSEC技術動向

グレン・マンスフィールド，太田 耕平

1 背景

 　DNSの欠点は1990年にSteve Bellovinによって発見され、論文としてまとめられたが、彼は、その影響の大きさを考慮して発表していなかった。1995年に、その論文[1]が発表されたことによってDNSがシステムへの侵入に悪用できることが明らかになり、より安全なDNSの研究が始まった。
 　最初の「攻撃の実演」は1997年にEugene Kashpureffによってなされた。世界の主要なネームサーバのキャッシュを汚染することで、www.internic.netに対する問い合わせがwww.alternic.netに対するアドレスとして返されることを示し、それが非常に容易であることが明らかにした。
 　その後、1997年1月にRFC 2065 “Domain Name System Security Extensions”が発行され、続いて1999年3月にはRFC 2535が発行されることでDNSSECの準備が整い、最も普及している主要な実装であるBIND9でも実装された。しかし、認証のための鍵配布をどのように実現するかについての問題は大きく、その利用は事実上不可能だった。
 　そのような中、特定の2者間でDNSの登録情報を更新する際の認証技術が提案された。RFC 2845は、DNSサーバに対する更新をクライアントからの認証するためのTransaction Signature（以下、TSIG）を定義し、これによってDNSサーバ間および通常のDNS要求の認証も可能となった。この技術は共通鍵暗号技術とハッシュ関数の暗号技術に基づくセキュアな方法で、DNS更新に対する要求と応答が許可されているエンドポイントを特定し認証する手段を提供している。しかし、このTSIGはDNS全体の問題を解決するDNSSECではない。TSIGはDNSに参加するエンティティ間で個別の認証を提供しているにすぎず、世界中に分散しているDNS全体の問題を解決することができないため、普及もしていない。
 　本来、DNSは、あらゆる要求に対してその発信者に関係なく同じ応答を返すように設計されている。その意味で、すべてのDNSデータは誰からも参照できるものである。したがって、DNSSECは、機密性やアクセス制御リスト、あるいは発信者によって要求を区別するような方法を提供するものではない。
 　その意味で、DNSSECはSSL/TLSなどの認証・暗号化技術とは異なるものであり、DNSが返す情報の正当性を確認するには、それが提供しているサーバの認証ではなく、そのドメイン名が親ドメインによって正しく発行されていることを確認する必要があるのである。このことは木構造をなしているDNS全体を考慮しなければDNS情報の正確さは保証できないことを示している。
 　DNSSECのRFC発行後、4年を経て、IETFは計画を見直し、現在のDNSSEC標準を構成する3つのRFCを発行した。

  •  　RFC 4033, “DNS Security Introduction and Requirements”
  •  　RFC 4034, “Resource Records for DNS Security Extensions”
  •  　RFC 4035, “Protocol Modifications for the DNS Security Extensions”

これらの文書は、様々な問題に断片的に対処したそれ以前のRFCを見直したものである。それらは以下のRFCとなる。：

    RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845および
    RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3007, RFC 3597, RFC 3226.

2 DNSSECプロトコルの概要

 　DNSSECは、クライアントが下記の事項を検証することを可能としている。

  •  　DNS応答の完全性
  •  　DNS応答の正当性

 　これらの検証は、応答の内容が、該当するドメインやリソースレコードがない場合でも同様に必要であり、具体的にはDNSKEY、RRSIGおよびNSECレコードを用いて以下のように実行される。

DNSサーバが特定のレコードに対する要求を受けとったとき：
 　その応答は通常RRセットデータを含んでいる。DNSSECの場合は、その応答にRRセットに対応するRRSIGレコードが追加される。
 　クライアントは、得られた応答からRRセットデータを取り出し、RRSIGレコードの中で参照されているアルゴリズムを利用してRRセットデータのハッシュ値を算出する。
 　次に、クライアントは当該ゾーンに対するDNSKEYレコードを取得し、格納されている公開鍵を利用してRRSIG中のハッシュ値を復号し、RRSIGのハッシュ値を得る。
 　上記の2つのハッシュ値が同じであれば、そのRRセットデータの完全性を確認できる。 正当性を検証するためには、DNSKEYの正当性を確認する必要がある。
 　DNSKEYそのものは、DNSSEC応答の中でadditional sectionに格納されている。このDNSKEYレコードの正当性は、1節で述べたように、その親のゾーンの公開鍵による署名によって検証する。その鍵はさらにその親の鍵で署名される、というようにDNSツリーを遡って信頼点（Trust Anchor）までたどることで検証が完了する。これによってDNSKEYの正当性を検証することが可能となり、この信頼点がDNSツリー上のrootであれば完全で最終的な検証となる。
 　要求に対応するデータがない場合は、サーバはRRSIGレコードに対応するNSEC応答あるいはRR応答を返す。
 　DNSSECではADフラグおよびCDフラグを利用する。ADフラグは、ネームサーバがリゾルバに対してコンテンツが認証されているかどうかを通知可能とする。これはリゾルバがDNSSECを（直接的に）サポートしていないが、そのネームサーバおよび通信を信頼している場合に有用なものとなる。一方のCDフラグは、リゾルバがネームサーバに対して自身がDNSSEC検証を実行可能であり、ネームサーバによるDNSSEC検証が不要であることを通知可能とする。
 　DNSSECではさらにDOフラグを利用する。DO（DNSSEC OK）はEDNS0と呼ばれる拡張DNSで用意されたフラグを利用しており、DNS応答にDNSSECに対応したRRセットデータを含ませるように要求する際に利用される。また、メッセージに複数のRRSIGが含まれることがあるDNSSECでは、512バイトに制限された従来のUDPベースのDNSメッセージは小さすぎる。この問題は同じくEDSN0で導入された最大メッセージサイズを4096バイトとする拡張を利用することで対応できる。

3 DNSSECの技術課題

 　DNSSECによってDNSの応答の安全性を確保できるが、DNSSECの導入にともなう技術およびセキュリティ上の課題がある[2]。

  •  　DNSの応答メッセージのサイズの増大
     　前述のEDNS0で従来の512バイトから4096バイトにまで拡張されている。
     　さらにUDPメッセージのサイズを超えた場合は、TCPにフォールバックする。
  •  　トランザクション数の増加
     　ゾーンの公開鍵を探すためのトランザクションが増加する。
     　またゾーンファイルのサイズが数倍になる。
  •  　必要な処理能力の増大
     　電子署名、およびその検証、鍵管理、鍵更新など、処理量が多くなり、
     　クライアント、サーバ双方とも必要な処理能力が大幅に増大する。
  •  　設定と運用が難しくなる
     　設定ミスや鍵の期限切れなどの問題がおこりやすくなる
  •  　小さな要求が大きな応答を発生させ得る
     　DoSの増幅器となりえる
  •  　鍵更新（Key rollover）
     　特に信頼点をrootゾーンとできるかどうかが運用面での現実的な課題となる
  •  　絶対時間についての仕様
     　時刻同期を必須とすることになる
  •  　NSECレコード
     　ゾーンファイルに内容と構造の記述が必要で、NSEC3レコードは依然検討中

 　普及についても、すでに広く普及した大規模なシステムへの配備となるため、大きな抵抗にあっている。DNSSECが対応しようとしている問題は、通常知られている脆弱性や攻撃などとは性質が異なるため、その価値の説明と理解は容易ではない。また近年までDNSによる攻撃は一般的ではないとされてきた。
 　さらに、部分的な配備が、配備を難しくしてしまうことも問題である。部分的な配備によって、root以外の信頼点が発生し、DNSがシステムとして分断されてしまい、2節で述べた検証の過程もそれぞれの信頼点で分断されてしまうため、クライアントはそれらすべての信頼点の情報を保持する必要がでてくるため、信頼点の管理という新しい問題が発生しています。
 　また、現実的な課題のひとつとしてアプリケーション側の対応の問題がある。DNSSECでの検証が失敗したときのアプリケーションの適切な振舞いは明確になっていない。例えばWindows 7のDNSSECでは、DNSクライアントはクライアント自身のDNSSECの検証に対応していない。クライアントは検証のために自身が利用しているDNSサーバを信頼することになる。これは前述のADフラグを利用した実装例となる。このことのメリットのひとつは、信頼ポイント自体の設定をクライアントが実行する必要はなく、それゆえ多くの手間が省けることであるが、これが適切な方法かどうかはあまり議論されていない。
 　次に上記問題の中でももっとも困難で、本質的な問題のひとつである鍵更新の問題について述べる。

3.1 鍵更新問題（Key rollover）

 　署名に用いられる鍵は定期的に更新される必要がある。DNSのような分散システムではこれは容易ではない。特に信頼点が島状にちらばっている場合は、問題はさらに複雑になる。
 　事故などが無く安全に運用されてきた鍵については自動更新のシナリオもシンプルで、各鍵に利用期限を設定した上で、現在の鍵Knで、更新する新しい鍵Kn+1に署名する。しかし、もし漏洩などの事故によってKnの変更が必要となった場合は、もはや鍵Knが信頼できないため、その方法は使えない。そのためDNSSECは独立した2つの鍵を使う。

(1) DNSKEYレコードで発行され、ゾーンに署名する運用鍵ZSK（Zone Signing Key）
(2) 運用鍵KSKに署名する保証鍵KSK（Key Signing Key）

 　ZSKは、通常のセキュリティレベルで運用される。そしてZSKに事故などがあった場合に利用することになるバックアップ用の鍵がKSKとなる。
 　ここで注意すべきなのはZSKの運用とKSKの重要性である。原理的にすべてのDNS応答に署名することになるため、ZSKは非常に多くのメッセージに対して署名する。このことは鍵が特定されるリスクが高いことを意味しており、ZSKの更新頻度は慎重に検討される必要がある。さらに、そのようなリスクをもつZSKに対して署名するKSKの役割は単なるバックアップを超えて重く、KSKの運用はDNSとは独立に慎重に扱うことが重要となる。しかし、上記のポイントは十分に理解されているとはいないのが現状である。

3.2 DNSSECの運用に関する意識調査

ICANNのccNSOは、2007年6月現在の調査にDNSSECに対する意識調査を実施した[3]。（国レベルおよび世界的なドメインのDNSを運用しているccNSO/wwTLDのメンバーから61％の回答を得ている）

  •  　DNSSECについて知っている 　 　 　 　 　 　　 90%
  •  　運用している 　 　 　 　 　 　 　　　　　 　　　 　　 7%
  •  　試験運用している 　 　 　 　　 　　 　　 　 　 　 　5%
  •  　運用を計画している(技術、情報の成熟待ち) 　85%
  •  　1年以内の運用を計画している 　 　 　 　 　 　 30%
  •  　具体的な計画はない　　　　　　　 　　 　 　 　　 30%
  •  　rootゾーンへの署名を希望 　 　 　　 　 　 　 　84%
  •  　ICANNによる署名を希望　　　　　 　 　 　 　　　65%
     　(残りのうち、2％はICANN以外のNGO, 2%は政府機関による署名を希望)

 　DNS運用の現場では、DNSSECに対する関心、期待は大きいが、現実的な運用面での課題がその普及を妨げていることがわかる

3.3 DNSSECの普及状況

 　DNSSECは期待されたほど普及してはいないが、スウェーデンを中心として、徐々に利用が進んでいる[4]。

  •  　2005年 9月：.se（スウェーデンのルート）がccTLDとして初の署名
  •  　2006年 4月：.ru（ロシア）が署名
  •  　2006年 8月：.pr（プエルトリコ）が署名
  •  　2007年 1月：.bg（ブルガリア）が署名
  •  　2007年 6月：.br（ブラジル）が署名
  •  　2008年 7月：.orgが最初のgTLDとして署名
  •  　2008年 8月：.govが2009年1月に署名することを発表
  •  　2008年 9月：.cz（チェコ）が署名

 　国内では、JPRS（Japan Registry Services）が配備について取り組んでおり、2007年10月のICANN会議のDNSSECワークショップで試験運用とその結果について発表している[5]。
 　2008年11月28日、スウェーデンのトップレベルドメインを管理する.SE (The Internet Infrastructure Foundation)は1,000番目のDNSSEC .se ドメイン（http://www.sormlandsmusikoteater.se/）を登録した[6]。
 　Kaminsky問題が明らかになって以来、DNSSECへの関心は大きくなっている。例えば、郵便電気通信庁や、選挙運営行政などの複数のスウェーデンの公的機関はDNSSECドメインとして署名することを選択しており、他も追随している。また、配備を促進するために.SEは2009年1月からDNSSECのための特別課金を廃止している。
 　2009年1月23日現在、.SEが管理しているDNSSECドメインはさらに増加し、1,563が署名されている。しかし、.SE全体では840,905のドメインが登録されており、最も熱心なスウェーデンでも普及の進行は遅々として進んでいないことがわかる。
 　また、監視サイトSecSpider1 によると、2008年12月29日現在、全世界ではKSKとZSKの両方を配備したDNSSECゾーンは1952運用されており、そのうち1192は.SE配下となっている。世界的にはさらに遅れている。様々な情勢や圧力にも係らず、明らかに配備はうまくいっていないが、2009年1月末には上記のDNSSECゾーンの数は4,071まで急増しており関心は高まっている。

4 配備が遅れている理由

 　その重要性にも係らず、実際の普及が遅れていることの背景にはDNSSECを利用しないことによるリスクと利用したときの利益が明確ではないことが挙げられる。
 　一般的なabc.comやdef.netを運用しているドメインは、安全でないDNSのリスクやDNSSECによる利益を理解していないことが多い。abc.comドメインがハイジャックされると、まずは利用者が影響をうける。しかしabc.comの所有者にとっては、オンラインショッピングサイトのようにその事業がそのユーザからのアクセスに依存する事業を運営していなければ、そのダメージはそれほど深刻ではないかもしれない。
 　一方で、abc.comの利用者は確かに影響をうけるかもしれないが、利用者自身によってできることは多くない。利用者はその安全でないサイトを避けるかもしれないが、実際のところ取りえる選択肢がなく、あるいはそのことに気づきもしないことも多い。 DNSSEC配備問題は、そのセキュリティ上の問題点が、エンドユーザにとっては、深刻にみえないことが多いことが危機感の欠如につながり、結果として積極的に推し進める立場の人が不在である（ように見える）ことである 。

4.1 商業的側面

 　DNSECが、普及しない技術であるとか、あるいは普及するまでは意味がない、といった議論はある。そのため、それが配備されるまで、少なくともバックアップとして、各サイトはクライアントに対してその正当性を示すためのサイト証明書を利用しなければならない。
 　このことは証明書発行機関（CA）にとってはいいビジネスとなっているため、信頼点を提供することのできるCAが、DNSSECに積極的になる理由が希薄になってしまう。最初のケースであるスウェーデンでも、バックアップとして、SSL証明書を認証の手段とした。SSL証明書は、CAによって直接的な収入の手段となるが、.orgのようなトップレベルドメイン（TLD）でのDNSSECの場合には直接的な収入にならないこともDNSSECが進まない理由の一つといえる。
 　しかし、エンドユーザにとっては、どのCAを信頼すべきかについて悩まされるとともに、多くのroot証明書を管理する必要性にせまられており、この傾向が続くと時期にはそれらを管理するのが非常に面倒という状況になる可能性がある。
 　また、多くのサイトでは証明書の購入について財政的、経営的負担をしたくないと考えることもありえる。
 　さらなる要因もある。DNSSECはサイトそのものの認証ではない。DNSSECはDNS名の所有者としてのサイトを認証するのみである。つまり、サイト証明書は、登記簿などによって存在を保障する社会的に広く認知された法的手段があり、CAはそれらの情報を元に証明書を発行できるが、ドメイン名の場合は、そのDNS名を登録・確認できるのは親ドメインのみである。
 　つまり、CAがサイト証明書と同じようにドメイン名を認証するためには、認証したドメインの親ドメインのゾーン管理者にその存在を確認する必要がある。そしてその親ゾーンの存在を確認するためには、さらにその親と次々に確認をとる必要がある。そうやって確認作業をしてはじめてドメイン名を認証することができる。しかしこれはDNSSECがやろうとしていることそのものであり、これを実現することがDNSSEC配備問題の要点であり、ほとんどの部分でもある。
 　結局のところ、ルートゾーンは、まだ署名されておらず、そのためDNSSECは例外的な処理なしには機能していない。そしてCAによる証明書に基づいたエンドポイントの認証も（同じ理由で）機能しない。

4.2 政治的関心

 　ルートゾーンが署名されるとしても、誰が署名するのか、が問題となる。それを実行するものには、巨大な権威と責任が伴う。これは政治的価値と商業的価値につながる。そのため誰が署名するのか、に対する回答にたどり着くのは自然と困難になる。これは別なもめごとにもなる。理想的にはなんらかのNPOがその責を果たすべきだが、現時点ではそれは検討中のひとつの提案にすぎない。多くはAとJのrootサーバを運用するVerisignのような営利企業ではなく、ICANNのような非営利組織を希望している。

5 参考文献

[1] Steven M. Bellovin. “Using the Domain Name System for System Break-ins”, Proceedings of the Fifth Usenix UNIX Security Symposium, June 1995, Salt Lake City, UT,
 　ftp://ftp.research.att.com/dist/smb/dnshack.ps

[2] DNSSEC - The Theory, Geoff Huston, The ISP column,
 　http://www.potaroo.net/papers/isoc/2006-08/dnssec.html

DNSSEC - The Practice, Geoff Huston, The ISP column,
 　http://www.potaroo.net/papers/isoc/2006-09/dnssec2.html

DNSSEC - The Opinion, Geoff Huston, The ISP column,
 　http://www.potaroo.net/papers/isoc/2006-10/dnssec3.html

[3] DNSEC Survey Results,
 　http://ccnso.icann.org/surveys/dnssec-survey-report-2007.pdf

[4] DNSSEC News, DNSSEC Mailinglists, DNSSEC News,
 　http://www.dnssec.net/news

[5] Shinta Sato, Kentaro Mori, A Brief Introduction to JPRS’ DNSSEC Implementation Research for TLD, DNSSEC Workshop - ICANN Los Angeles Oct. 29, 2007,
 　http://losangeles2007.icann.org/files/losangeles/SatoICANN-LA-DNSSEC-shinta-v1.0.pdf

[6] .SE Pressreleases, 1, 000 DNSSEC domains signed,
 　http://www.iis.se/about/press?id=173

  1. SecSpider the DNSSEC Monitoring Project,
     　http://secspider.cs.ucla.edu/islands.html
ページトップへ
目次へ
次へ