Extensions(略称DNSSEC)は、DNSにおける応答の正当性を保証するための拡張仕様である。サーバとクライアントの双方がこの拡張に対応し、かつ拡張機能を使った形式で該当ドメイン情報が登録されていれば、DNS応答の偽造や改竄を検出することができる。背景[編集]インターネットで使われている通信プロトコルのTCP/IPは、通信相手を指定するのにIPアドレスを用いる。通常は、ユーザのレベルではホスト名を使い、アプリケーションプログラムが自動的にDNSの問い合わせを発行して、ホスト名に対応するIPアドレスを取得・変換している。DNS応答を偽造もしくは改竄することができれば、ユーザの意図とは異なる接続先に誘導することができる。これはDNS偽装と呼ばれる攻撃手法である。DNSが設計されたのは1983年であり、当時と近年とでは、ネットワークに接続された機器が攻撃を受けるリスクは変化している。今となってはDNSは攻撃に対して安全な通信プロトコルとは言い難く、問題視されている[1][2]。概要[編集]DNSSECはドメイン登録情報にデジタル署名を付加することで、正当な管理者によって生成された応答レコードであること、また応答レコードが改竄されていないことを保証する。RR)の集合として構成される。リソースレコードにはいくつかの型が定義されており、ホスト名に対応するIPv4アドレスの定義にはA、IPv6アドレスにはAAAA、メールの送付先はMXというように使い分けている。DNSSECはリソースレコードの型を追加し、認証に必要な情報を追加のリソースレコードとして扱う。DNSSECに対応していないクライアントは、追加のリソースレコードを無視すれば従来どおり照会できる。4034では、host.example.comのAレコードに対するデジタル署名の具体例として、以下のようなRRSIGレコードを示している。3行目以降がデジタル署名をBase64表記したものである。)デジタル署名は具体的には、データのハッシュ値に対して、公開鍵暗号に基づく署名処理を適用した結果の値である。上記の例ではSHA-1およびRSAを使用している(1行目の「5」が使用したアルゴリズムを示す)。認証用の公開鍵は、また別のリソースレコード(DNSKEYレコード)として取得できるが、その鍵の正当性を確認する方法が必要になる。DNSSECは、DNSが持つ階層構造を利用して認証チェーンを構成している。ドメイン名は全体として巨大な木構造を構成し、照会時は根から順に探索していく。DNSではこの木構造を「ゾーン」の階層構造に分割し、分散管理している。子のドメインが別のゾーンとして管理されている場合、そのゾーンの委譲先となるDNSサーバのホスト名を記述する。クライアントは委譲先のDNSサーバに対して再帰的に照会を行なう。ここでDNSSECは、委譲先のホスト名に加えて、そのゾーンで使われる公開鍵のダイジェスト値を追加のリソースレコード(DSレコード)として提供する。クライアントは委譲先のDNSKEYレコードから公開鍵を取得し、そのダイジェスト値をDSレコードと比較することによって、正当な鍵であるか確認できる。対応状況[編集]DNSを実装するソフトウェアとしては、BINDがBIND9で対応する[3]など、DNSSEC対応が進んできている。実際の運用としては、2009年現在、まだごく一部でしか使われていない。原因のひとつは、上位ゾーンにおける対応の遅れである。上記のとおりDNSSECの認証チェーンは、ルートゾーンからの委譲関係をたどるようになっている。トップレベルドメインでDNSSECに対応しているのは一部のccTLDだけという状態が続いていた。Validation(DLV)という暫定手段も提案されているが[4]、普及していない。2008年7月のDNSキャッシュポイズニング問題以降、この状況に進展が見られる。2009年6月には.orgドメインがgTLDとしては最初にDNSSECに対応した[5]。.comや.netを管理するVeriSignは、同社の管理するgTLDをすべて2011年までに対応させると宣言している[6][7][8]。ルートゾーンにも2010年7月までに段階的にDNSSECを導入する計画が立てられた[9]。日本のccTLDである.jpドメインは、2011年1月16日に対応した。ConnectSafe[12]などがDNSSECに対応している。国内においてはIIJ[13]、InfoSphere[14]、SANNET[15]等の事業者が利用者にDNSSEC対応のサービスを提供している。KSKロールオーバー問題[編集]DNSSECにおいて、電子署名の正当性検証に使われる最上位の暗号鍵である「ルートゾーンKSK」を更新する際に、EDNSによるIPフラグメンテーションが発生するほどのサイズの応答データが発生するが、通信設定が対応できていないDNSで通信ができず、DNSSECによる正当性検証ができなくなり、インターネットの利用に問題が発生する。変更を行うことになったために顕在化した問題である。2017/09/19、2017/12/20、2018/01/11から始まる更新では、IPフラグメンテーションが発生しない1280bytesを超える1414~1424Bytesの応答データが発生するために、問題が発生する。Proxyでも問題が発生する可能性があり、インターネットの利用に問題が発生する場合がある。2009年7月20日閲覧。2009年7月20日閲覧。2009年9月13日閲覧。2009年7月20日閲覧。2009年7月20日閲覧。2009年7月20日閲覧。2009年7月20日閲覧。2009年12月23日閲覧。2009年12月23日閲覧。2009年7月20日閲覧。ExtensionsRFC[編集]DNSSECに関するRFCは以下のとおり。レコードの署名ではなく通信路の認証・暗号化によりセキュリティをもたせたプロトコル。(日時は個人設定で未設定ならばUTC)。表示-継承ライセンスの下で利用可能です。追加の条件が適用される場合があります。詳細は利用規約を参照してください。Cookieに関する声明モバイルビュ。