JPNICJavaScriptが無効になっています。JavaScriptを有効にしてご利用いただくことで、より快適にご利用いただけます。会員の種類・会費・メリット入会手続情報よくある質問JPNIC会員リスト更新情報イベント情報Q&Aサイトマップアクセス英語ページトップページ>ライブラリ>ニュースレター>バックナンバーオンライン版>No.43スマートフォン表示に切り替えるPC表示に切り替えるニュースレターNo.43/2009年11月発行DNSSEC今回の10分講座は、各TLDが対応を表明するなど導入の機運が高まりつつある、DNSSECについて解説します。DNSの仕組みまずはじめに、DNSではエンドユーザーのPCなど、DNSを利用するクライアントがどのようにドメイン名の情報を得るのか、その流れについて簡単に説明します(図1)。問い合わせ(1)クライアントから、所定のネームサーバに対し、問い合わせを依頼します。具体的には、ドメイン名に関する情報はリソースレコードという形式で管理されているので、www.nic.ad.jpというドメイン名のIPアドレスを知りたい場合にはwww.nic.ad.jpのAレコード(IPアドレスを格納するリソースレコード)を問い合わせます。(2)依頼を受けたネームサーバは、問い合わせ内容を元に、ルートサーバ※1から委任をたどりながら順に問い合わせを行い、目的のドメイン名情報を持つ権威ネームサーバから結果を取得します。(3)依頼を受けたネームサーバは、問い合わせの結果をクライアントへ返答します。キャッシュポイズニングとは問い合わせを処理するネームサーバは、処理の途中で得たドメイン名の情報を、一時的にローカルに保存することができます。この処理をキャッシングと言い、一時保存した情報をキャッシュと言います。クライアントから問い合わせの依頼を受けるネームサーバは、このキャッシュの仕組みを実装していることが多いため、「DNSキャッシュサーバ」とも呼ばれています。DNSキャッシュサーバは、権威ネームサーバへ問い合わせをする際に、“ID”という16ビットの識別子をDNSメッセージ中に指定し、送信します。問い合わせにより得た応答のメッセージ中のIDを確認し、一致している場合には問い合わせに対応する応答であると判断します。IDは16ビット(=65,536通り)しか取り得る値が無く、総当たりでパケットを生成するなどの手段で偽装されてしまう危険性があります。このような偽装により、ホスト名とIPアドレスの対応が本来の情報とは違うものとしてクライアントに伝わってしまった場合、特定のサイトへ到達できなくなったり、攻撃者がコントロールする別のサイトへ誘導されたりする恐れが発生します。randomization)が知られています。本文章で説明するDNSSECも有効な対策となります。キャッシュポイズニングの詳細は、2008年11月に発行したJPNICニュースレターNo.40に掲載した記事をご参照ください。前述のキャッシュポイズニングによる危険は、そもそも正規でないサーバから偽装されたパケットが送信されることによるものですが、DNSSECでは、電子署名の仕組みを基に、DNSキャッシュサーバが問い合わせにより得た応答が、問い合わせた本来の権威ネームサーバからの応答かどうか、パケット内容が改ざんされていないかどうか、さらに、問い合わせたレコードが存在するか否か、を検証することができます。DNSSECでは、公開鍵暗号方式と電子署名の仕組みを応用し、前記の検証を可能としています。そこで、次の節で簡単に、公開鍵暗号方式と電子署名の技術について説明します。秘密鍵および公開鍵と呼ばれる一対の異なる鍵を用います。アルゴリズムの性質上、一方の鍵で暗号化されたメッセージ内容は、対になる他方の鍵を用いた場合には容易に復号可能ですが、該当の鍵無しでの復号は膨大な計算量が必要となることから、暗号を破ることは困難とされています。一方の鍵から他方の鍵を推測することが難しいため、片方の鍵を公開して利用することができます。公開された方の鍵で暗号化されたデータは、公開されない方の鍵でしか復号できません(図2)。される鍵は公開鍵と呼ばれ、公開されない鍵は秘密鍵と呼ばれます。秘密鍵は、性質上その秘密鍵を生成した主体のみにより保持することが期待されます。ここで、ある送信者が秘密鍵で暗号化し発信したメッセージ内容を、公開されている公開鍵で復号できたとき、そのメッセージは確かに秘密鍵の保持者が発信したものだと検証できます。送信者の秘密鍵は、その送信者しか保持し得ないことが期待されるからです。この仕組みを応用して、次に述べる電子署名の技術を実現できます。電子署名ある送信者が送信したいメッセージ内容について、一定のアルゴリズムでハッシュ値※2を求め、その値を秘密鍵で暗号化します。この暗号化されたハッシュ値を「電子署名」と呼びます。送信者は、メッセージ内容とともに、電子署名を受信者に送信します。受信者は、受け取ったメッセージ内容について、同じアルゴリズムでハッシュ値を求めます(α)。電子署名を送信者の公開鍵で復号します(β)。この(α)と(β)の内容を比べたとき、同一であれば、確かに送信者が送信したメッセージであり、改ざんもされていないことがわかります(図3)。何を検証できるようになるのかDNSSECでは電子署名の仕組みを応用し、以下のように検証が実施されます(図4)。図4:DNSSECの仕組み(1)あるゾーンの管理者は、秘密鍵と公開鍵の鍵ペアを作成します。(2)同じくゾーンの管理者は、ゾーン内のリソースレコードを、秘密鍵で署名し、電子署名を作成します。対応する公開鍵を公開し、問い合わせがあった場合に参照できるようにします。(3)このゾーンに対してDNSキャッシュサーバから問い合わせがあった場合、権威ネームサーバは電子署名付きの応答を返します。(4)DNSキャッシュサーバが、この電子署名付きの応答をゾーン管理者による公開鍵で復号できた場合には、そのメッセージは確かに該当ゾーンの管理者が作成したもので、かつ改ざんもされていないことがわかります。このように、DNSSECではDNS応答の出自およびDNS応答の完全性を検証することができます。前述の方法による検証を行うには、ゾーン署名者の公開鍵が、確かにその当人のものであると確証できることが前提になります。公開鍵と電子署名を受け取っただけでは、その内容が真正のものなのか偽のものなのかどうか、判断ができないからです。trust)」と呼ばれる仕組みによって担保できるようになっています。Signer)を送信します。該当する親ゾーンの管理者は、その子ゾーンの管理者から送信されたDSが正しいことを確認し、親ゾーンの秘密鍵で署名をして公開します。従って、あるゾーンについて問い合わせをする際、攻撃により応答が偽装され偽の公開鍵を受け取ったり、また偽の署名がなされたリソースレコードを受け取ったりしたとしても、親ゾーンに登録されている該当ゾーンの公開鍵(DS)が正規のもののままであれば、受け取った公開鍵と親ゾーンの持つDSとが異なることを検知できるので、攻撃者によるなりすましを防ぐことができます。trust)ができます。これがDNSキャッシュサーバ管理者の信頼するゾーンまで行われれば、所定のゾーンに対して連鎖的に検証を行うことができるようになります(図5)現在、ルートゾーンには署名されていませんが、いくつかのTLDが、自身が管理するゾーンの公開鍵を公表しています。追加されたリソースレコードこれまで説明したDNSSECの仕組みを実現するため、追加されたリソースレコードを説明します。DNSKEYゾーンを署名する秘密鍵に対応する公開鍵です。DNSキャッシュサーバはこのDNSKEYに記述されている公開鍵を使用し、署名を検証します(図6)。RRSIGリソースレコードの電子署名です。DNSキャッシュサーバはこのRRSIGに記述されている署名を使用し、問い合わせた本来の権威ネームサーバからの応答かどうか、パケット内容が改ざんされていないかどうか、正当性を検証します(図7)。DSDNSKEYのハッシュ値です。これを親ゾーンに登録することで、前述した信頼の連鎖を形成します(図8)。NSEC存在していないゾーンについて問い合わせがあった場合に、そのゾーンを管理する権威ネームサーバが、不存在との旨の回答に署名するためのリソースレコードです。あるゾーンについての不存在を証明するため、下記の例のようにゾーンを辞書的な順序にソートしたとき、次に位置するゾーンが何になるか、NSECレコードでは示されます(図9)。図9:NSECレコードの例この例では、alfa.example.comの次に辞書的な順序で位置するゾーンは、host.example.comになることが示されています。ここで、beta.example.comのAレコードを問い合わせた場合には、従来のDNSと同様該当レコードが見つからない旨の応答と、それに加えてこのNSECレコードが応答され、alfa.example.comの次にはhost.example.comが位置することが判明しますので、beta.example.comというゾーンは存在しないことを検証できます。NSECレコードは、上述のようにあるゾーンの次に位置するゾーンを示したものであることから、あるゾーンを足がかりに、網羅的にゾーン情報を一通り調べることができます。この行為をzoneenumerationと言います。これにより、不正な利用をされてしまわないか、セキュリティ的な懸念を示す向きがありました。NSEC3NSEC3レコードでは、NSECのように次のゾーン名を直接示すのでなく、そのゾーン名がわからないようにハッシュ関数で計算されたハッシュ値により、ゾーンを示します。enumerationを限定することができます(図10)。図10:NSEC3レコードの例この例では、<0p9mhaveqvm6t7vbl5lop2u3t2rp3tom>は、<example>のハッシュ値です。反対に、<0p9mhaveqvm6t7vbl5lop2u3t2rp3tom>から<example>を導くことは困難となる計算アルゴリズムを使用していますので、zoneenumerationを実施することも困難になります。同じ鍵を長く使い続けると、外部からの解析により暗号が破られるリスクが高まります。秘密鍵が漏洩するリスクを考慮する必要があります。従って、署名に用いられる鍵は、定期的に更新されることがセキュリティ上望ましくなります。いえ、鍵の更新には労力が必要です。本節では、鍵更新にかかる負荷を軽減する仕組みを簡単に説明します。DNSSECでは署名に用いる鍵が2種類あります。SigningKey)ゾーン署名鍵ZSKは、各ゾーンに署名する際に用いられるものとなりますが、その対応する公開鍵がDNSKEYレコードとして公開されますので、外部からの解析にさらされます。ゾーン署名鍵ZSKの更新を比較的頻繁に行うことにより、鍵を解析される危険を減ずることができます。鍵署名鍵KSKは、ゾーン署名鍵ZSKを署名するものです。鍵署名鍵KSKについて公開鍵のハッシュ値を求め、その値をDSとします。親ゾーンには、鍵署名鍵KSKのDSを登録することになります。ゾーンの更新があるたびに親ゾーンにDSを再登録するとなると、更新の負荷が高まりますが、このように鍵を二つに分ける運用をすることで、鍵署名鍵KSKの更新があったときにのみ、親ゾーンにDSを再登録すればよくなります。鍵署名鍵KSKの更新は、長くとも1~2年程度の間隔で行うことが推奨されています。DNSSECの課題DNSSECには、セキュリティが向上する利点がありますが、その導入には下記のように技術的な課題があります。DNS応答パケットサイズの増加DNSSECでは、応答パケットの中に署名情報が加わるため、従来のDNSと比べてパケットサイズが増大します。従来のDNSでUDPを用いる場合は、パケットサイズが512バイトまでと定められていますので、DNSSECを扱う場合には、この制限について対応する必要があります。扱えるパケットサイズを4,096バイトまで増やせる、EDNS0という技術を用いることができますが、さらにこのサイズをも超えてしまった場合およびEDNS0を使用できない場合には、TCPにてメッセージをやりとりすることになります。このようにパケットサイズが増加した場合、該当パケットが通過する回線の帯域幅について、増速が必要となる場合があります。上述のように、DNSSECでは電子署名とその検証が実施されますので、DNSキャッシュサーバ・権威ネームサーバともに負荷が増大します。設備面でCPUやメモリ、ネットワークの帯域幅について配慮する必要があります。ユーザーへのアピールDNSSECについては、DNSサーバ側で対応したとしても、エンドユーザーの利用するブロードバンドルータやOS・アプリケーションなどが対応していなければ、ユーザーには違いが明確になりません。時刻同期DNSSECでは、署名された時刻を検証に用いるため、サーバの時計がずれていると検証に支障を来します。NTPなどの手段を用いて、正確な時刻を保っている必要があります。DS登録あるゾーンにおける権威ネームサーバの管理者は、親ゾーンを管理するDNSサーバにDSを登録することになります。ともに管理工数が増大することになります。署名は有効期限を付して作成されますので、所定のタイミングで再署名する必要があります。現在、「.se」をはじめとしたいくつかのccTLDが、DNSSECのサービスを開始しています。「.jp」においては、2010年中を目処に導入する予定であることが、登録管理組織(レジストリ)である株式会社日本レジストリサービス(JPRS)よりアナウンスされました。gTLDにおいても、「.org」や「.gov」がDNSSECの導入を開始しています。NCCが既に2005年よりDNSSECのサービスを開始しており、ARINは2009年7月より試験運用を開始しました。APNICでは、2010年中に実験を開始する予定です。JPNICにおいても、APNICおよび各NIRの動向を踏まえ、対応を検討しています。「ルートゾーン」を管理するネームサーバです。ハッシュ値ある数値からハッシュ関数と呼ばれる計算方法によって求められる数値です。同じ数値について計算した場合、得られるハッシュ値は決まったものになります。トピックスとお知らせ一覧2020年2019年2018年2017年2016年2015年2014年2013年2012年2011年2010年2009年2008年2007年2006年2005年2004年2003年2002年2001年2000年1999年1998年1997年Web更新履歴一覧2020年の更新履歴2019年の更新履歴2018年の更新履歴2017年の更新履歴2016年の更新履歴2015年の更新履歴2014年の更新履歴2013年の更新履歴2012年の更新履歴2011年の更新履歴2010年の更新履歴2009年の更新履歴2008年の更新履歴2007年の更新履歴2006年の更新履歴2005年の更新履歴2004年の更新履歴2003年の更新履歴2002年の更新履歴Q&AIPアドレスWHOIS/DBJPNIC認証局ドメイン名ニュースレター/メールマガジン会員JPNICについて統計よくある質問イベントカレンダー2020年2019年2018年2017年2016年2015年2014年2013年2012年2011年2010年2009年2008年2007年2006年2005年2004年2003年2002年2001年2000年1999年1998年1997年1996年1995年1994年1993年WHOISGateway表示例このページを評価してくださいこのWebページは役に立ちましたか?役に立った役に立たなかったどちらとも言えないページの改良点等がございましたら自由にご記入ください。回答を差し上げられません。回答が必要な場合は、お問い合わせ先をご利用ください。Views)登録パスワードが記載された確認メールが発送されます。再度ご登録手続きを行ってください。Views)登録パスワードが記載された確認メールが発送されます。再度ご登録手続きを行ってください。