ネットワークワーキンググループ E. Lewis Request for Comments: 3130 NAI Labs 分類: 情報提供 2001年6月 DNSSEC技術の状況に関する覚書 本文書の位置づけ 本文書はインターネットコミュニティに対して情報を提供するものである。 本文書はいかなる種類のインターネット標準も規定していない。本文書の 配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2001). All Rights Reserved. 要旨 本文書はDNSSEC(Domain Name System Security Extensions)ステータス ミーティングのメモである。 1.0 はじめに DNS Security Extensions (DNSSEC)の開発に関与しているグループの ミーティングが、第49回IETFにあわせて行われた。そこでは、現在の試行の 範囲、DNSSECについて質問されている事柄、標準化への草稿(Draft Standard) レベルの定義まで進展させるために、IETFが必要としている事柄等について 議論が行われた。 DNSSEC [RFC2535]は、最新の定義のコアであるRFC2535と共に、長年にわたって 検討中の状態が続いている。DNSSECはDNSEXTとDNSOPという2つのワーキング グループのチャータの一部になっている。ISCのBIND v8.2は仕様の一部を 実装しており、BIND v9は最初の完全な実装となっている。1999年と2000年には、 構想と、最初の実装をテストするために数多くのワークショップが行われた。 しかし、今までのところ、DNSSECは一般に使用されるまでに至っていない。 現在における共通の見解は、DNSSECは 1)重要であり、2)専門用語であり、 3)堅牢であり、4)未完成であるというものである。この技術の正確な状況を 記録し、作業が必要な分野を特定するため、DNSSECに関わっていることが 知られているグループの非公式な会合が第49回IETFにあわせて開催された。 出席者は NLnet Labs、The Foundation for Internet Infrastructure、 RIPE NCC、ARIN、CAIRN (ISI と NAI Labs)、NIST、DISA、RSSAC、 Network Associates、Verisign (COM/NET/ORG TLDs)の代表者たちだった。 Lewis Informational [Page 1] RFC 3130 DNSSEC Status Meeting Report June 2001 このミーティングの議題は、3つの項目から構成されていた。各グループから 現在の研究目標に関する報告が行われた後に、DNSSECについて質問されている 事柄に関する議論が行われた。最後に、標準化への草稿の状態に達することを 目標として、これを実現するために必要な事柄について検討が行われた。 本報告はミーティングの単なる議事録ではなく、サマリである。ここで提供する 情報の一部は、ミーティングの後に出席者と直接コンタクトして得られた ものである。 1.1 「DNSSEC」という用語は何を意味するか? 議論の中で出されたコメントの1つに、DNSSECとは一枚岩のような1つの技術を 指し示すものではない、というものがある。この用語は技術や手法の 「ツールボックス」を指し示すようになっており、適切に使用されれば、 DNSの完全性を改善することができる。この意見をふまえて、DNSSECの幾つかの 部分は他の部分よりも速く発展していると考えることができる。特に、TSIG [RFC2845]はゾーン転送向けに「導入可能」なレベルに確実に到達している。 以下の4つの構成要素は、DNSSECの一部と考えられているものである。RFC2535と 幾つかのサポート文書([RFC3008]のような)で説明される、DNSトラフィックを 電子署名によって保護するという概念は、インターネット規模でデータ転送を 保護するために設計されたものである。あまりスケールしないが、より効率的な TSIGメカニズム[RFC2845]による照会と応答の保護という概念は、ゾーン転送、 DHCPの登録、リゾルバからネームサーバへのその他の種類のトラフィックに 適用可能である。TSIGを使用する効果による安全な動的な更新[RFC3007]は、 DNSSECの一部と考えることができる。最後に、CERTリソースレコード[RFC2538]の 定義は、DNSがセキュリティデータを分配するメカニズムになる能力を与える ものである。 このDNSSECの構成要素の定義は、決して最終的なものではない。正直に言えば、 この定義はいささか不自然な分類である。DNSSECは、今日DNSにおいて行われて いるセキュリティの全てを包含するわけではない。例えば、データはいつ、 どのようにキャッシュされるのかに関する再定義[RFC2181]は、DNSシステムの 堅牢化に大きな役割を果たしている。前の段落で説明した4つの構成要素は、 そのほとんどが一緒にまとまって分類される。なぜなら、それらが相互に 関連しているだけでなく、ほぼ同時期に開発されたからである。 2.0 グループの報告 ミーティングの冒頭は、目標の報告で構成された。その報告を基に、目標達成 のために必要とされる作業との隔たりがないかを確認するために、試行の分類が 行われた。 Lewis Informational [Page 2] RFC 3130 DNSSEC Status Meeting Report June 2001 2.1 NLnet Labs NLnet Labsによる試行は、ccTLD、特に.de(ドイツ)、.nl(オランダ)、 .se(スウェーデン)におけるDNSSECの影響を理解するという方向に向けられ ている。現在までの作業により、ゾーンに対して電子署名とNXTレコードを 適用する問題が研究されている。得られた結論は、巨大なゾーンに署名を行う 場合、たとえそれが「.com」であったとしても、メモリやCPU速度に関する 現実的な問題はないということである。NLnet Labsはこれを更に調査する ために、Verisignとの共同作業を提案している。 NLnet Labsは、TLDレジストリ、レジストラ、レジストラントに向けて、 ルート、TLDと下位レベルのゾーンにおいて、ゾーンの再署名と鍵のロール オーバー等の作業を正確に処理するための手続きを定義し、文書化しようと 試みている。現時点までの結論は、DNSOP Roll Overの提案は、非現実的で あるか、または巨大なTLDではおそらく実装不可能であろうと思われるという ことである。NLnet Labsは、別のKEY+SIGの処理機構に関する草稿を作成 している。その機構では、SIGは対応するゾーンKEYが置かれているゾーンに のみ保存される。この機構はゾーンの再署名のために必要な作業を、2レベル (現在のゾーンと全ての子)から1レベル(現在のゾーン)に減らす。また、鍵の ロールオーバーに必要な作業を3レベル(親、現在のゾーン、全ての子)から 2レベル(親と現在のゾーン)に減らすものである。 2.2 Verisign Verisignのレジストリ事業部門と法人部門は、非常に巨大なゾーンにとって DNSSECが何を意味するかについて調査してきた。調査はハードウェアの観点 からだけではなく、制度上の観点からも行われた。既に商業化されている 委任を提供するサービスとに対して、DNSSECサービスを提供するために何が 必要かについて、彼らは定義しようと試みている。重要な問題は、委任された ゾーンの鍵それぞれについての親の検証である。 2.3 The Foundation for Internet Infrastructure スウェーデンの組織であるFoundation for Internet Infrastructureは、 2つの要素を持つプロジェクトを実施している。1つはDNSSECにおける参加者の 「トポロジ」に向けられたものであり、もう1つはツールの開発一般に 向けられたものである。 研究ではDNSSECを使用時における管理面の問題を調査している。調査される 問題の1つは、DNSSEC使用時に考えられる4つのパーティの相互作用である。 4つのパーティとは、レジストリ、レジストラ、レジストラント、 DNSオペレータである。4つのパーティに属するある1つのエンティティ内部 では、あらゆる組み合わせが発生してもよい。例えば、独自のDNSを 情報技術部門の一部として運用するレジストラントなどが考えられる。 Lewis Informational [Page 3] RFC 3130 DNSSEC Status Meeting Report June 2001 研究のもう1つの部分は、リゾルバで何が起こるのかに目を向けたもの である。目標には、ISAKMPd(IPSECの鍵ネゴシエーションソフトウェア)や 安全なNTP4、電子メール等のDNSSEC対応ツールが含まれる。この試行の一部は sigz.net実験の中で実装されている。これに関する情報はwww.sigz.netにある。 2.4 RSSAC RSSAC (Root Server System Advisory Committee)は、TSIGは価値が高く 導入すべきであるという結論を出している。ただし、導入の予定はない。 DNSSEC技術の残り(TSIG以外)に関しては、新しい特性の影響を、実運用に 導入する前により深く理解する必要がある。現在、実現の可能性が見込まれる テストベッドに関する問題の文書化が行われている。2つの基本的な想定は、 ルートサーバを含むDNSSECテストベッドが望ましいということ、そして、 そのようなテストベッドであれば長期間のテストにも耐え得るだろうという ことである。後者の想定は、複数の独立したレベルのDNS階層において、 繰り返されるゾーン鍵の検証がどのようにして発生するかを理解する必要が あることに基づいている。 2.5 CAIRN CAIRN (Collaborative Advanced Interagency Research Network)は、DARPAを スポンサーとする、共同研究のためのネットワークである。資金提供を受けて いる活動でDNSSECに関連するものは、FMESHDという、Fault-Tolerant Mesh of Trust in DNSSEC (DNSSECにおける耐障害性の高い信頼のメッシュ機構)を 略したものである。この活動の試行は、幾つかのDNSツリーが利用できない場合、 あるいは安全でない場合に、リゾルバの信頼のチェーンを構築する手段を 決定することである。この手段について、早い段階で実現可能なものは、 DNSSECから鍵を取り出すことができるようにSecure Shellを拡張すること である。この活動の一環として、大規模ではないプロバイダのゾーンに おいてDNSSECの使用が実装され、研究が行われている。 2.6 NIST NISTは、DNSSECに関するパフォーマンスの情報を収集している。DNSSECを 採用するにあたってひとつの懸念は、既存のDNSマシン負荷に対して、DNSSECが 更に加える負荷である。この試行が目指すことは、この懸念を定量化し、懸念が 本当なのか憶測なのかを確認することである。 時間的に都合がつくのであれば、(Javaで実装された)ゾーンの完全性を チェックするプログラムを実装する試行が行われる可能性がある。この プログラムは、DNSSEC使用時における誤りを探すためのものである。 基になるコードは存在しているが、(現在の基礎的な部分を超えた)作業が 必要である。 Lewis Informational [Page 4] RFC 3130 DNSSEC Status Meeting Report June 2001 2.7 DISA アメリカ国防情報システム局(U.S Defense Information Systems Agency)は、 DNSSECをBINDに実装するために資金を提供している。特に関心のあるところは、 DNSSECの仕様が正しいこと、BINDがその仕様を遵守すること、そして、BINDが アメリカ国防総省(US Department of Defense)で使用されるオペレーティング システムで利用可能なことを確かめることである。DISAは、この試行を通じて 開発されたコード全てがstock BINDリリースの一部として一般に利用可能に なることを期待している。 2.8 RIPE NCC RIPE NCCは、IPレジストリにおけるDNSSECの影響に目を向けている。 RIPE NCCはDNSSEC導入の調整と支援を計画している。RIPE NCCはヨーロッパ 方面のための地域インターネットレジストリであるため、焦点は逆引きツリー (IPv4のin-addr.arpa)へのDNSSEC導入に絞られる。 2.9 ARIN ARINはin-addr.arpaより下位にある、ARINに委任されたゾーンへの署名に 使用するために、DNSSECを調査している。また、ARINは2000年10月に ワシントンDCで開催されたNANOG 20に続くDNSSECワークショップに参加した。 カリフォルニア州サンディエゴで開催されたIETF 49に続くIPv6 DNSSEC ワークショップにも参加している。更に、ARINはDNSSECを含む様々なDNSの 実験を行い、限定的な実験を行うために、サーバを立ち上げている。 2.10 Network Associates NAIは、tislabs.comゾーンがDNSSEC仕様に従って運用されることを強く 求めている。これは、ISP以外の組織(IPトランジット、IPアドレス分配の サービス、ドメイン名管理サービスのどれも提供しないエンティティ)が 情報技術部門の通常の運用の範囲でDNSSECを使用する例である。 2.11 ip6.int.ドメイン ip6.intドメインに対して権威をもつネームサーバは、その大部分がCERT レコードとTSIGをサポートできるようにアップグレードされる。これが完全に 達成され、提案が承認されたならば、TSIGとCERTレコードが使用されることに なる。それ以上のDNSSEC関連の作業は不明である。 2.12 トポロジに基づくドメイン検索 トポロジに基づくドメイン検索(TBDS: Topology Based Domain Search)は、 DARPAの資金提供を受けている活動であり、インターネットの通信断になった 部分でいかにしてDNSを継続的に動作させるかを調査している。関心のある トピック(このプロジェクトで扱われているか、プロジェクトに関連するかの どちらか)は、分割された鍵、自己署名されたゾーン(鍵)、多重署名 アルゴリズムの使用である。目標は、署名済インフラストラクチャゾーンを 確立し、それによってIPSECやFreeSwanといった活動のための分散CAの設立を 促進することである。 Lewis Informational [Page 5] RFC 3130 DNSSEC Status Meeting Report June 2001 3.0 試行の分類と、不足している事項 着手されつつある試行は、大規模なドメインレジストリからドメイン名 利用者まで、作業エリアの幅広い範囲を対象にしていると思われる。 作業は、実運用に供しているゾーンにおいて進められており(署名、鍵管理)、 (リゾルバにおける)DNSSECで保護されたデータの使用が開始されつつある。 行われた議論から、注意が不足している明確な分野は存在しないことが わかった。しかしながら、幾つかのエリアでは更なる情報のインプットが 必要である。特に、(アプリケーション部門およびIT部門における)DNSSECの 使用に関する情報が求められる。 4.0 DNSSECに向けられた質問 第49回IETFまでの段階で、DNSSECに関する最も差し迫った質問は、「それは 導入可能なものなのか?」というものである。この質問を重要視したため、 ミーティングでは質問のリストが作成され、答えがわかっているか、質問に 対応するために作業が進められているか、どちらの状態なのかを確認した。 4.1 それは導入可能なものなのか?いつ可能になるのか? この質問に対する通例の回答が「今ではない」という状態が続いている。 その時期は常に「およそ1年先」の未来に据えられている。導入可能な段階に 到達するために、1999年春以降、一連のワークショップが開催されている。 現時点においては、より長期間のワークショップが必要であるということが、 以前にも増して明らかになりつつある。全てのワークショップの発表を通して、 プロトコルの仕様を損なうインパクトを持つ問題、実装上の問題の数は増えて いる。このような状況のため、1日ないし2日のワークショップでは、 プロトコルを導入可能な段階にするための支援が徐々に出来なくなって きているのである。 必要なことは、より長期間の試験環境を運用することである。これは おそらく他のイベントとの関連の助けとなり、また継続を前提としたワーク ショップであろう。これにより、時間の経過を必要とする問題、鍵の有効期間 終了等の問題をより適切に評価できるようになる。 セクション1.1で記述し、セクション2においても触れたように、DNSSECの1つの 構成要素であるTSIGは、他の構成要素に比べるとより進展しているものである。 TSIG以外のDNSSEC構成要素はその段階に至っていないにしても、ゾーン転送を 保護するためにTSIGを使用することは、「実行すべき非常に優れたアイデア ステージ」に向けて既に充分に成熟したものである。しかし、ローカル リゾルバと、それらの「デフォルト」再帰的ネームサーバ間のトラフィックを 保護するためにTSIGを使用するには、依然として更なる作業が必要である。 Lewis Informational [Page 6] RFC 3130 DNSSEC Status Meeting Report June 2001 4.2 DNSSECは効果があるか? 正しいアプローチなのか? 現在、提案された作業として、仕様作成のための多くの試行がなされている。 現時点では、仕様の評価に関して幾つかの試行が実施されている。特に、 NXTレコードの価値と、それを置き換え可能なものについて検討がなされて いる。 KEYおよびSIGレコードの価値について、ほとんど議論の余地はないように 思われる。ゾーンの境界をまたぐKEYの検証については依然として幾らかの 研究が必要である。そのような作業が少なくとも予定されている。 4.3クライアントソフトウェアはどのようにDNSSECを使用するか 既存のアプリケーションを採り上げ、アプリケーション機能を実行するために DNSSECを使用させることを目的とした、数多くの試行が存在する。 そのような例の1つに、Secure Shellがある。 DNSSECがオペレーティングシステムにおいて、(POSIXライクな表現で言う ところの)「gethostbyname」や、類似のルーティンで認識されるようになる のはいつか、あるいは認識されるようになるのかどうか、という問題に ついては対応がなされていない。 4.4 残されている問題は何か? 依然としてプロトコルの問題が多少残っている。NXTリソースレコードは、 認証によりデータの存在を否定する手段を提供するために設計された。 問題は、提案されたこの解決方法が、ある見地からみると、問題よりも悪い 状況をもたらす場合があることである。別の提案としては、DNSEXTワーキング グループにおいて検討中のNOリソースレコードがある。現時点では、DNSEXT ワーキンググループは以下の点を検討している。すなわち、データの存在を 認証によって否定する必要があるかどうか。その必要があるとするならば、 (現在使用されている)NXTとNOのどちらがより適しているかということである。 境界が明確になっていない他の課題として、子の署名を親が検証するための メカニズムが挙げられる。このメカニズムに関して、プロトコルの要素は 解決しつつあるが、セクション2で述べた作業によって明示されるように、 運用に関する考察はまだ検討が完了していない。DNSSECの相互の影響は、 標準的なレジストリ-レジストラプロトコルに関する議論の中でも言及 されている。 5.0 標準化への草稿(Draft Standard)への進展 DNSSECに関するIETFの目標は、標準トラック[RFC2026]を通して、文書を 進展させることである。現在、RFC2535は標準化への提唱(Proposed Standard) レベルの第2版という位置づけにある。もう1度、標準化への提唱の段階で版を 重ねる必要がある。その作業に引き続き、次の目標は標準化への草稿となる。 Lewis Informational [Page 7] RFC 3130 DNSSEC Status Meeting Report June 2001 標準化への草稿レベルに移動するためには、2つの主な要件が満たされ なければならない。まず、2つ以上の相互運用可能な実装がなければ ならない。また、充分な量の成功した運用経験がなければならない。 5.1 DNSEXTワーキンググループの活動を経たRFC2535の改訂 DNSEXTワーキンググループは、間もなくRFC2535仕様(と、そのサポート文書) の書き直しを開始する。これは実装と試験の経験を基に、仕様の更新と 明確化を行うことを目指すものである。 5.2 DNSOPワーキンググループの活動に基づく運用文書 DNSOPは引き続き、DNSSECの活動に基づく運用文書のためのフォーラムとなる。 コミュニティは、より多くの文書をこのグループに提供する必要がある。 5.3 相互運用性 DNSSECの相互運用性を立証するということは、DNSSECの作業を実行する際に 異なる2つの実装が相互に作業しあうということを意味しており、それは1つの 問題を提示する。というのも、現在までに、DNSSECに対して厳密に適合する 実装はBINDだけだからである。DNSSECの部分的な実装は他に存在するため、 部分的に相互運用性を立証できる可能性は残されている。 ミーティングでは、掲げられた目標に向けて、18ヶ月以内に2つ目のDNSSEC実装 が必要であることが合意された。会場にいた様々な参加者は、この合意に関して 何ができそうかを調査し始めようと述べた。 6.0 謝辞 以下の方々がミーティングに参加し、またはこの報告書のために文を提供した (順不同)。 Mark Kosters(Network Solutions)、Patrik Faltstrom(Cisco)、Ted Lindgreen、 Miek Gieben(NLnet Labs)、Jaap Akerhuis(SIDN)、Olaf Kolkmann(RIPE NCC)、 Bill Manning、Dan Massey(ISI)、Martin Fredriksson、Hakan Olsson、 Jakob Schlyter(Carlstedt Research & Technology)、Doug Montgomery、 Scott Rose(NIST)、Johan Ihren、Lars-Johan Liman(Autonomica)、 Brian Wellington(Nominum)、Kevin Meynell(CENTR)、Ed Lewis、 Olafur Gudmundsson(NAI Labs) 7.0 IANAに関する考察 本文書は、割り当てられた番号を一切必要としない。 Lewis Informational [Page 8] RFC 3130 DNSSEC Status Meeting Report June 2001 8.0 セキュリティに関する考察 本文書はDNSのセキュリティ拡張の議論であるが、この文書自体はセキュリティ への影響を及ぼさない。セキュリティに関する問題が発生した場合は、 その問題は適切な文書の「セキュリティに関する考察」の項で議論されることに なる。 9.0 参考文献 全てのRFCの文書は、Webブラウザにおいて、URL: ftp://ftp.isi/edu/in-notes/ rfc.txt をリクエストすることによって取り出してよい。ここで、「wxyz」 はRFCの番号である。 [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", July 1997. [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", March 1999. [RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System", March 1999. [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", May 2000. [RFC 3007] Wellington, B., "Secure Domain Name System Dynamic Update", November 2000. [RFC 3008] Wellington, B., "Domain Name System Security Signing Authority", November 2000. 10.0 著者の連絡先 Edward Lewis 3060 Washington Rd (Rte 97) Glenwood, MD 21738 Phone: +1(443)259-2352 EMail: lewis@tislabs.com Lewis Informational [Page 9] RFC 3130 DNSSEC Status Meeting Report June 2001 11.0 著作権表示の全文 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 Editor機能のための資金は現在、Internet Societyによって提供されて いる。 Lewis Informational [Page 10] RFC3130-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/