Network Working Group E. Lewis
Request for Comments: 3130 NAI Labs
Category: Informational June 2001
Notes from the State-Of-The-Technology: DNSSEC
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting.
これは、DNSSEC（ドメインネームシステムセキュリティ拡張）ステータスミーティングのメモです。
A meeting of groups involved in the development of the DNS Security Extensions (DNSSEC) was held in conjunction with the 49th IETF. The discussion covered the extent of current efforts, a discussion of what questions are being asked of DNSSEC, and what is needed by the IETF to progress the definition to the Draft Standard level.
DNSセキュリティ拡張機能（DNSSEC）の開発に携わるグループの会議が第49回IETFと連携して開催されました。議論は現在の努力の範囲をカバーし、質問がDNSSECの聞くと、どのようなドラフト標準レベルに定義を進めるためにIETFによって必要とされているかについての議論。
DNSSEC [RFC 2535] has been under consideration for quite a few years, with RFC 2535 being the core of the most recent definition. DNSSEC is part of the charter of two working groups, DNSEXT and DNSOP. ISC's BIND v8.2 implemented part of the specification, BIND v9 represents the first full implementation. In 1999 and 2000, more than a half dozen workshops have been held to test the concepts and the earliest versions of implementations. But to date, DNSSEC is not in common use.
DNSSEC [RFC 2535]はRFC 2535は、最新の定義のコアであることで、かなりの数年間のために検討されています。 DNSSECは、2つの作業グループ、DNSEXTとDNSOPのチャーターの一部です。 ISCのBINDのV8.2は、BINDのV9が最初の完全な実装を表し、明細書の一部を実施しました。 1999年と2000年には、以上の半ダースのワークショップは、概念と実装の最初のバージョンをテストするために開催されています。しかし、現在までに、DNSSECは、一般的に使用されていません。
The current collective wisdom is that DNSSEC is 1) important, 2) a buzzword, 3) hard, 4) immature. To capture the true state of the technology and identify where work is needed, an informal gathering of groups known to be involved in DNSSEC was held in conjunction with the 49th IETF. The attendees represented NLnet Labs, The Foundation for Internet Infrastructure, RIPE NCC, ARIN, CAIRN (ISI and NAI Labs), NIST, DISA, RSSAC, Network Associates and Verisign (COM/NET/ORG TLDs).
現在の集団の知恵はDNSSEC 1）重要な、2）流行語、3）ハード、4）未成熟であることです。技術の真の状態をキャプチャし、作業が必要とされている場所を特定するには、DNSSECに関与することが知られているグループの非公式の集まりは、第49回IETFと連携して開催されました。参加者はNLnet Labs社、インターネットインフラのための財団、RIPE NCC、ARIN、CAIRN（ISIとNAI Labs社）、NIST、DISA、RSSAC、ネットワークアソシエイツとベリサイン（COM / NET / ORGのTLD）で表されます。
The agenda of the meeting consisted of three items. Reports from each group on their current research goals were followed by a discussion of questions being asked of DNSSEC. Finally, with reaching Draft Standard status as a goal, what was needed to make this happen was considered.
会議の議題は3つの項目で構成されていました。彼らの現在の研究目標に、各グループからのレポートは、DNSSECの求められている質問の議論が続きました。最後に、目標としてドラフト標準状態に達して、何これを実現するために必要だったことは考えられていました。
This report is not simply a transcript of the meeting, it is a summary. Some of the information presented here was obtained in direct contact with participants after the meeting.
このレポートは、それが要約され、単に会議の転写産物ではありません。ここで提示された情報の一部は会議の後、参加者と直接接触して得ました。
One of the comments made during discussions is that DNSSEC does not refer to just one monolithic technology. The term has come to refer to "toolbox" of techniques and methodologies, that when used properly can improve the integrity of the DNS. Given this observation, it can be seen that some portions of DNSSEC are evolving much more rapidly than other portions. In particular, TSIG [RFC 2845] has certainly reached a level "being deployable" for zone transfers.
議論の中に作られたコメントの一つは、DNSSECはただ1つのモノリシック技術を参照していないということです。用語は、適切に使用するDNSの整合性を向上させることができ、技術や方法論の「ツールボックス」を参照するようになってきました。この観察を考えると、DNSSECのいくつかの部分がはるかに急速に他の部分よりも進化していることがわかります。特に、TSIG [RFC 2845]は確かにゾーン転送のための「展開さ」レベルに達しています。
The following four components are considered to be part of DNSSEC. The concept of digital signature protection of DNS traffic as described in RFC 2535 and a few support documents (such as [RFC 3008]), which is designed to protect the transfer of data on an Internet scale. The concept of protecting queries and responses through the less-scalable but more efficient TSIG mechanism [RFC 2845], which has applicability to zone transfers, DHCP registrations, and other resolver to name server traffic. Secure dynamic updates [RFC 3007], by virtue of using TSIG, can be considered to be part of DNSSEC. Finally, the definition of the CERT resource record [RFC 2538] gives DNS the ability to become a distribution mechanism for security data.
次の4つのコンポーネントは、DNSSECの一部であると考えられています。 DNSトラフィックのデジタル署名保護の概念は、RFC 2535に記載されたように、インターネットのスケール上のデータの転送を保護するように設計され、（例えば、[RFC 3008]のような）いくつかのサポート文書。ゾーン転送、DHCPの登録、およびネームサーバトラフィックに他のリゾルバへの適用可能性を持ってあまりスケーラブルが、より効率的なTSIGメカニズム[RFC 2845]を通じてクエリと応答を保護するというコンセプト。 TSIGを用いによって動的更新[RFC 3007]を、固定、DNSSECの一部であると考えることができます。最後に、CERT資源レコード[RFC 2538]の定義は、DNSにセキュリティデータの配信メカニズムになる能力を提供します。
This definition of the components of DNSSEC is in no way definitive. To be honest, this is a somewhat artificial grouping. DNSSEC does not encompass all of the security practiced in DNS today, for example, the redefinition of when and how data is cached [RFC 2181], plays a big role in hardening the DNS system. The four elements of DNSSEC described in the previous paragraph are grouped together mostly because they do interrelate, but also they were developed at approximately the same time.
DNSSECのコンポーネントのこの定義は、決定的では決してありません。正直に言うと、これはやや人工的なグループです。 DNSSECは、例えば、今日のDNSで実践セキュリティのすべてを包含していない、データがキャッシュされた[RFC 2181]のとき、どのように再定義は、DNSシステムを強化に大きな役割を果たしています。 DNSSECの4つの要素が前の段落で説明し、それらの相互関係ないため、主にグループ化されているが、また、それらがほぼ同時に開発されました。
The first part of the meeting consisted of reports of goals. From this a taxonomy of efforts has been made to see if there are gaps in the work.
会議の最初の部分は、目標のレポートで構成されていました。このことから努力の分類は、作業中にギャップがあるかどうかを確認するために行われています。
Efforts by NLnet Labs are directed towards yielding an understanding of the impact of DNSSEC on ccTLDs, specifically .de (Germany), .nl (The Netherlands), and .se (Sweden). Work to date has studied the problem of applying digital signatures and NXT records to a zone. The conclusion drawn is that there are no real problems regarding memory or CPU speed when signing large zones, not even for ".com." NLnet Labs has offered to work with Verisign to examine this further.
NLnet研究所による努力が（ドイツ）具体.DE、のccTLDにDNSSECの影響の理解を得、.nl（オランダ）、及び.SE（スウェーデン）に向けられています。これまでの仕事はゾーンにデジタル署名とNXTレコードを適用する問題を研究しています。描かれた結論はないでものために、大規模なゾーンに署名するときにメモリやCPU速度に関しては実際の問題がないことである「.COM。」 NLnet Labsはこれをさらに調査するベリサインで動作するように提供してきました。
NLnet Labs is trying to define and document procedures for TLD registries, registrars and registrants to properly handle actions like zone-resigning and key-rollover at the root, TLD, and lower levels. The outcome so far is that the DNSOP Roll Over proposal seems impractical or possibly even impossible to implement at large TLDs. NLnet Labs will produce a draft on an alternative KEY+SIG handling scheme where SIGs are only kept in the zone where the corresponding zone-KEY is located. This scheme reduces the necessary actions for resigning zones from 2 levels (current zone and all children) to 1 level (current zone), and for key-rollover from 3 levels (parent, current zone and all children) to 2 levels (parent and current zone).
NLnet Labsは定義して、TLDレジストリ、レジストラと登録者のための書類手続きが適切にゾーン辞任およびキーロールオーバールート、TLDで、かつ低いレベルのようなアクションを処理しようとしています。結果は、これまでDNSOPロールオーバー案は非現実的または可能性大のTLDで実装することさえ不可能だということです。 NLnet LabsはのSIGのみ対応するゾーン-KEYが配置されているゾーンに保管されている代替KEY + SIGハンドリング方式に草案を作成します。この方式は、2つのレベル（親に3つのレベル（親、現在のゾーンとすべての子）から1つのレベル（現在のゾーン）に、およびキーロールオーバーのための2つのレベル（現在のゾーンとすべての子）から退職ゾーンに必要な行動を減少させ現在のゾーン）。
Verisign's registry operations and corporate components have been investigating what DNSSEC means to very large zones, not just from a hardware point of view, but from an institutional point of view. With the service of providing delegations already commercialized, they are attempting to define what it would take to provide a DNSSEC service. An important issue is the parent validation of each delegated zone's keys.
ベリサインのレジストリ操作と企業のコンポーネントは、ハードウェアの観点から、ビューの制度的観点からだけではなく、DNSSECは非常に大きなゾーンに何を意味するかを調査してきました。すでに商品化委任を提供するサービスでは、彼らはそれがDNSSECサービスを提供するのにかかるものを定義しようとしています。重要な問題は、各委任ゾーンのキーの親の検証です。
The Foundation for Internet Infrastructure, an organization in Sweden, is running a project with two parts. One part is directed at the "topology" of the participants in DNSSEC, the other part of the project is directed towards general development of tools.
インターネットインフラのための財団、スウェーデンの組織は、二つの部分でプロジェクトを実行しています。一方の部分は、DNSSECの参加者の「トポロジー」に向けられ、プロジェクトの他の部分は、ツールの一般的な開発に向けられています。
The study is examining the administrative issues of running DNSSEC. One issue is the possible 4-party interaction in the use of DNSSEC. The four parties are the registry, the registrar, the registrant, and the DNS operator. Of these four parties, any combination may occur within one entity, such as a registrant that operates their own DNS as part of their information technology department.
研究では、DNSSECを実行する管理上の問題を検討しています。 1つの問題は、DNSSECの使用で可能な4者の相互作用です。 4つの当事者は、レジストリ、レジストラ、登録者、およびDNSオペレーターです。これら4つの者のうち、任意の組み合わせは、そのような彼らの情報技術部門の一部として、独自のDNSを運営する登録者として、一方のエンティティ内で発生することがあります。
The other part of the study is looking at what happens in the resolver. Goals include DNSSEC-enabling tools such as ISAKMPd (an IPSEC key negotiation software) secure NTP4, and e-mail. Part of this effort is implemented in the sigz.net experiment, information on this exists at www.sigz.net.
研究の他の部分はリゾルバに何が起こるか見ています。目標は、このようなISAKMPD（IPSEC鍵ネゴシエーションソフトウェア）のセキュアNTP4、および電子メールなどのDNSSEC有効化ツールが含まれています。この取り組みの一部はsigz.net実験で実装され、これに関する情報はwww.sigz.netに存在します。
The RSSAC (Root Server System Advisory Committee) has come to the conclusion that TSIG is worthwhile and should be deployed. There is no schedule for deployment, however.
RSSAC（ルートサーバーシステム諮問委員会）は、TSIGは価値があると展開されなければならないという結論に至りました。展開のためのスケジュールはしかし、ありません。
As for the rest of DNSSEC, there is a need to better understand the impact of the new features before being introduced into production. Currently issues regarding potential testbeds are being documented. Two fundamental assumptions are that a DNSSEC testbed involving the root servers is desirable and that such a testbed would allow for long term testing. The latter assumption is based upon the need to understand how repeated zone key validations can occur at multiple independent levels of the DNS hierarchy.
DNSSECの残りの部分については、より良い生産に導入される前に、新機能の影響を理解する必要があります。潜在的なテストベッドに関する現在の問題は文書化されています。二つの基本的な仮定は、ルートサーバを含むDNSSECテストベッドが望まれると、このようなテストベッドは、長期的なテストを可能にすることということです。後者の仮定を繰り返しゾーン鍵の検証は、DNS階層の複数の独立したレベルで発生する可能性があります方法を理解する必要性に基づいています。
CAIRN (Collaborative Advanced Interagency Research Network) is a DARPA-sponsored network for collaborative research. A funded activity that involves DNSSEC is FMESHD, shorthand for Fault-Tolerant Mesh of Trust in DNSSEC. The effort of this activity is to determine a means of building a resolver's chain of trust when some of the DNS tree is unavailable or unsecured. An early deliverable of this is an extension of secure shell to retrieve keys from DNSSEC. As part of this activity, the use of DNSSEC in a non-major provider zone is being implemented and studied.
CAIRN（共同アドバンスト省庁間研究ネットワーク）は、共同研究のためのDARPA主催のネットワークです。 DNSSECを必要とする資金を供給活動がFMESHD、DNSSECにおける信託のフォールトトレラントメッシュの省略形です。この活動の努力は、DNSツリーの一部が利用できないか、無担保であるとき、信頼のリゾルバのチェーンを構築する手段を決定することです。この初期の成果は、DNSSECのキーを取得するためのセキュアシェルの拡張機能です。この活動の一環として、非主要プロバイダゾーンにおけるDNSSECの使用が実装され、検討されています。
NIST is collecting performance information regarding DNSSEC. One of the fears in adopting DNSSEC is the workload it adds to existing DNS machine workload. The hopes of this effort is to quantify the fear, to see if it is real or imagined.
NISTは、DNSSECに関するパフォーマンス情報を収集しています。 DNSSECを採用における懸念の一つは、既存のDNSマシンのワークロードに追加したワークロードです。この努力の希望は、それが本物か想像であるかどうかを確認するために、恐怖を定量化することです。
If time permits, there may be an effort to implement a zone integrity checking program (implemented in Java) that will look for missteps in the use of DNSSEC. Base code exists, but needs work (beyond the current baseline).
時間が許すならば、DNSSECの使用に失策を検索します（Javaで実装されている）ゾーンの整合性チェックプログラムを実装するための努力があるかもしれません。基本コードは存在するが、（現在のベースラインを超えて）作業を必要とします。
The U.S. Defense Information Systems Agency is providing funds to have DNSSEC implemented in BIND. Of particular interest is making sure that the DNSSEC specifications are correct, that BIND adheres to the specifications, and that BIND is available on the operating systems in use by the US Department of Defense. DISA expects that every line of code developed through this effort be made publicly available as part of stock BIND releases.
米国国防情報システム局は、BINDで実装DNSSECを持っている資金を提供しています。特に興味深いのは、DNSSECの仕様が正しいことを確認している、そのBINDは、仕様に準拠し、かつそのBINDは、米国国防総省で使用されているオペレーティングシステム上で使用可能です。 DISAは、この努力によって開発されたコードのすべての行が株式BINDリリースの一部として公開されることを期待しています。
The RIPE NCC is looking at the impact of DNSSEC on IP-registries. The RIPE NCC is planning to coordinate and assist in the deployment of DNSSEC. Because the RIPE NCC is the Regional Internet Registry for Europe the focus will be on the deployment of DNSSEC on the reverse map tree (in-addr.arpa for IPv4).
RIPE NCCは、IP-レジストリへのDNSSECの影響を見ています。 RIPE NCCは、座標とDNSSECの導入を支援するために計画しています。 RIPE NCCは、ヨーロッパのための地域インターネットレジストリであるため、焦点は逆マップツリー（IPv4のin-addr.arpa）のDNSSECの展開になります。
ARIN is investigating DNSSEC for use in signing its delegated zones under in-addr.arpa. It participated in a dnssec workshop following NANOG 20 held in Washington, DC in October, 2000. It also participated in an ipv6-dnssec workshop that followed IETF 49 in San Diego, California. Additionally, ARIN has stood up a server dedicated to testing various dns experimentation, including dnssec and carrying out limited testing.
ARINはin-addr.arpaの下にその委任ゾーンに署名に使用するためにDNSSECを調査しています。それはまた、カリフォルニア州サンディエゴでIETF 49を踏襲したIPv6-DNSSECワークショップに参加した2000年10月にワシントンD.C.で開催されたNANOG 20次DNSSECワークショップに参加しました。さらに、ARINは、DNSSECを含むさまざまなDNSの実験を、テストし、限られたテストを行う専用のサーバーを立ち上がっています。
NAI is pressing to get the tislabs.com zone running in accordance with DNSSEC. This is an example of a non-Internet service provider (neither an IP transit, IP address allocation, nor a domain name managing entity) making use of DNSSEC within the normal operations of the Information Technology department.
NAIは、DNSSECに基づいて実行されているtislabs.comゾーンを取得するために押しています。これは、情報技術部門の通常業務内でDNSSECを利用した非インターネット・サービス・プロバイダ（いずれもIPトランジット、IPアドレスの割り当て、またエンティティを管理するドメイン名）の一例です。
The name servers authoritative for the ip6.int. domain are mostly upgraded to be able to support CERT records and TSIG. Once this is fully accomplished and proposals are approved, TSIG and CERT records will be used. Further DNSSEC work is unknown.
ip6.intのための権威ネームサーバ。ドメインは、主にCERTレコードとTSIGをサポートすることができるようにアップグレードされています。これは完全に達成され、提案が承認されると、TSIGとCERTレコードが使用されます。さらに、DNSSEC作業は不明です。
Topology Based Domain Search (TBDS), is a DARPA funded activity investigating how DNS may continue to run in disconnected parts of the Internet. Topics of interest (either covered by this project, or associated with the project) are the use of split keys, self-signed zone (keys), and multiple signing algorithms. A goal is the establishment of signed infrastructure zones, facilitating the creation of a distributed CA for activities like IPSEC and FreeSwan.
トポロジベースのドメイン検索（TBDS）は、DNSはインターネットの切断部分に実行を継続できるかを調査DARPA資金提供活動です。興味のあるトピック（このプロジェクトによって覆われ、またはプロジェクトに関連付けられているいずれか）分割鍵、自己署名されたゾーン（キー）、及び複数の署名アルゴリズムの使用です。目標は、IPSECとFreeSwanなどの活動のための分散CAの作成を容易に署名したインフラゾーンの確立です。
The efforts being undertaken appear to cover a broad range of work areas, from large domain registries to domain name consumers. Work has been progressing in the production of zones (signing, key management), and is starting in the use (resolver) of DNSSEC secured data.
行われての努力は、ドメイン名の消費者への大規模なドメイン登録から、作業領域の広い範囲をカバーするように見えます。仕事はDNSSEC保護されたデータのゾーンの生産（署名、鍵管理）に進んでおり、使用中に開始される（リゾルバ）。
From the discussion, there were no apparent areas lacking attention. Additional input in some areas is needed however, particularly in making use (applications and IT department) of DNSSEC.
議論から、注意を欠いている明白な領域がありませんでした。一部の地域では、追加の入力は、特にDNSSECの使用（アプリケーションやIT部門）を行う際に、しかし必要とされています。
By the 49th IETF meeting, the most pressing question on DNSSEC is "is it deployable?" From just the emphasis placed on this question, the meeting generated a list of questions and made sure that either the answer was known, or work was being done to address the question.
第49回IETFミーティングでは、DNSSECの最も差し迫った問題は、「それは展開可能です？」ですこの質問に配置されたばかり重視から、会議が質問のリストを生成し、答えのいずれかが知られていたことを確認しました、または仕事は、問題に対処するために行われていました。
The usual answer to this has been "not now." When is always off into the future - "about a year." To get to a deployable point, a series of workshops have been held since the spring of 1999.
これまでの通常の答えは、「今ではない。」となっていますオフのときは未来に常にある - 「約一年。」展開可能なポイントを取得するには、一連のワークショップは、1999年の春から開催されています。
At this point, it is becoming clearer that longer term workshops are needed. In going through the motions of any workshop, the number of issues raised that impact the protocol's specification is diminishing, as well as implementation issues. As such, one or two day workshops have been helping less and less in reaching deployment.
この時点で、それは長期的なワークショップが必要であることが明確になってきています。任意のワークショップの動きを経て、多くの問題は、そのプロトコルの仕様が減少している影響だけでなく、実装上の問題を提起しました。このようにして、1または2日間のワークショップは、展開に至るに少なくを支援してきました。
What is needed is to run longer term test configurations, possibly workshops that are help in conjunction with other events and that assume continuity. This will allow a better assessment of the issues that involve the passage of time - expirations on key validations, etc.
必要なものは、おそらく長期的なテスト構成、他のイベントと一緒に助けており、それが継続性を前提とワークショップを実行することです。これは、時間の経過を伴う問題のより良い評価を可能にします - キーの検証の有効期限など
As was noted in section 1.1, and touched on in section 2, one component of DNSSEC, TSIG, is more advanced that the others. Use of TSIG to protect zone transfers is already matured to the "really good idea to do stage" even if other elements of DNSSEC are not. Using TSIG to protect traffic between local resolver and their "default" recursive name server still needs more work, however.
セクション1.1で述べた、及びセクション2に触れたように、DNSSEC、TSIGの一つの成分は、他のものより高度です。ゾーン転送を保護するためにTSIGの使用は、すでにDNSSECの他の要素がない場合であっても、「舞台をやって本当に良いアイデア」に成熟しています。ローカルリゾルバとその「デフォルト」再帰ネームサーバ間のトラフィックを保護するためにTSIGを使用することはまだしかし、多くの作業を必要とします。
Currently there is a lot of effort into making the specification as proposed work. There is some effort in assessing the specification at this point, particularly the value of the NXT records and possible replacements of it.
現在提案されている作品としての仕様を作るに多くの労力があります。この時点では仕様書を評価する上でいくつかの努力、特にNXTレコードの値と、それの可能性置き換えがあります。
There seems little question on value of the KEY and SIG records. There is some research still needed on KEY validation across zone boundaries. Such work is at least scheduled.
KEYとSIGレコードの値にはほとんど問題があるようです。まだゾーンの境界を越えKEYの検証に必要ないくつかの研究があります。このような作業は、少なくとも予定されています。
There are a number of efforts to take existing applications and have them make direct use of DNSSEC to carry out their functions. One such example is secure shell.
既存のアプリケーションを取り、彼らがその機能を実行するためにDNSSECを直接使用すること持つための努力がいくつかあります。その一例は、セキュアシェルです。
When or whether DNSSEC will be understood in the (using POSIX-like terms) operating systems "gethostbyname" and similar routines has not been addressed.
場合又はDNSSECは、（POSIXのような用語を使用して）オペレーティングシステム「のgethostbyname」と同様のルーチンが対処されていないに理解されるであろう。か
There are still a few protocol issues. The NXT resource record is designed to provide a means to authentically deny data exists. The problem is that the solution proposed may be worse than the problem, in the eyes of some. There is an alternative proposal, the NO resource record, under consideration in the DNSEXT working group. At the present time, the DNSEXT working is considering the following question: Is there a need to authentically deny existence of data, if so, which is better, NXT (being incumbent) or NO?
いくつかのプロトコルの問題が残っています。 NXTリソースレコードは、本物のデータが存在を否定するための手段を提供するように設計されています。問題は、提案された解決策は、いくつかの目には、問題よりも悪いかもしれないということです。 DNSEXTワーキンググループで検討中の代替案、NOリソースレコードは、あります。 NXT（さ現職）、そうであれば、どれが優れている、本物のデータの存在を否定する必要があるかNO：現時点では、DNSEXTの作業は、次の質問を検討していますか？
Another less defined issue is the mechanism for parent validation of children signatures. Although the protocol elements of this are becoming settled, the operational considerations are not, as evidenced by work mentioned in section 2. DNSSEC interactions have also been referenced in discussions over a standard registry-registrar protocol.
もうあまり定義された問題は、子どもたちの署名の親の検証のためのメカニズムです。このプロトコル要素が確定しつつあるものの、運用の考慮事項が2 DNSSECの相互作用はまた、標準のレジストリ・レジストラプロトコル上での議論の中で参照されているセクションで説明した作業によって明らかなように、ではありません。
The IETF goal for DNSSEC is to progress the documents through the standards track [RFC 2026]. Currently, RFC 2535 is the second iteration at the Proposed standard level. There is a need to cycle through Proposed once more. Following this, the next goal is Draft.
DNSSECのためのIETFの目標は、標準化を通じて文書を進行することである[RFC 2026]を追跡します。現在、RFC 2535は、提案された標準レベルでの2回目です。もう一度案を循環させる必要があります。これに続いて、次の目標はドラフトです。
To pass to the Draft Standard level, two main requirements must be met. There must be two or more interoperable implementations. There must also be sufficient successful operational experience.
ドラフト標準レベルに合格するには、二つの主な要件が満たされなければなりません。二つ以上の相互運用可能な実装が存在する必要があります。また、十分な成功運用経験がなければなりません。
DNSEXT will soon begin a rewrite of the RFC 2535 specification (and its support documents), rolling in updates and clarifications based upon implementation and testing experience.
DNSEXTはすぐに実装とテストの経験に基づいて更新と説明に転がり、RFC 2535の仕様（とそのサポート文書）の書き換えを開始します。
DNSOP will continue to be the forum for operations documents based upon DNSSEC activity. There is a need for the community to provide more documents to this group.
DNSOPは、DNSSECの活動に基づいて業務文書のためのフォーラムであり続けるだろう。このグループに複数のドキュメントを提供するコミュニティの必要性があります。
Demonstrating interoperability of DNSSEC, meaning the interaction of two different implementations when performing DNSSEC work, poses an issue because, to date, only BIND is seriously being fitted with DNSSEC. There are other partial implementations of DNSSEC functionality, so the potential for partial interoperability demonstrations may exist.
現在までに、唯一のBINDは真剣にDNSSECを装備している、ので、DNSSECの作業を行うときに、2つの異なる実装の相互作用を意味し、DNSSECの相互運用性を実証し、問題を提起します。そこDNSSEC機能の他の部分の実装があるので、部分的な相互運用性のデモの可能性が存在してもよいです。
During the meeting, it was realized that given goals stated, a second DNSSEC implementation is needed in 18 months. Various folks in the room mentioned that they would begin see what could be done about this.
会議中に、それは与えられた目標を述べたことを実現した、第二DNSSECの実装は18ヶ月で必要とされています。客室内に様々な人々は、彼らはこのことについて何ができるか見始めるだろうと述べました。
The following people attended the meeting and/or provided text for this report (in no particular order): Mark Kosters (Network Solutions), Patrik Faltstrom (Cisco), Ted Lindgreen and Miek Gieben (NLnet Labs), Jaap Akerhuis (SIDN), Olaf Kolkmann (RIPE NCC), Bill Manning and Dan Massey (ISI), Martin Fredriksson, Hakan Olsson and Jakob Schlyter (Carlstedt Research & Technology), Doug Montgomery and Scott Rose (NIST), Johan Ihren and Lars-Johan Liman (Autonomica), Brian Wellington (Nominum), Kevin Meynell (CENTR), Ed Lewis and Olafur Gudmundsson (NAI Labs).
次の人は（順不同）このレポートの会合および/または提供されたテキストに出席しました：マークKosters（ネットワークソリューション）、パトリックFaltstrom（シスコ）、テッドLindgreenとMiek Gieben（NLnet Labs社）、ヤープAkerhuis（SIDN）、オラフKolkmann（RIPE NCC）、ビル・マニングとダン・マッセイ（ISI）、マーティン・Fredriksson、ハカン・オルソンとヤコブSchlyter（Carlstedtリサーチ＆テクノロジー）、ダグ・モンゴメリーとスコット・ローズ（NIST）、ヨハンIhrenとラース・ヨハンLiman（Autonomica） 、ブライアン・ウェリントン（ノミナム）、ケビン・Meynell（CENTR）、エド・ルイスとオラフルグドムンソン（NAI Labs社）。
This document does not involve assigned numbers in any way.
この文書では、どのような方法で割り当てられた番号は含まれません。
This document, although a discussion of security enhancements to the DNS, does not itself impact security. Where security issues arise, they will be discussed in the Security Considerations of the appropriate document.
この文書では、DNSのセキュリティ強化の議論が、それ自体はセキュリティに影響を与えません。セキュリティ上の問題が発生した場合、それらは、適切な文書のセキュリティの考慮事項に説明します。
The text of any RFC may be retrieved by a web browser by requesting the URL: ftp://ftp.isi.edu/in-notes/rfc<wxyz>.txt, where "wxyz" is the number of the RFC.
すべてのRFCのテキストは、URLを要求することにより、Webブラウザによって取得することができる：ftp://ftp.isi.edu/in-notes/rfc<wxyz>.txt、「WXYZ」はRFCの数です。
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", July 1997.
[RFC 2181]エルツ、R.とR.ブッシュ大統領、 "DNS仕様の明確化"、1997年7月。
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions", March 1999.
[RFC 2535]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、1999年3月。
[RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System", March 1999.
[RFC 2538]イーストレイク、D.およびO.グドムンソン、「ドメインネームシステムでの保管証明書」、1999年3月。
[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", May 2000.
[RFC 2845]いるVixie、P.、グドムンソン、O.、イーストレイク、D.とB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、2000年5月。
[RFC 3007] Wellington, B., "Secure Domain Name System Dynamic Update", November 2000.
[RFC 3007]ウェリントン、B.、2000年11月 "ドメインネームシステム動的な更新を固定"。
[RFC 3008] Wellington, B., "Domain Name System Security Signing Authority", November 2000.
[RFC 3008]ウェリントン、B.、2000年11月 "ドメインネームシステムのセキュリティは、権限の署名"。
Edward Lewis 3060 Washington Rd (Rte 97) Glenwood, MD 21738
エドワード・ルイス3060オーガスタ（RTE 97）グレンウッド、MD 21738
Phone: +1(443)259-2352 EMail: lewis@tislabs.com
電話：+1(443)259-2352 Eメール：lewis@tislabs.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。