ネットワークワーキンググループ E. Lewis Request for Comments: 3090 NAI Labs 分類: 標準化過程 2001年3月 ゾーンステータスに関するDNSセキュリティ拡張の明確化 この文書の位置づけ この文書は、インターネットコミュニティのためにインターネット標準化過程 プロトコルを規定するとともに、改善のための議論や提案を求めるものである。 このプロトコルの標準化の段階と状態については、「Internet Official Protocol Standards」(STD 1)の最新版を参照されたい。この文書の配布は制 限されない。 著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. 要約 保護されたゾーンの定義を提示し、RFC 2535の一部を明確にし更新する。RFC 2535は、保護されるゾーンをアルゴリズムごとに定義する。たとえば、あるゾ ーンはRSA鍵によって保護できるが、DSA鍵によっては保護できない。この文書 はこの点を変更するもので、使用する(または使用しない)鍵アルゴリズムとは 無関係に、保護されるまたは保護されないゾーンを定義する。ゾーンのステー タスの決定をもっと簡単にするために、「実験的に安全(experimentally secure)」というステータスは推奨されなくなった。 1 はじめに DNSゾーンが「保護されている」かどうかという質問は、少なくとも4つのコン テキストで出される。ゾーンの管理者は、DNSSECを使用するためにゾーンを設 定するときに、この質問をする。動的更新サーバは、DNSSEC処理を要求するか もしれない更新要求が到着するときに、この質問をする。委譲するゾーンは、 子のステータスを示すデータを親が入力するときに、この質問を子ゾーンにす る。リゾルバは、ゾーンに属するデータを受け取るときに、この質問をする。 1.1 ゾーンのステータスが重要になるのはいつか ゾーンの管理者は、ゾーンをできるだけ安全なものにするためにはどんな手順 が必要かを決定できるようにならなければならない。DNSとその管理は分散的 性質のため、セキュリティの観点からは個々のゾーンはどれも他のゾーンに左 右される。この文書は、ゾーンを安全なものにする条件を定義する。 Lewis Standards Track [Page 1] RFC 3090 DNS Security Extension on Zone Status March 2001 動的更新を実行するネームサーバは、更新されているゾーンの署名は更新済み データに追加されるかどうかと、適用されたNXTレコード、他の必要な処理につ いて知っていなければならない。この場合、この知識を持つようにネームサー バが設定されていることは考えられるが、データを検査することによってゾー ンのステータスを決定できることは、設定パラメータに取って代わる望ましい 方法である。 委譲するゾーンは、子ゾーンが保護されているかどうかを示すことを要求され る。この要件がなぜ必要かは、リゾルバがゾーンに関する決定をどのように行 うかを見れば分かる(次のパラグラフ)。一言でいえば、親は、子が保護されて いるとみなすべきかを知る必要がある。これは、2つの部分からなる質問であ る。どんな状況の下で親は子ゾーンが安全であるとみなすかと、子が規則に従 うかどうかを親はどのように知るかである。 リゾルバは、ゾーンのデータを処理するときに、そのゾーンが保護されている かを知る必要がある。最終的には、リゾルバは、そのデータをカバーする使用 可能な署名を期待すべきかどうかを知る必要がある。この決定をどのように行 うかはこの文書の範囲外であるが、ただし、一部のケースでは、リゾルバはゾ ーンの親と連絡をとって、子が保護されていると親が表明しているか調べる必 要がある。 1.2 セキュリティの島 DNSSECの目的は、ルートゾーンやトップレベルドメインからリーフゾーンに至 るまでの、階層内の各ゾーンが保護されるようにすることである。保護されて いないDNSの段階(現段階)から完全に保護された -- あるいは「できる限り保護 された」-- ツリーの段階に移行するには、時間がかかる。この間、DNSSECはツ リー内のさまざまな場所で適用されるが、「トップダウン」に適用されるわけ ではかならずしもない。 たとえば、ある瞬間には、ルートゾーンと"test."TLDは保護されているかもし れないが、region1.test.は保護されていないかもしれない。(参考のために、 region2.test.は保護されているとする。)一方、subarea1.region1.test.は、 その委譲とともに、保護状態になるためのプロセスを通過したかもしれない。 ここにおけるジレンマは、subarea1のゾーン鍵に正しく署名することができな いことで、その原因はその親ゾーンであるregion1が保護されていないことで ある。 subarea1.region1.test.より下にある保護された一連のゾーンは、「セキュリ ティの島」という口語的な表現で表される。DNSリゾルバがこの島のデータを 信頼するようになるのは、リゾルバがsubarea1.region1.test. (すなわち、セ キュリティの島のルート)用のゾーン鍵により事前に設定されている場合だけ である。他のリゾルバ(そのように設定されていない)は、この島は保護されて いないと認識する。 Lewis Standards Track [Page 2] RFC 3090 DNS Security Extension on Zone Status March 2001 セキュリティの島は、リゾルバ内で事前に設定された公開鍵を持つ1つのゾーン から始まる。この島の内部にはサブゾーンがあり、これらも保護されている。 島の「底」は、保護されていないゾーンへの委譲によって定義される。ある島 が別の島の上に存在することもある。これは、上側の島の底と下側の保護され た島のルートとの間に、保護されていないゾーンが少なくとも1つ存在すること を意味する。 subarea1.region1.test.とregion2.test.はどちらも、管理スタッフによって、 保護状態に正しく置かれているが、後者だけが -- すべてのDNSSECリゾルバが そのデータを検証できまた検証するという意味で -- 実際に「グローバル」に 保護されている。前者のsubarea1を保護されているとみなすのは、これらのリ ゾルバの一部、すなわち適切に設定されているものだけである。この文書では、 このようなゾーンを、「ローカルに」保護されている、と呼ぶことにする。 RFC 2535には、「認証機関」(subarea1などのゾーン用の公開鍵に署名するエン ティティ)に関する規定がある。このアクティビティを制限する文書[RFC3008] もある。他の文書にどのように記述されていても、リゾルバを正しく設定しな いと、認証機関を使用してsubarea1島のデータを検証することはできないだろ う。 1.2.1 最も近いセキュリティルートの決定 ドメインが与えられた場合に、それが安全かどうかを調べる最初のステップは、 最も近いセキュリティルートを決定することである。最も近いセキュリティ ルートは、セキュリティの島の頂上であり、その名前は、与えられたドメイン と合致する(ルートからの順番で)右端のラベルの数が最も多い。 たとえば、ドメインの名前が"sub.domain.testing.signed.exp.test."で、安全 なルートが"exp.test."、"testing.signed.exp.test."、"not-the-same.xy."の 場合は、2番目が最も近い。共有するラベルの数が、最初の安全なルートは2つ、 2番目は4つ、最後は0だからである。 最も近いものが望まれる理由は、NULL鍵が原因で、危険と誤って認識されるこ とをなくすことである。今の例で考えると、"testing..."と"exp.test."の両方 が安全なルートとしてリストされるのは、"signed.exp.test."が保護されてい ない(NULL鍵を持つ)ことがおそらく原因である。与えられたドメイン(sub...) に"exp.test."から下降し始めるとすると、NULL鍵に遭遇して、sub...には署名 が付いていないと結論することになるだろう。これに対し、"testing..."から 下降する場合には、鍵"domain...."が見つかることから、"sub..."は保護され ていると結論することができる。 注意を要する点は、この例ではゾーンの深さが1ラベルであることと、セキュリ ティの島がオーバーラップしないように設定することが前提とされていること である。明確になるように、与えられた定義は、2つのラベルが合致しても、 "short.xy.test."を"short.xy."の最も近いセキュリティルートとしないように するほうがよい。 Lewis Standards Track [Page 3] RFC 3090 DNS Security Extension on Zone Status March 2001 セキュリティの島がオーバーラップするようにしても、概念的におもしろいア イデアは生まれず、どのようにしてもプロトコルに影響することはない。しか し、プロトコルの実装者は、オーバーラップによってコードがループに陥って いないか、確かめるべきである。セキュリティの島が拡大して、名前空間に占 める領域が増えると、オーバーラップは間違いなく設定上の問題になる。 1.3 子のセキュリティに関する親の表明 この文書の1.1には、「子が保護されていると親が表明する」という記述があ る。これは、かなりの混乱をもたらした。 親に子のステータスを「表明」させることの必要性は、次の観察から生じる。 応答が保護されているかどうかを調べる場合、すなわち、それが「セキュリテ ィの島」からのもので、正しく署名されていることを調べる場合は、そのセキ ュリティの島の(適切な)ルートから始めなければならない。 検査している応答を見つけるには、セキュリティの島の内部のゾーンを通って 下降しなければならないかもしれない。島の信頼されたルートから始めて、1つ 下の次のゾーンに下降する。上側のゾーンを信頼しているので、そのゾーンか ら、1つ下の次のゾーンに関するデータを入手することが必要になる。さもない と、ゾーンをハイジャックできる脆弱な点ができる。保護されているゾーンか ら保護されていないゾーンへトラバースする点に達したときは、セキュリティ の島を離れたことになり、その応答は保護されていないと結論づけることが必 要である。 しかし、RFC 2535のセクション2.3.4にある次の記述は、子について親に何か 「表明」させる必要性と相容れないように思われる。 スーパーゾーンが安全な場合は、どのサブゾーンについても、そのスーパ ーゾーンによって署名されたゾーンKEY RRが存在しなければならない。こ れは通常はサブゾーンに出現し、スーパーゾーンにも含まれるかもしれな い。しかし、セキュリティRRを追加するという目的では変更されることが できないあるいは変更されることがない未保護のサブゾーンの場合は、ス ーパーゾーンが安全であれば、そのサブゾーンが保護されていないと宣言 するKEYは、スーパーゾーンの署名付きでスーパーゾーンに出現しなけれ ばならない。 ここにおける混乱は、RFC 2535では、保護されている親は、何も言わないこと によって、子が保護されていることを表明することである(「～にも～されるか もしれない」は、「～にも～されなければならない」の反対である)。データの 欠如が何かが「保護」されていることを意味するという事実は、直観に反する。 この考えは理論的な状況では許容できるが、操作の状況ではいささか不便だっ た。しかし、何か表明するのに「沈黙」を使用することは、このケースでは実 際はうまく働くため、この定義を変更する十分な必要性はこれまで示されなか った。 Lewis Standards Track [Page 4] RFC 3090 DNS Security Extension on Zone Status March 2001 1.4 RFC 2535への影響 この文書は、RFC 2535の一部を更新するものである。保護されているゾーンの 定義は、このRFCのセクション3.4を更新するものである。セクション3.4は更新 されて、実験的な鍵の定義がなくなり、それらの機能を実現する方法が示され るようになった。またセクション3.1.3が更新され、ゾーン鍵中のプロトコルオ クテットの値が指定されるようになった。 1.5 「しなければならない(MUST)」などのキーワード この文書で使用されるキーワード「しなければならない(MUST)」、「要求され ている(REQUIRED)」、「するほうがよい(SHOULD)」、「推奨される (RECOMMENDED)」、「してもよい(MAY)」は、[RFC 2119]の記述にしたがい解釈 される。現時点では、「しなければならない(MUST)」しかこの文書に使用され ていない。 2 ゾーンのステータス このセクションでは、ゾーンのDNSSECステータスに関する規則を提示する。定 義されているセキュリティレベルは、「グローバル」、「ローカル」、「保護 されていない」の3つである。ゾーンがグローバルに安全なのは、そのゾーンが 最も厳格なDNSSEC処理規則セットに従う場合である。ゾーンがローカルに保護 されるのは、そのゾーンが保護されていることが適切に設定されたリゾルバだ けに分かるように、そのゾーンが設定されている場合である。その他のゾーン はすべて、保護されていない。 注: DNSSEC検証規則を完全に定義する文書は、現時点では存在しない。この文 書の目的のために、ゾーン鍵の検証チェーンは委譲ツリーとルートゾーンまで 類似すると最も厳格な規則に規定されていることが、前提とされている。(2.b 参照。)これは、代替の検証パスを禁止することは意図していない。指針となる 定義を確立することだけが目的である。 以下の用語は、後述する規則での記述の繰り返しを避けるために定義されてい る。 2.a ゾーン署名KEY RR -- フラグフィールドの値が名前タイプについては01 (ゾーン鍵を示す)、鍵タイプについては00または01(データの認証を許可され た鍵を示す)であるKEY RR。(RFC 2535のセクション3.1.2参照。)また、KEY RR のプロトコルオクテット値は、DNSSEC(3)かALL(255)である。 この定義は、ゾーン鍵についてのRFC 2535の定義を更新する。プロトコルフィ ールドはDNSSECかALLという要件は、新しい要件である(セクション3.1.3の変 更)。 2.b オンツリー検査 -- 子の鍵から認識済みセキュリティルートまでの信頼の チェーンを構築するためにリゾルバが使用する、DNSSECにとって意味のある署 名を供給することを、親ゾーンだけが承認される認可モデル。 Lewis Standards Track [Page 5] RFC 3090 DNS Security Extension on Zone Status March 2001 「オンツリー(on-tree)」という用語は、DNSドメインの階層を(上に)たどって 信頼された鍵に到達することを意味し、これは、他の鍵を利用できない場合は、 おそらくルート鍵である。「検査(validation)」という用語は、子のゾーンデ ータに署名するための子の鍵の完全性と認証、認可を証明するための親による デジタル署名を意味する。 2.c オフツリー検査 -- 署名を子のゾーン鍵に対し提供することを親のドメイ ン名以外のドメイン名に許可する認可モデル。この署名により、リゾルバはそ れらの鍵を信頼できるようになる。 2.1 グローバルに保護された(ゾーン) グローバルに保護されたゾーンとは、一言でいえば、アルゴリズムを実装する ための必須アルゴリズム(RFC 2535のセクション3.2)だけを使用して、委譲ツリ ーに似た鍵認証チェーンを信頼する(オンツリー検査)ゾーンのことである。グ ローバルに保護されたゾーンは、以下の規則によって定義される。 2.1.a. ゾーンの頂点はKEY RRセットを持たなければならない。アルゴリズムを 実装するための必須アルゴリズムのゾーン署名KEY RR (2.a)が、そのセット中 に少なくとも1つ存在しなければならない。 2.1.b. ゾーンの頂点のKEY RRセットは、親ゾーンに属するプライベート鍵によ って署名されなければならない。そのプライベート鍵と対をなす公開鍵は、ア ルゴリズムを実装するための必須アルゴリズムのゾーン署名KEY RR (2.a)でな ければならず、親の頂点によって所有されなければならない。 規則に従う署名をゾーンが親ゾーンから取得できない場合は、子ゾーンがグロ ーバルに保護されているとみなすことはできない。唯一の例外はルートゾーン であり、これに関しては親ゾーンは存在しない。 2.1.c. NXTレコードは、ゾーン全体に配置されなければならない。(RFC 2535の セクション2.3.2の明確化。) 注: 現在のNXTレコードはいささか操作しにくい。 この要件は、2つのことが起こる場合は変更を受け入れる。ひとつは、NXTに代 わる機構が定義されること、もうひとつは、代替の方法を使用していることを ゾーンが表示できる手段が定義されることである。 2.1.d. ゾーンに属する資格がある各RRセットは、頂点のKEY RRセット中に存在 する、アルゴリズムを実装するための必須アルゴリズムのゾーン署名KEY RR (2.a)である鍵によって、署名されなければならない。(RFC 2535のセクション 2.3.1の更新。) 前述したように、ルートゾーンは特殊なケースである。ルートゾーンは、ロー カルに保護されるための規則に従う場合には、グローバルに保護されていると みなされる。ただし、規則2.1.a.にも従う(要件を実装するために必要)ことは 例外である。 Lewis Standards Track [Page 6] RFC 3090 DNS Security Extension on Zone Status March 2001 2.2 ローカルに保護された(ゾーン) 「ローカルに」という用語は、特定のゾーンについて設定されるリゾルバだけ が、組織に対し「ローカルな」リゾルバである可能性があることから生まれた。 ローカルに保護されたゾーンは、グローバルに保護されたゾーンに関する規則 に似た規則に従うゾーンである。ただし、次の例外がある。署名鍵(signing key)はアルゴリズムの実装を必要としないかもしれないし、使用中のゾーン鍵 の検証は、委譲ツリーに類似しない検証チェーン(オフツリー検査)に頼るかも しれない。 2.2.a. ゾーンの頂点は、KEY RRセットを持たなければならない。そのセット中 にはゾーン署名KEY RR (2.a)が少なくとも1つ存在しなければならない。 2.2.b. ゾーンの頂点のKEY RRセットは、プライベート鍵によって署名されなけ ればならず、次の2つの副節の一方は真でなければならない。 2.2.b.1 プライベート鍵と対になる公開鍵は、関係するすべてのリゾルバで事 前に設定されなければならない。 2.2.b.2 プライベート鍵と対になる公開鍵は、関係するリゾルバによって承認 されたように、ゾーンの頂点のKEY RRセットを検査する権限を持つゾーン署名 KEY RR (2.a)でなければならない。 この文は、信頼されたサードパーティを使用して鍵を検査するという考えを伝 えようとしている。検査する鍵を所有するドメイン名が親ゾーンでない場合、 ドメイン名はリゾルバが検査を任せる相手を表さなければならない。 2.2.c. NXTレコードは、ゾーン全体に配置されなければならない。注: 2.1.cの 後の議論を参照されたい。 2.2.d. ゾーンに属する資格がある各RRセットは、頂点のKEY RRセット中に存在 する、ゾーン署名KEY RR (2.a)である鍵によって、署名されなければならない。 (RFC 2535のセクション2.3.1の更新。) 2.3 保護されていない(ゾーン) その他のゾーンはすべて、保護されていないゾーンに分類される。このトピッ クに関する後のセクションで定義されているように、これには実験的に安全に なるように設計されたゾーンも含まれる。 Lewis Standards Track [Page 7] RFC 3090 DNS Security Extension on Zone Status March 2001 2.4 まとめ 「グローバルに保護された」、「ローカルに保護された」、「保護されていな い」という呼称は、その中身に基づいてゾーンに付けられるラベルにすぎない。 署名が期待されているかどうかを判定する際、リゾルバはゾーンが保護されて いるまたは保護されていないとみなすだけである。 制限の最も強いDNSSEC検証規則に従うリゾルバは、グローバルに保護されたゾ ーンだけを保護されているとみなし、ローカルに保護されたゾーンも含め、そ の他のゾーンはすべて、保護されていないとみなす。アルゴリズムを実装する ための必須アルゴリズム以外のアルゴリズムを実装するリゾルバのような、そ れほど制限の強くないリゾルバは、ローカルに保護されているゾーンの一部も 保護されているとみなす。 ラベル「グローバル」と「ローカル」の目的は、ゾーンの固有の属性を識別す ることである。これらの言葉が選ばれたのは、DNSセキュリティ拡張を利用する ゾーン管理者が取るアクションを推奨する文書の執筆を支援するためである。 これらの言葉の目的が、DNSセキュリティ規格の遵守の状態を伝えるものでない ことは明らかである。 3 実験的ステータス 実験的に保護されたゾーンの目的は、保護されていないゾーンから保護された ゾーンへの移行を促進することである。この区別は廃止される。 この移行を促進するという目標は、「実験的に安全な」という特別な呼称のス テータスがなくても達成可能である。「実験的に保護された」というステータ スは、「ローカルに保護された」というステータスの特別なケースである。ゾ ーンの管理者は、署名付きのゾーンを公表し、対応する公開鍵を持つ1組のテス トリゾルバを設定することにより、これを達成できる。公開鍵がKEY RR中に公 表されても、親の署名がない限り、リゾルバは署名の処理を知るためにある程 度の事前の設定を必要とする。これにより、実験の範囲内ではゾーンを保護で きるようになるが、一般のインターネット上では依然として、保護されていな いものとして登録される。 4 IANAに関する検討 この文書は、番号割り当て機関に対し何のアクションも要求しないし、何のア クションも推奨しない。 Lewis Standards Track [Page 8] RFC 3090 DNS Security Extension on Zone Status March 2001 5 セキュリティに関する検討 指定されたプロトコルや推奨されたアクションの遵守を強制する手段がなけれ ば、DNSゾーンが「完全に」保護されていると宣言することは不可能である。 DNSを全能と考えて、セキュリティのためにゾーンが正しく設定されていると宣 言できるとしても、また、ルートに至るすべてのゾーンも正しく設定されてい るとしても、予想外の動作をするリゾルバをだまして、不正なデータを正しい と信じ込ませることは可能だろう。ゾーンとリゾルバが規則に従う場合でも、 規則に従わないあるいは破壊された親があれば、運用が中断する可能性がある。 期待できる最善の策は、安全と判定されるように関係者全員が準備を整えるこ とと、セキュリティ事件の原因を直ちに突き止めることができるようにするこ とである。 6 謝辞 保護されたゾーンの定義を改善する必要性は、NIC-SE(.seレジストラ)とCAIRN (DARPAの出資を受けた研究ネットワーク)後援の2つのワークショップや、その 他のワークショップに参加した方々の活動を通して明らかになった。Olafur Gudmundsson氏、Russ Mundy氏、Robert Watson氏、Brian Wellington氏とのそ の後の討論を経て、この文書が生まれた。Roy Arends氏やTed Lindgreen氏を始 めとする方々も、ネームドロッパメーリングリストを通した情報の提供で重要 な貢献をしてくださった。 7 参考文献 [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000. Lewis Standards Track [Page 9] RFC 3090 DNS Security Extension on Zone Status March 2001 10 著者の連絡先 Edward Lewis NAI Labs 3060 Washington Road Glenwood MD 21738 Phone: +1 443 259 2352 EMail: lewis@tislabs.com Lewis Standards Track [Page 10] RFC 3090 DNS Security Extension on Zone Status March 2001 11 著作権表示の全文 Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 謝辞 RFCエディターの職務に対する助成金は、現時点ではInternet Societyによって 提供されている。 Lewis Standards Track [Page 11] RFC3090-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/