[要約] RFC 3130は、DNSSECの現状と技術に関する要点をまとめたものです。その目的は、DNSセキュリティの向上と信頼性の確保です。
Network Working Group E. Lewis
Request for Comments: 3130 NAI Labs
Category: Informational June 2001
Notes from the State-Of-The-Technology: DNSSEC
最先端からのメモ：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.
Copyright（c）The Internet Society（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は、DNSEXTとDNSOPの2つのワーキンググループの憲章の一部です。ISCのBind V8.2は仕様の一部を実装しました。BindV9は、最初の完全な実装を表します。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、Network Associates、Verisign（com/net/org tlds）を代表しました。
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.
議論中に行われたコメントの1つは、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の一部であると考えられています。RFC 2535で説明されているDNSトラフィックのデジタル署名保護の概念と、インターネットスケールでのデータの転送を保護するように設計されたいくつかのサポートドキュメント（[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ラボの取り組みは、CCTLDS、特に.DE（ドイツ）、.NL（オランダ）、および.se（スウェーデン）に対するDNSSECの影響の理解をもたらすことに向けられています。これまでの作業は、デジタル署名とNXTレコードをゾーンに適用する問題を研究しています。描かれた結論は、「.com」のためでさえなく、大きなゾーンに署名するとき、メモリやCPU速度に関する本当の問題はないということです。NLNET Labsは、これをさらに調べるためにVerisignと協力することを申し出ました。
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が保持される代替キーSIG処理スキームのドラフトを作成します。このスキームは、ゾーンを2つのレベル（現在のゾーンおよびすべての子供）から1レベル（現在のゾーン）に除去するために必要なアクションを削減し、3つのレベル（親、現在のゾーン、およびすべての子供）から2つのレベル（親と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.
Verisignのレジストリ運用と企業コンポーネントは、ハードウェアの観点からだけでなく、制度の観点から、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.
スウェーデンの組織であるインターネットインフラストラクチャの基礎は、2つの部分を持つプロジェクトを運営しています。1つの部分は、DNSSECの参加者の「トポロジ」に向けられており、プロジェクトのもう1つの部分はツールの一般的な開発に向けられています。
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を運営する登録者など、1つのエンティティ内で任意の組み合わせが発生する場合があります。
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の残りの部分については、生産に導入される前に新機能の影響をよりよく理解する必要があります。現在、潜在的なテストベッドに関する問題が文書化されています。2つの基本的な仮定は、ルートサーバーを含む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（Collaborative Advanced Interagency Research Network）は、共同研究のためのDARPAが後援するネットワークです。DNSSECを含む資金提供された活動は、DNSSECの断層耐性の信頼のメッシュのFMESHDであり、速記です。このアクティビティの努力は、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を採用することの恐怖の1つは、既存の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.
米国防衛情報システム機関は、DNSSECをBindに実装するための資金を提供しています。特に興味深いのは、DNSSECの仕様が正しく、バインドが仕様に付着し、そのバインドが米国国防総省が使用しているオペレーティングシステムで利用できることを確認することです。DISAは、この取り組みを通じて開発されたすべてのコードが、ストックバインドリリースの一部として公開されることを期待しています。
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).
熟したNCCは、IP-Registriesに対するDNSSECの影響を検討しています。Ripe NCCは、DNSSECの展開を調整して支援することを計画しています。熟した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を調査しています。2000年10月にワシントンDCで開催されたNANOG 20に続くDNSSECワークショップに参加しました。また、カリフォルニア州サンディエゴのIETF 49に続いたIPv6-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ゾーンを実行するように迫っています。これは、インターネットサービスプロバイダー（IPトランジット、IPアドレスの割り当て、またはドメイン名の管理エンティティ）の例であり、情報技術部門の通常の運用内でDNSSECを使用しています。
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.
これに対する通常の答えは「今ではない」ことです。いつでも未来にオフになるのは、「約1年」です。展開可能なポイントに到達するために、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の1つのコンポーネント、TSIGは、他のDNSIGよりも高度です。ゾーン転送を保護するために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.
キーレコードとSIGレコードの価値に関する疑問はほとんどないようです。ゾーン境界を越えた重要な検証に関する研究がまだ必要です。そのような作業は少なくともスケジュールされています。
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を直接使用して機能を実行するために、多くの努力があります。そのような例の1つは、安全なシェルです。
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リソースレコードがあります。現時点では、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.
それほど定義されていないもう1つの問題は、子供の署名の親の検証のメカニズムです。セクション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.
標準レベルのドラフトに渡すには、2つの主要な要件を満たす必要があります。2つ以上の相互運用可能な実装が必要です。また、十分な成功した運用経験がなければなりません。
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.
DNSSECの相互運用性を実証することは、DNSSECの作業を実行するときに2つの異なる実装の相互作用を意味しますが、これまでにBindのみが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.
会議中に、目標が述べられていることを考えると、18か月で2回目のDNSSEC実装が必要であることが認識されました。部屋のさまざまな人々は、これについて何ができるかを見始めると述べました。
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).
次の人々は、このレポートの会議および/または提供されたテキストに参加しました（特定の順序なし）：マークコスターズ（ネットワークソリューション）、パトリックファルトストローム（シスコ）、テッドリンドグリーン、ミークギーベン（NLNETラボ）、ジャプアケルイス（SIDN）、オラフ・コルクマン（RIPE NCC）、ビル・マニングとダン・マッシー（ISI）、マーティン・フレドリクソン、ハカン・オルソン、ヤコブ・シュライター（カールステッド・リサーチ・テクノロジー）、ダグ・モンゴメリーとスコット・ローズ（NIST）、ヨハン・イーレン、ラース・ジョハン・リマン（オート経済）、ブライアン・ウェリントン（ノミナム）、ケビン・メイネル（センター）、エド・ルイス、オラファー・グドムンソン（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：ftp：//ftp.isi.edu/in-notes/rfc<wxyz>.txtを要求することにより、Webブラウザーによって取得できます。
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2026] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。
[RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", July 1997.
[RFC 2181] Elz、R。およびR. Bush、「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] Eastlake、D。およびO. Gudmundsson、「ドメイン名システムに証明書の保存」、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.、Gudmundsson、O.、Eastlake、D。and B. Wellington、「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ワシントンRD（RTE 97）グレンウッド、MD 21738
Phone: +1(443)259-2352
EMail: lewis@tislabs.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。