コンテンツにスキップ

DNS Security Extensions

出典: フリー百科事典『ウィキペディア（Wikipedia）』
印刷用ページはサポート対象外です。表示エラーが発生する可能性があります。ブラウザーのブックマークを更新し、印刷にはブラウザーの印刷機能を使用してください。
インターネットセキュリティ
プロトコル
キーマネジメント
アプリケーション層
DNS
インターネット層

DNS Security Extensions（略称 DNSSEC）は、インターネットプロトコル (IP) で使用される Domain Name System (DNS) における応答の正当性を保証するための Internet Engineering Task Force (IETF) による拡張仕様である。サーバとクライアントの双方がこの拡張に対応し、かつ拡張機能を使った形式で該当ドメイン情報が登録されていれば、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 over HTTPS (DoH) / DNS over TLS (DoT) との関係

→「DNS over HTTPS」を参照
→「DNS over TLS」を参照

DNS over HTTPS (DoH)は、リゾルバとのDNSクエリのやり取りをHTTPS上で行う[3]ことで、セキュリティを向上させる。これは RFC 8484 で定義される。DNS over TLS(DoT)は、TLSプロトコルを介してリゾルバとのDNSクエリをやり取りする。効果はDoHと同様である。これらDoH/DoTとDNSSECは競合しない。DNSSECはリゾルバや権威サーバ間のドメイン登録情報のやり取りに電子署名を付加して完全性を担保するものであり、当該登録情報のやり取り自体は平文である。EDNS Client Subnet（英語版）ではロードバランス目的のために、フルリゾルバは端末からのクエリのIPアドレスのサブネットを権威サーバに渡す場合があり、その場合、フルリゾルバと権威サーバの間との間で、端末のサブネットとクエリドメインの組み合わせ情報が、平文で通信される[4]。フルリゾルバと権威サーバ間の通信も暗号化するものはDNSCurveによって実装される。

対応状況

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

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

2008年7月のDNSキャッシュポイズニング問題以降、この状況に進展が見られる。2009年6月には.orgドメインがgTLDとしては最初にDNSSECに対応した[7]。.comや.netを管理するVeriSignは、同社の管理するgTLDをすべて2011年までに対応させると宣言している[8][9][10]。さらにルートゾーンにも2010年7月までに段階的にDNSSECを導入する計画が立てられた[11]。

なお日本のccTLDである.jpドメインは、2011年1月16日に対応した。[12]。

パブリックDNSサービスプロバイダ（英語版）（一般に提供している公開DNSリゾルバ）では、Google Public DNS、Verisign Public DNS[13]、Norton ConnectSafe[14]（終了）などがDNSSECに対応している。

また、国内においてはIIJ[15]、InfoSphere[16]、SANNET[17][リンク切れ]等の事業者が利用者にDNSSEC対応のサービスを提供している。

KSKロールオーバー問題

KSKロールオーバー問題は、DNSSECにおいて、電子署名の正当性検証に使われる最上位の暗号鍵である「ルートゾーンKSK」を更新する際に、EDNSによるIPフラグメンテーションが発生するほどのサイズの応答データが発生するが、通信設定が対応できていないDNSで通信ができず、DNSSECによる正当性検証ができなくなり、インターネットの利用に問題が発生すると予想された問題である。

これは、「ルートゾーンKSK」が2016年まで更新されてこなかったために問題になっていなかったが、2016年10月から2018年3月にかけて、 順次変更を行うことになったために顕在化した問題である。特に2017/09/19、2017/12/20、2018/01/11から始まる更新では、IPフラグメンテーションが発生しない1280bytesを超える1414～1424Bytesの応答データが発生するために、問題が発生すると予想された。

基本的には、DNSの運用責任者がソフトウェアのアップデートや設定変更で対応すべきものであるが、一般消費者向けのルータに内蔵されているDNS Proxyでも問題が発生する可能性があり、インターネットの利用に問題が発生する場合があると予想された。

2019年12月、ASCII.jpによればKSKロールオーバーで大きな問題は報告されなかったと言う[18]。

脚注

[脚注の使い方]
  1. ^ “複数のDNSサーバ製品におけるキャッシュポイズニングの脆弱性”. JPCERT コーディネーションセンター (2008年7月25日). 2009年7月20日閲覧。
  2. ^ 藤原和典，関谷勇司，石原知洋 (2005年1月31日). “WIDE合宿におけるDNS攻撃実験” (PDF). WIDE Project. 2009年7月20日閲覧。
  3. ^ つまり、ポート53を使わずにポート443を使う。
  4. ^ 山口崇徳 (2020). “public DNSとプライバシー”. JANOG45 meeting. 
  5. ^ “DNSSEC and BIND” (英語). Internet Systems Consortium. 2009年9月13日閲覧。
  6. ^ “JPCERT/CC REPORT 2008-09-10”. JPCERT コーディネーションセンター (2008年9月10日). 2009年7月20日閲覧。
  7. ^ “.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日閲覧。
  8. ^ Carolyn Duffy Marsan (2009年2月24日). “VeriSign: We will support DNS security in 2011” (英語). Network World, Inc.. 2009年7月20日閲覧。
  9. ^ “ベリサイン、2年以内に全トップレベル・ドメインでDNSSEC導入へ”. IDG Japan, Inc. (2009年2月25日). 2009年7月20日閲覧。
  10. ^ “VeriSign Announces DNSSEC Deployment Support Plans to Enhance Internet Security” (英語). VeriSign, Inc.. 2009年12月23日閲覧。
  11. ^ “ルートゾーンへのDNSSECの導入と展開”. Japan Registry Services Co., Ltd. (2009年12月16日). 2009年12月23日閲覧。
  12. ^ “JPドメイン名サービスへのDNSSECの導入予定について”. Japan Registry Services Co., Ltd. (2009年7月9日). 2009年7月20日閲覧。
  13. ^ DNSの安定性とセキュリティを提供するベリサインのPublic DNS – ベリサイン
  14. ^ Norton ConnectSafe
  15. ^ “独自開発によるDNSSECの実現 | IIJの技術 | インターネットイニシアティブ（IIJ）”. インターネットイニシアティブ-IIJ. 2021年1月23日閲覧。
  16. ^ “InfoSphere | NTTPCコミュニケーションズ”. www.sphere.ne.jp. 2021年1月23日閲覧。
  17. ^ SANNET ホームページ［DNSSEC］DNS Security Extensions
  18. ^ ASCII. “ICANN会合やルートゾーンKSKロールオーバーなど2019年の「ドメイン名ニュース」 (2/2)”. ASCII.jp. 2021年1月23日閲覧。

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)
  • RFC 5702 - Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC

外部リンク

関連項目

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