ネットワークワーキンググループ D. Atkins Request for Comments: 3833 IHTFP Consulting 分類: 情報提供(Informational) R. Austein ISC 2004年8月 DNS(Domain Name System)の脅威分析 Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). 要旨 IETFはこの10年間の大半をDNSセキュリティ拡張(DNSSEC)の開発に費やしてきたが、 DNSSECが防ごうとしている脅威について、これまでに一度も記述していない。 DNSSEC開発に関して様々な問題が指摘されてきたが、この本末転倒状態のために 設計目標が不明確で、DNSSECが設計目標を満たしているか判断することが 困難となっていた。本文書はDNSに対する既知の脅威を文書化することを試みる ものである。またこの作業を通じて、これらの脅威に対する防御手段として DNSSECが有効なツールとして機能する範囲(もしそのようなものがあるのなら)の 推計をあわせて試みる。 1. はじめに IETFにおけるDNSSECに関する組織的な作業で最も早いものは、1993年11月に ヒューストンで開催された第28回IETFミーティングである。ここでDNSワーキング グループのメンバらにより、設計チームの公開ミーティングが開かれた。 このミーティングの成果としてJim Galvinが作成したサマリの中で、我々が 今日知っているDNSSECの大まかな輪郭は既に明確になっている[Galvin93]。 その内容は以下のとおりである。 ・ミーティング参加者の一部は、許可のない相手に対するDNSデータの漏洩を 防ぐことに興味を示したが、設計チームは "DNSデータは「公開されたもの (public)」である" という明示的な決定を行い、データ漏洩に関する全脅威を 明示的にDNSSECの対象範囲外であるとした。 ・ミーティング参加者の一部は、アクセス制御の基盤としてDNSクライアントと サーバの認証に興味を示したが、この作業もDNSSECの本質的な機能の 対象範囲外であるとした。 Atkins & Austein Informational [Page 1] RFC 3833 DNS Threat Analysis August 2004 ・"セキュリティ機能を持たないDNS"への後方互換性および共存は、明示的な 要件として記載された。 ・目標とするセキュリティサービスとして列挙されたものは以下のとおりである。 1)データの完全性保護機能 2)データの出自の認証機能 ・設計チームは、デジタル署名の仕組みが目標とするサービスを支援するだろうと 注記した。 このミーティング後の10年間において、細部に関する多くの決定がされない ままになっている(また幾つかの項目については実装の経験後に再度決定を やり直した)が、基本的なモデルおよび設計目標は変わっていない。 しかし、DNSSECに関して行われた作業のどれもが、DNSSECが防ごうとする攻撃の 種類や、ヒューストンミーティングで作成された目標とするセキュリティサービス 一覧があのようになった理由を詳細に規定しようとしていない。 したがって、我々は1990年に元々はSteve Bellovinによって書かれた文書にまで 立ち返らなければならない。この文書は1995年まで公開されなかったもので、 その理由についてはBellovinがエピローグで説明している[Bellovin95]。 脅威を防ぐよう設計されたプロトコルの作業を開始してから10年も経って、 その脅威に関する分析を文書化するのは少し妙に思われるかもしれないが、 それでもなお、それがこの文書の試みようとしていることである。 遅れても何もしないよりはましなのだから。 本文書は、読者がDNSおよびDNSSECを理解しているものとする。したがって どちらについてもチュートリアルは提供しない。本文書の内容に関連性が高い 文書は以下のとおりである。[RFC1034]、[RFC1035]、[RFC1123]のセクション6.1、 [RFC2181]、[RFC2308]、[RFC2671]、[RFC2845]、[RFC2930]、[RFC3007]、 [RFC2535]。 以下の議論において、本文書は"DNSSEC"という用語をDNSSEC文書で規定された 公開鍵と署名を階層的に使用する仕組みを参照する語として使用する。TKEY およびTSIGについては、これらのチャネルセキュリティ(訳注: データを転送する 経路で安全を確保するアプローチ)も"DNSを安全に保つ"というより大きな問題の 一部であり、したがって全体的な"DNSセキュリティ拡張"の一部ではあるけれども、 本文書では独立した仕組みとして扱う。これは、プロトコルが発展してきた過程 (ゾーン転送やダイナミックアップデート要求のような特定の処理向けに、 より簡素と思われるチャネルセキュリティモデルを導入した)を反映したもので、 恣意的な区別である。おそらくは本文書を将来改訂する際に修正すべきだろう。 Atkins & Austein Informational [Page 2] RFC 3833 DNS Threat Analysis August 2004 2. 既知の脅威 DNSに対する脅威には幾つかのクラスが存在する。その大部分は、より一般的な 問題がDNSにも影響するものだが、少数のものはDNSプロトコル固有のものである。 2.1. パケット傍受攻撃 DNSに対する最も単純な脅威は、様々な形態のパケット傍受である。具体的に、 中間者(monkey-in-the-middle)攻撃や、リクエストを盗聴し、正しい応答の前に 偽造した応答をリゾルバに送りつける攻撃などが挙げられる。 これらのシナリオのいずれの場合においても、攻撃者はリゾルバかサーバの どちらか(通常はリゾルバ)に対して、それ(リゾルバまたはサーバ)が信用する 情報を何でも与えることができる。パケット傍受攻撃は決してDNS固有の問題では ないが、問合わせまたは応答全体を単一の、デジタル署名を持たない、また 暗号化もされないUDPパケットで送信するというDNSの通常の振る舞いが、 共有ネットワーク上またはトランジット(transit)ネットワーク上でパケットを 傍受可能な悪意ある者にとって、これらの攻撃を極めて容易なものにしている。 さらに厄介なことに、攻撃者がDNS問合わせを傍受することが別の攻撃の手段に なっている場合がある。攻撃者は応答を偽造する際に、回答部には正しい情報を 残し、他の部分には問題を引き起こすような何かを組み込む、例えば名前連鎖 攻撃(セクション2.3参照)を仕掛けるかもしれない。 TSIGやIPsecのようなチャネルセキュリティの仕組みを使用してDNSメッセージに 署名したり、IPsecを使用して暗号化することは確かに可能だが、これらは パケット傍受攻撃に対する良い解決策ではないだろう。まず第一に、この アプローチはDNSメッセージ毎に極めて高い処理コストを課すだけでなく、 特定の問い合わせの名前解決に関わる全てのリゾルバ・サーバ等の間で双方向の 信頼関係を確立し維持するために膨大なコストが必要となる。使用頻度の高い ネームサーバ(ルートゾーンのサーバのような)では、このコストは法外に高い ものとなるだろう。しかし、より重要なことは、この設計の土台になっている 信用モデルが誤っていることである。このモデルでは、せいぜいDNSメッセージの ホップバイホップでの完全性検査(*訳注)しか提供できず、DNSデータ生成者 (ゾーン管理者)とDNSデータ利用者(問合わせ発行を行ったアプリケーション)の間の エンドツーエンドの完全性検査は一切提供できないからである。 訳注: ホップバイホップの完全性検査 DNSメッセージまたはデータが複数のコンピュータで中継される場合に、 各中継区間毎に個々に独立して完全性検査を行う方式。 対照的に、DNSSECは(適切に使用されれば)エンドツーエンドのデータ完全性 検査を提供する。したがってDNSの名前検索処理におけるこの種の問題に 対しては遙かに優れた解決策である。 Atkins & Austein Informational [Page 3] RFC 3833 DNS Threat Analysis August 2004 TSIGが有効に機能するのは、DNSプロトコルの特定のクライアントと特定の サーバ間で固有の信頼関係が築かれている限定された状況である。具体的に ゾーン転送やダイナミックアップデートが動作する状況、あるいはDNSSEC署名を それ自身では検証しないリゾルバ(スタブまたは他の形式)とサーバの関係の ような状況が挙げられる。 DNSSECはDNSメッセージヘッダの改ざんに対する保護を提供しないことに 注意してもらいたい。したがって適度に疑い深いリゾルバは、以下の処理を 行わなければならない。 ・DNSSECの署名検証を全て自分自身で行う。 ・当該リゾルバが信頼することを選択したネームサーバ全てに対し、 通信の完全性を保証するためにTSIG(または等価な仕組み)を使用する。 ・パケット傍受(および以下に示す他の手法)を使用した攻撃の可能性に ついては許容する。 2.2, IDおよび問合わせの推測 DNSの大部分はUDP/IP上で使用されるため、攻撃者がトランスポート層の パラメータに一致するパケットを生成することは比較的容易である。 DNSヘッダのIDフィールドは16ビットしかなく、DNSのUDPポート番号は Well-knownである。したがって、任意のクライアントとサーバについて、 IDとクライアントUDPポート番号の組合せは2^32しかない。 これは特に大きな探索範囲というわけではないので、総当たり(brute force)の 探索を防ぐには不十分である。更に、実際はクライアントUDPポート番号とIDは 以前に取得したトラフィックから推測可能である。加えて、(ファイアウォール または他の制限のため)クライアントポート番号を既知の固定した値にすることも 珍しくないので、多くの場合探索空間は2^16よりも小さくなる。 IDの推測だけでは攻撃者が偽データを注入するには不十分だが、リゾルバが 問い合わせるQNAMEおよびQTYPEの知識(または推測)と組み合わせることにより、 リゾルバは偽の応答の注入に対して脆弱になる。 この攻撃はリゾルバの振る舞いを推測することに依存するので、攻撃対象 (victim)が既知の状態であれば攻撃成功の可能性が高くなる。例えば、攻撃対象が 最近リブートした、あるいは攻撃者の何らかの操作により攻撃対象の振る舞いが 影響を受けた、攻撃対象が攻撃者にとって既知の第三者の操作に対して (推測可能な)応答を返した、などが挙げられる。 Atkins & Austein Informational [Page 4] RFC 3833 DNS Threat Analysis August 2004 この攻撃は、攻撃者にとって先に記述した単純なパケット傍受攻撃よりも 困難でもあり、容易でもある。攻撃者が正しく推測できた場合にだけ攻撃が 機能するという面では困難であると言える。一方で、攻撃者がトランジット ネットワークまたは共有ネットワークを必要としない点で容易であるとも言える。 その他の多くの点について、この攻撃はパケット傍受攻撃に似ている。 DNSSEC署名を検証するリゾルバは偽造された応答を検知することができる。 DNSSEC署名検証を自分で行わないリゾルバは、DNSSEC署名検証を行う 再帰ネームサーバ間との通信で完全性を保証するために、TSIGまたは同等の 仕組みを使用すべきである。 2.3. 名前連鎖攻撃 おそらく、DNS固有の脅威の中で最も興味深いものが名前連鎖攻撃だろう。 これは、"キャッシュポイズニング"攻撃と呼ばれることもある、名前に基づく (name-based)より大きな攻撃のサブセットである。名前に基づく攻撃の大半は、 応答メッセージに含まれるRRと元になる問合わせとの関連性を長期に渡り検査する ことにより、その影響を軽減できるが、そのような防御手段は名前連鎖攻撃を 検知できない。基本的な攻撃の亜種も幾つか存在するが、全てに共通している のは、RDATA部(RR表記の右側部分)にDNS名を含むDNS RRを必要とすることである。 (幾つかの事例では、DNS名ではないがDNS名に直接マッピングされる何らかの情報が 使用された)。このようなRRは、少なくとも原理上、攻撃者が偽造データを 攻撃対象のキャッシュに注入する足がかりとなるものであるから、潜在的には DNS名に基づく何らかの決定を妨害するものである。 この種のRRで最も悪い例はCNAME、NS、DNAME RRである。なぜなら、これらのRRは 攻撃対象の問合わせを攻撃者が指定した場所にリダイレクトできるからである。 MXやSRVといったRRは幾らか危険度が低いが、原理上、攻撃者が指定した場所に 向けた付加的な名前検索のトリガーとして使用できる。AまたはAAAAのような アドレスRRはRDATAにDNS名を含まないが、IN-ADDR.ARPAおよびIP6.ARPAのツリーは それぞれIPv4およびIPv6アドレスのDNSエンコーディングを使用してツリー上の 特定の場所を指定するので、これらのレコードタイプも名前連鎖攻撃に 使用することができる。 名前連鎖攻撃の一般的な形態は以下のとおりである。 ・おそらくは攻撃者または第三者の扇動により、攻撃対象が問合わせを発行 する。幾つかの事例では、問合わせと攻撃される名前は関連しない。 (つまり、攻撃者は問合わせを別の名前の偽造情報を注入する手段として 使用する)。 Atkins & Austein Informational [Page 5] RFC 3833 DNS Threat Analysis August 2004 ・攻撃者は、パケット傍受、問合わせの推測、攻撃対象が発行した問い合わせに 回答する過程で(再帰検索時に問い合わされる)正当なネームサーバとなること など、何らかの手段を経て応答を注入する。 ・攻撃者の応答は、攻撃の形態に依存して、RDATA部にDNS名を持つ1つ以上の RRを含む。攻撃の形態とは、攻撃の目標が当該応答の付加情報部(Additional Section)を経由してこれらの名前に関連する偽造データを攻撃対象の キャッシュに注入することであるかもしれないし、次の問い合わせを攻撃者が 指定したサーバへの問合わせにリダイレクトさせること(このようにすることで、 単一の応答で実現するものに比べてより複雑な偽造データを攻撃対象の キャッシュに注入する、あるいは権威部または回答部に偽造データを入れ込む ことでリゾルバの防御をこっそりかいくぐれる可能性を高める)であるかも しれない。 攻撃対象のキャッシュにRRを注入できる攻撃者は誰でも、ほぼ確実に何らかの ダメージを与えることができる。したがって、ここで論じた意味での名前連鎖 攻撃には分類されないキャッシュポイズニング攻撃も存在する。 しかし、名前連鎖攻撃の場合、最初の攻撃と最終的な結果の因果関係は、 他の形態のキャッシュポイズニング攻撃に比べてはるかに複雑である。したがって 名前連鎖攻撃は特別な注意に値する。 名前連鎖攻撃に共通する脅威は、攻撃者が応答メッセージにより、攻撃者が 指定する任意のDNS名に関する情報を注入可能であり、それを利用して攻撃者が より多くの情報を注入できてしまうことにある。当該DNS名のデータに関して 攻撃対象がより良い(正確性が保証された)情報を持たない限り、攻撃対象が この種の攻撃を防ぐことは困難である。 攻撃者が攻撃対象に特定の名前に関する問合わせを発行させることは極めて 容易なので、この種の攻撃は極めて悪質である。例えば、1x1ピクセルの"web bug" (訳注: HTMLメールを誰が見ているかを把握するためにWebページに埋め込まれた 画像。ユーザがHTMLメールを見ると、その画像を取得しようとサーバにアクセス するためユーザーの行動が把握できる)へのリンクを埋め込んだHTMLメールを 攻撃対象に送りつければよい。攻撃対象のメールソフトがそのリンクにアクセス を試みると、攻撃者が指定した名前に対する問合わせが発行される。 DNSSECはこの種の攻撃の(全てかはわからないが)大部分に対して優れた防御手段を 提供するはずである。署名を検証することにより、応答に含まれる名前に関する データについて、それがDNS名前空間において権威を委任されたサーバが本当に 注入したのかをリゾルバが判断できるようになる。より正確に言えば、リゾルバが 判断できることは、データを注入したものは公開鍵と対となる秘密鍵にアクセス していること、またその公開鍵はリゾルバが事前に知識として持っている何らかの 公開鍵を起点として、DNS名前空間で親側から子側を署名で認証するという署名の 連鎖により期待される場所に置かれていることである。 Atkins & Austein Informational [Page 6] RFC 3833 DNS Threat Analysis August 2004 DNSSEC署名はグルーレコードを対象としない。したがってグルーレコードを 使用した名前連鎖攻撃の可能性は依然として残される。しかし、DNSSECを 使用する環境であれば、グルーを一時的に受理しても、同じデータの 署名された権威あるデータを取得し、その署名を検査することで攻撃を検知 することは可能である。 2.4. 信頼するサーバの裏切り パケット傍受攻撃の別の形態として、信頼するサーバが偶然または故意により 信頼できなくなるというものが挙げられる。多くのクライアントマシンはスタブ リゾルバとして設定されており、信頼するサーバを使用して、DNS問合わせ全てを 代行してもらっている。多くの場合、信頼するサーバはユーザが使用するISPが 提供しており、DHCPまたはPPPオプションでその情報が広報される。 偶発的な信頼関係の裏切り(サーバのバグやサーバのセキュリティ侵害等のため)に 加えて、サーバ自身がユーザの期待する回答を返さないよう設定されている場合が ある。その原因はユーザを支援するための誠実な試みである場合もあるし、 当該ISPと第三者間のビジネス関係を強化するような何らかの目標を促進するための 試みである場合もある。 頻繁に旅行する人々が自分の機器を携行し、それらの機器がどこに行っても 同じように動作することを期待する場合、この問題は深刻なものになる。 これらの人々は、使用する機器が現在接続されているネットワーク運用者が 誰か、またはローカルなインフラで使用する中間的な装置が何かに関わらず、 信頼できるDNSサービスを必要とする。 この問題に対する明らかな解決策は、クライアントがより信頼可能なサーバを 選択することだが、現実問題としてクライアントにそのような選択肢は存在 しないかもしれない。多くのネットワーク環境では、クライアントマシンは 限定された再帰ネームサーバ群から使用するサーバを選択することしかできず、 そのどれもがとりたてて信頼できるというわけでもない。極端な事例では、 クライアントマシンの所有者が反復検索を行うリゾルバ(フルリゾルバ)を動作 させたくても、ポートフィルタリングや他の形態のパケット傍受(攻撃)のため、 それができないこともある。以上より、この問題の起源は本質的にDNSプロトコル 攻撃ではないが、この種の信頼するサーバの裏切りはDNSクライアントへの 脅威であり、単に異なる再帰ネームサーバに切り替えることは適切な防御手段には ならない。 DNSプロトコルの観点から厳密に見ると、この種の裏切りとパケット傍受攻撃の 違いは、この場合クライアントが自主的にリクエストを攻撃者に送信したことだけ である。防御手段はパケット傍受攻撃と同じである。すなわち、リゾルバは DNSSEC署名を検証するか、信頼すると決めたサーバとの通信を認証するために TSIG(または等価な仕組み)を使用しなければならない。TSIGの使用それ自体は、 ネームサーバが信頼できることを保証しないことに注意してもらいたい。 TSIGができることは、リゾルバが何らかの理由に基づいて信頼すると決めた ネームサーバと当該リゾルバ間の通信の保護を支援することである。 リゾルバと偽造した回答を返すサーバ間の通信を保護しても特に有用ではない。 Atkins & Austein Informational [Page 7] RFC 3833 DNS Threat Analysis August 2004 また、スタブリゾルバがネームサーバが代行する作業を信頼せず、自身で DNSSEC署名検証を行いたい場合、署名検証を実行するには、必要なDNSSEC公開鍵に 関する独自の知識が必要となることにも注意してもらいたい。 通常、ルートゾーンの公開鍵があれば充分だが、追加の鍵の知識を持つことが 適切な場合がある。 適度に疑い深いリゾルバは常に自分で署名検証を実行しなければならない、 またこの規則はスタブリゾルバにも当てはまるという結論から逃れることは 難しい。 2.5. サービス不能攻撃 あらゆるネットワークサービス(あるいは、ほぼ全ての対話的サービス)と同様に、 DNSはサービス不能攻撃に対して脆弱である。DNSSECはこの攻撃からの保護を 支援しない。実際、署名を検証するリゾルバに関してはこの問題を悪化させる。 署名検証はDNSメッセージ毎の処理コストを増大させることに加えて、場合に よっては問合わせへの回答で必要なメッセージ数を増大させることもあるから である。TSIG(および同様の仕組み)も同じ問題を持っている。 また、DNSサーバはサービス不能攻撃における増幅器(アンプ装置)として使用される リスクが存在する。DNS応答パケットはDNS問合わせパケットよりも非常に大きく なる傾向にあるためである。当然、DNSSECはここでも助けにならない。 2.6. ドメイン名の不在証明 ドメイン名の不在証明に関する論点に関して、多くの議論が行われてきた。 特に重要な論点は、名前の不在を証明したいという要求が存在するのかどうか である。問題は、攻撃者が応答からRRを取り除いた場合、リゾルバはそれを 検知できるようにすべきかどうかということである。 偏執的に疑い深い人々はおくとしても、RRが存在しない場合にその場で失敗する のではなく、別の処理が生じるようなRRタイプ(例えばMXやSRV RRが存在しない 場合、A RRが替わりに使用される)は脅威となる。ほぼ間違いなく、幾つかの 状況ではRRが存在しないこと自体が問題と考えられる。論点は依然として 残される。"この脅威はどの程度深刻なのか"。脅威は明らかに存在する。 偏執的に疑い深い人々は、今日の時点でこの攻撃が発生する尤もなシナリオを 想像できなくても、いつの日かこの問題が主要な新聞の一面に掲載されるだろうと 主張する。これはこのリスクをある程度軽減する必要があることを意味する。 Atkins & Austein Informational [Page 8] RFC 3833 DNS Threat Analysis August 2004 不在証明の仕組みの一部として、ワイルドカードRRの不在を証明する必要があり、 深さ1ラベル以上のゾーンにおいてそのような証明を行うためには複数の独立した ワイルドカードRRの不在証明を必要とすることに注意してもらいたい。 DNSSECは、ゾーン内に存在する権威を持つ名前は何か、その名前に対応付けられた 権威を持つRRタイプは何かを判定できるような仕組みを持つ。DNSSECの保護は グルーレコードのような権威を持たないデータは対象としない。 2.7. ワイルドカード "ワイルドカード"DNS名に対してデータの完全性保護とデータの出自の認証を 提供を行うべきかどうか、行うとすればどのように行うかについて、多くの議論が 行われてきた。概念的に、ワイルドカード名を持つRRは、RFC 1034の セクション4.3.2に記載がある一致規則に応じて、動的にRRを合成するひな形 である。ワイルドカード名の振る舞いを制御する規則には、軽率なゾーン管理者が 間違いに陥る可能性がある幾つかの癖があるのだが、多くのサイトでワイルド カードRR、特にワイルドカードMX RRを頻繁に使用していることは明らかである。 ワイルドカードRRに対して望ましいサービスを提供するために、以下の2つを 行う必要がある。 ・ワイルドカードRR自身の存在を証明する手法を必要とする。 (つまり合成規則が存在することを示す必要がある)。 ・ワイルドカードの使用法を管理する合成規則にしたがうとワイルドカード RRを無意味にしてしまうようなRRが不在であることを証明する手法を必要と する。(つまり、合成規則が適用可能であることを示す必要がある)。 このことにより、ワイルドカードの仕組みが先のセクションで記述した 不在証明の仕組みに依存するようになることに注意してもらいたい。 DNSSECは先に示した仕組みを含み、これにより、ネームサーバが回答を 生成する際にワイルドカード展開を正しく適用したのかどうかをリゾルバが 検証できるようになる。 Atkins & Austein Informational [Page 9] RFC 3833 DNS Threat Analysis August 2004 3. DNSSECの欠点 DNSSECはそれ自体で幾つか問題を抱えている。 ・DNSSECの実装は複雑であり、ゾーンカットにおいては、注意深いコーディングを 必要とするような扱いの難しい処理が幾つか存在する。これまでに実施された テストベッドの実験より、ゾーン設定の些細な誤りや鍵の有効期限切れなど により、DNSSEC対応リゾルバに深刻な問題が生じるので、現在のプロトコルの エラー通知機能では不十分である可能性が指摘されている。 ・DNSSECはDNS応答パケットサイズを著しく増大させる。幾つかある問題の中でも 特にこの問題により、DNSSEC対応サーバはサービス不能攻撃の増幅器として より効果的なものとなってしまう。 ・DNSSECの回答を検証する処理はリゾルバの負荷を増大させる。DNSSEC対応 リゾルバは署名検証を行う必要があり、場合によっては追加の問合わせ発行を 必要とするためである。作業負荷が増大すると、初めに問合わせを生成した DNSクライアントに対して回答を返すまでの時間が増大するので、タイムアウトや 再問合わせを生じさせてしまうこともある。ほぼ間違いなく、現在の多くの DNSクライアントは、DNSSECにより生じるより大きな遅延を抜きに考えても、 遅延に対して非寛容になっている。しかしこの問題は本注記の対象範囲外とする。 ・DNSと同様に、DNSSECの信頼モデルもほぼ完全に階層的である。DNSSECは、 リゾルバがルート以外の公開鍵の情報を特別な追加の情報として保持すること を許容しているが、一般的な場合はルートの鍵が重要なポイントになる。 したがって、ルートから特定の名前を保持するゾーンの間に存在する任意の ゾーンでセキュリティ侵害が生じた場合、その特定の名前が保持するデータの 完全性を保護するというDNSSECの機能は損なわれる。元々の"セキュリティ 機能を持たないDNS"も同じモデルなので、これはDNSSECによって生じた変更点 ではない。 ・ルートにおける鍵のロールオーバーは極めて困難である。これまでに行われた 作業では、ルート鍵をロールオーバーする方法、あるいはルート鍵を初めの 段階でどのように設定するかなどについて適切に規定したものは存在せず、 それに近いものすらない。 ・DNSSECは、署名を検証するリゾルバとDNSSEC署名を生成するものとの間で 緩やかな時刻同期を必要とする。DNSSEC導入以前は、DNSの時間に関連する 処理は全て、"経過時間"または"相対的な時間"しか知らない機器でも 実行することができた。DNSSEC署名の有効期間は"絶対"時間に基づくので、 署名を検証するリゾルバは、署名が有効期限内であるのか有効期限終了 したものなのかを判定するために、ゾーン署名者と同じ絶対時間の概念を 持たなければならない。リゾルバが把握する絶対時間の現在時刻を変更できる 攻撃者は、有効期限切れの署名を使用してリゾルバを騙すことができる。 同様に、ゾーン署名者の把握する絶対時間の現在時刻を変更できる攻撃者は、 ゾーン署名者を騙し、署名者が意図する有効期間とは一致しない署名を 生成させることができる。 Atkins & Austein Informational [Page 10] RFC 3833 DNS Threat Analysis August 2004 ・ゾーン内にワイルドカードRRが存在する前提を置くと、不在証明の仕組みは 大幅に複雑になる。DNSSECの開発に充てられた10年の大半で、この問題は あまり理解されてこなかった。様々な時点で、不在証明の仕組みは完全に 問題ないのか、ゾーン内にワイルドカードが存在しない場合向けに 不在証明の仕組みを最適化する価値があるかどうかなどについて問いかけが あった。しかし、主たる問題はワイルドカードの仕組みそのものに由来する 複雑さなのである。この複雑さにより、おそらくは不在証明を生成または 検査するコードが脆弱になる。しかし、ワイルドカードの使用を完全に 断念するという選択肢は、ワイルドカードが広く使用されている現状を考えても 現実的ではないので、今後もワイルドカードの使用を許容しなければならない。 したがって、現在残された問いかけは、提案される不在証明最適化の仕組みは DNSSECの仕組みを事実上脆弱にしてしまうのかどうか、ということになる。 ・DNSSECを使用しても、セクション2.4で記述した種類の攻撃を克服するのは 容易ではない。この場合、DNSSECを有効に機能させるためには、リゾルバが 特定の分類に属するDNSレコードは署名されているものと期待するように 設定できなければならない。特にDNSSEC初期の普及段階の間、リゾルバが ルートゾーンおよびTLDゾーンが署名されていると期待することが妥当ではない 場合、これを実現するためにはリゾルバを手動で設定する必要がある。 4. 今後の課題 本セクションは、これまでに対象としてこなかったが、更なる研究や付加的な 仕組み、あるいは双方を必要とするような幾つかの課題を列挙する。 4.1. 他のプロトコルとの相互運用 上記の議論は、DNSプロトコルの範囲内における攻撃に集中していた。それが DNSSECが防ごうと意図したものだったからである。しかし、DNSが他の プロトコルと相互運用する場合、その境界にも潜在的な問題が存在する。 4.2. DNSダイナミックアップデートのDNSSEC対応 DNSダイナミックアップデートとDNSSECと組み合わせて運用する場合、数多くの 潜在的な問題が存在する。未署名ゾーンでは、TSIGを使用してクライアントから サーバへの更新を認証することができる。TSIGは大規模な運用には耐えられない (DNSサーバと各TSIGクライアントの間で共通鍵の設定を手動で行う必要があるため) が、DHCPサーバがローカルなDNSサーバを更新するような限定された、または閉じた 環境においてはうまく機能する。 Atkins & Austein Informational [Page 11] RFC 3833 DNS Threat Analysis August 2004 しかし、署名ゾーンに対してダイナミックアップデートの使用を試みる場合、 重大な問題が生じる。TSIGは未署名ゾーンに対する場合と同様に、 クライアントからサーバへの更新を認証するための限定された範囲で使用できる。 しかし、TSIGが保護するのはDNSトランザクションだけであり、データではない。 またTSIGはDNSゾーンには含まれないので、リゾルバはゾーンの変更を検証する ためにTSIGを使用することはできない。これは以下のいずれかの条件を満たす 必要があることを意味する。 a) 更新を発行するクライアントは、サーバに更新データを送信する前に 更新データに署名するために、ゾーン署名鍵にアクセスできなければならない。 b) DNSサーバは更新データに署名するために、オンラインでゾーン署名鍵に アクセスできなければならない。 いずれの場合でも、更新されたゾーンに置かれる署名付RRsetを生成するために、 ゾーン署名鍵が利用できなければならない。ゾーン署名鍵がオンライン上に 存在しなければならない(少なくともオンラインで利用可能でなければならない) という事実は、潜在的なセキュリティ上のリスクである。 ダイナミックアップデートは、ゾーンのSOA RRのSERIALフィールドの更新も 必要とする。この処理は、理論上先に示した2つの条件のいずれかが満たされれば 処理可能だが、現実問題として(a)は極めて脆弱なので、(b)が実行可能な 唯一の仕組みである。 ゾーン内に存在するRRsetについて、誰が、どのRRsetに対して、どのような 変更を行えるのかを記述したポリシーに関して、他の脅威が存在する。 安全なダイナミックアップデートで現在使用されているアクセス制御の仕組みは 極めて限定的である。DNSゾーン情報を更新する多数のクライアントに対し、 それぞれ異なるアクセス手段を要求するような、きめの細かいアクセス制御を する手法は存在しない。例えば、アリスに対してはゾーンに新しくノードを 追加したり既存のノードを変更したりすることは可能だが削除できないようにする 必要がある、ボブに対してはゾーンを削除することは可能だが追加できないように する必要がある、キャロルはノードを追加、削除、変更することは可能だが、 それらはAレコードに限定される必要がある、といったアクセス制御を行うことは できない。 鍵管理問題のスケール特性は、より多くの調査を必要とする重要な懸念事項 である。 4.3. DNSゾーンの複製のDNSSEC対応 先のセクションで記述したように、DNSSECとは本質的に標準的DNS問合わせ プロトコル上で、データの完全性保護サービスとデータの出自の認証サービスを 提供する試みである。[RFC3552]で議論された用語を使用すると、DNSSECは 標準的DNS問合わせプロトコルに"オブジェクトセキュリティ(訳注: データ側で 安全を確保するアプローチ)"を提供する。しかし、DNSゾーン全体を複製する という場合、DNSSECはオブジェクトセキュリティを提供しない。ゾーンは 委任点に未署名のNS RRやグルーレコードを持つためである。 Atkins & Austein Informational [Page 12] RFC 3833 DNS Threat Analysis August 2004 一方で、TSIGを用いたゾーン転送(AXFRまたはIXFR)処理の保護は"チャネル セキュリティ"を提供するが、ゾーン全体に対してオブジェクトセキュリティは 提供しない。ゾーン転送に関する信頼関係は、ネームサーバ管理者がゾーン情報 提供元であるゾーン管理者を信頼するというエンドツーエンドの関係ではなく、 依然としてネームサーバ管理者がゾーン転送元になっているネームサーバの 管理者を信頼するという極めてホップバイホップな関係になっている。 ゾーンに対してオブジェクトセキュリティを提供することはDNSSECの明示的な 設計目標ではなかったので、そのようなサービスの提供が失敗したとしても 驚くにはあたらない。それでもなお、ゾーンに対してオブジェクトセキュリティを 提供することが有用な付加的サービスとなるゾーン複製のシナリオが幾つか 存在する。したがって、これは今後の課題として有望な分野だと思われる。 理論上、既存のDNSSECモデルとの後方互換性を維持したままゾーンに対して オブジェクトセキュリティを提供する拡張を行うことは困難ではないかも しれない。しかし、DNSEXT WGはそのような拡張の望ましさや要件について 議論をしていない。 5. 結論 上記の分析に基づき、DNSSEC拡張は解決が必要な問題を解決するように 思われるので、展開する価値がある。 セキュリティに関する考慮点 本文書全体がDNSのセキュリティに関する考慮点の記述である。著者らは、 DNSSECを展開することで、DNSに対する既存の脅威の全てではないが、 その幾つかについては解決の助けになると信じている。 Acknowledgments This note is based both on previous published works by others and on a number of discussions both public and private over a period of many years, but particular thanks go to Jaap Akkerhuis, Steve Bellovin, Dan Bernstein, Randy Bush, Steve Crocker, Olafur Gudmundsson, Russ Housley, Rip Loomis, Allison Mankin, Paul Mockapetris, Thomas Narten Mans Nilsson, Pekka Savola, Paul Vixie, Xunhua Wang, Atkins & Austein Informational [Page 13] RFC 3833 DNS Threat Analysis August 2004 and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose names and contributions the authors have forgotten, none of whom are responsible for what the authors did with their ideas. As with any work of this nature, the authors of this note acknowledge that we are standing on the toes of those who have gone before us. Readers interested in this subject may also wish to read [Bellovin95], [Schuba93], and [Vixie95]. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999. Atkins & Austein Informational [Page 14] RFC 3833 DNS Threat Analysis August 2004 Informative References [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [Bellovin95] Bellovin, S., "Using the Domain Name System for System Break-Ins", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995. [Galvin93] Design team meeting summary message posted to dns- security@tis.com mailing list by Jim Galvin on 19 November 1993. [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name System Protocol", Master's thesis, Purdue University Department of Computer Sciences, August 1993. [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995. Authors' Addresses Derek Atkins IHTFP Consulting, Inc. 6 Farragut Ave Somerville, MA 02144 USA EMail: derek@ihtfp.com Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA EMail: sra@isc.org Atkins & Austein Informational [Page 15] RFC 3833 DNS Threat Analysis August 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Atkins & Austein Informational [Page 16]