「DNS Security Extensions」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
TobeBot (会話 | 投稿記録)
44,822 回編集
m ロボットによる 追加: it:DNSSEC
Nagae (会話 | 投稿記録)
370 回編集
BINDおよびDNSSEC Lookaside Validationに関するリンク追加
40行目: 40行目:


== 対応状況 ==
== 対応状況 ==
DNSを実装するソフトウェアとしては、[[BIND]]がBIND9で対応するなど、DNSSEC対応が進んできている。しかし実際の運用としては、[[2009年]]現在、まだごく一部でしか使われていない。
DNSを実装するソフトウェアとしては、[[BIND]]がBIND9で対応する<ref>{{Cite web
|url=https://www.isc.org/software/bind/dnssec
|title=DNSSEC and BIND
|language=英語
|publisher=Internet Systems Consortium
|accessdate=2009年9月13日
}}</ref>など、DNSSEC対応が進んできている。しかし実際の運用としては、[[2009年]]現在、まだごく一部でしか使われていない。


原因のひとつは、上位ゾーンにおける対応の遅れである。上記のとおりDNSSECの認証チェーンは、ルートゾーンからの委譲関係をたどるようになっている。しかし、[[トップレベルドメイン]]でDNSSECに対応しているのは一部の[[国別コードトップレベルドメイン|ccTLD]]だけという状態が続いていた。上位ゾーンの対応を待たずにDNSSECを導入する手段としてDNSSEC Lookaside Validation（DLV）という暫定手段も提案されているが<ref>{{Cite web
原因のひとつは、上位ゾーンにおける対応の遅れである。上記のとおりDNSSECの認証チェーンは、ルートゾーンからの委譲関係をたどるようになっている。しかし、[[トップレベルドメイン]]でDNSSECに対応しているのは一部の[[国別コードトップレベルドメイン|ccTLD]]だけという状態が続いていた。上位ゾーンの対応を待たずにDNSSECを導入する手段としてDNSSEC Lookaside Validation（DLV）という暫定手段も提案されているが<ref>{{Cite web
94行目: 100行目:
* RFC 4034 - Resource Records for the DNS Security Extensions
* RFC 4034 - Resource Records for the DNS Security Extensions
* RFC 4035 - Protocol Modifications for the DNS Security Extensions
* RFC 4035 - Protocol Modifications for the DNS Security Extensions
* RFC 4431 - The DNSSEC Lookaside Validation (DLV) DNS Resource Record
* RFC 4470 - Minimally Covering NSEC Records and DNSSEC On-line Signing
* RFC 4470 - Minimally Covering NSEC Records and DNSSEC On-line Signing
* RFC 4509 - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
* RFC 4509 - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
* RFC 5074 - DNSSEC Lookaside Validation (DLV)


==外部リンク==
==外部リンク==

2009年9月13日 (日) 00:19時点における版

DNS Security Extensions（略称DNSSEC）は、DNSにおける応答の正当性を保証するための拡張仕様である。サーバとクライアントの双方がこの拡張に対応し、かつ拡張機能を使った形式で該当ドメイン情報が登録されていれば、DNS応答の偽造や改竄を検出することができる。

背景

インターネットで使われている通信プロトコルのTCP/IPは、通信相手を指定するのにIPアドレスを用いる。しかし通常は、ユーザのレベルではホスト名を使い、アプリケーションプログラムが自動的にDNSの問い合わせを発行して、ホスト名に対応するIPアドレスを得ている。もしDNS応答を偽造もしくは改竄することができれば、ユーザの意図とは異なる接続先に誘導することができる。これはDNS偽装と呼ばれる攻撃手法である。

DNSが設計されたのは1983年であり、当時と近年とでは、ネットワークに接続された機器が攻撃を受けるリスクは変化している。今となってはDNSは攻撃に対して安全なプロトコルとは言い難く、問題視されている[1][2]。

概要

DNSSECはドメイン登録情報に電子署名を付加することで、正当な管理者によって生成された応答レコードであること、また応答レコードが改竄されていないことを保証する。

DNSでは、ドメイン登録情報はリソースレコード（Resource Records; RR）の集合として構成される。リソースレコードにはいくつかの型が定義されており、ホスト名に対応するIPv4アドレスの定義にはA、IPv6アドレスにはAAAA、メールの送付先はMXというように使い分けている。DNSSECはリソースレコードの型を追加し、認証に必要な情報を追加のリソースレコードとして扱う。DNSSECに対応していないクライアントは、追加のリソースレコードを無視すれば従来どおり照会できる。

RFC 4034では、host.example.comのAレコードに対する電子署名の具体例として、以下のようなRRSIGレコードを示している。3行目以降が電子署名をBase64表記したものである。 

host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
                               20030220173103 2642 example.com.
                               oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
                               PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
                               B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
                               GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
                               J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

電子署名は具体的には、データのハッシュ値に対して、公開鍵暗号に基づく署名処理を適用した結果の値である。上記の例ではSHA-1およびRSAを使用している（1行目の「5」が使用したアルゴリズムを示す）。認証用の公開鍵は、また別のリソースレコード（DNSKEYレコード）として取得できるが、その鍵の正当性を確認する方法が必要になる。DNSSECは、DNSが持つ階層構造を利用して認証チェーンを構成している。

ドメイン名は全体として巨大な木構造を構成し、照会時は根から順に探索していく。DNSではこの木構造を「ゾーン」の階層構造に分割し、分散管理している。子のドメインが別のゾーンとして管理されている場合、そのゾーンの委譲先となるDNSサーバのホスト名を記述する。クライアントは委譲先のDNSサーバに対して再帰的に照会を行なう。ここでDNSSECは、委譲先のホスト名に加えて、そのゾーンで使われる公開鍵のダイジェスト値を追加のリソースレコード（DSレコード）として提供する。クライアントは委譲先のDNSKEYレコードから公開鍵を取得し、そのダイジェスト値をDSレコードと比較することによって、正当な鍵であるか確認できる。

対応状況

DNSを実装するソフトウェアとしては、BINDがBIND9で対応する[3]など、DNSSEC対応が進んできている。しかし実際の運用としては、2009年現在、まだごく一部でしか使われていない。

原因のひとつは、上位ゾーンにおける対応の遅れである。上記のとおりDNSSECの認証チェーンは、ルートゾーンからの委譲関係をたどるようになっている。しかし、トップレベルドメインでDNSSECに対応しているのは一部のccTLDだけという状態が続いていた。上位ゾーンの対応を待たずにDNSSECを導入する手段としてDNSSEC Lookaside Validation（DLV）という暫定手段も提案されているが[4]、普及していない。

2008年7月のキャッシュポイズニング問題以降、この状況に進展が見られる。2009年6月には.orgドメインがgTLDとしては最初にDNSSECに対応した[5]。.comや.netを管理するVeriSignは、同社の管理するgTLDをすべて2011年までに対応させると宣言している[6][7]。

なお日本のccTLDである.jpドメインは、2010年中の対応を予定している[8]。

脚注

  1. ^ “複数のDNSサーバ製品におけるキャッシュポイズニングの脆弱性”. JPCERT コーディネーションセンター (2008年7月25日). 2009年7月20日閲覧。
  2. ^ 藤原和典，関谷勇司，石原知洋 (2005年1月31日). “WIDE合宿におけるDNS攻撃実験” (PDF). WIDE Project. 2009年7月20日閲覧。
  3. ^ “DNSSEC and BIND” (英語). Internet Systems Consortium. 2009年9月13日閲覧。
  4. ^ “JPCERT/CC REPORT 2008-09-10”. JPCERT コーディネーションセンター (2008年9月10日). 2009年7月20日閲覧。
  5. ^ “.ORG is the First Open Top-Level Domain to be Signed with Domain Name Security Extensions” (英語). Public Interest Registry (2009年6月2日). 2009年7月20日閲覧。
  6. ^ Carolyn Duffy Marsan (2009年2月24日). “VeriSign: We will support DNS security in 2011” (英語). Network World, Inc.. 2009年7月20日閲覧。
  7. ^ “ベリサイン、2年以内に全トップレベル・ドメインでDNSSEC導入へ”. IDG Japan, Inc. (2009年2月25日). 2009年7月20日閲覧。
  8. ^ “JPドメイン名サービスへのDNSSECの導入予定について”. Japan Registry Services Co., Ltd. (2009年7月9日). 2009年7月20日閲覧。

RFC

DNSSECに関するRFCは以下のとおり。

  • RFC 2535 - Domain Name System Security Extensions
  • RFC 3110 - RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
  • RFC 4033 - DNS Security Introduction and Requirements
  • RFC 4034 - Resource Records for the DNS Security Extensions
  • RFC 4035 - Protocol Modifications for the DNS Security Extensions
  • RFC 4431 - The DNSSEC Lookaside Validation (DLV) DNS Resource Record
  • RFC 4470 - Minimally Covering NSEC Records and DNSSEC On-line Signing
  • RFC 4509 - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
  • RFC 5074 - DNSSEC Lookaside Validation (DLV)

外部リンク

「https://ja.wikipedia.org/w/index.php?title=DNS_Security_Extensions&oldid=27925363」から取得