この文書はRFC3130の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
Abstract
概要
This is a memo of a DNSSEC (Domain Name System Security Extensions)
status meeting.
これはＤＮＳＳＥＣ（ドメインネームシステムセキュリティ拡張）状態のミー
ティングのメモです。
1.0 Introduction
1.0 はじめに
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.
ＤＮＳセキュリティ拡張の開発に関係しているグループ（ＤＮＳＳＥＣ）の
ミーティングが第４９番目のＩＥＴＦと関連して開催されました。論議は現
在の取り組み、ＤＮＳＳＥＣに何の問題があるか、ドラフト標準レベルへの
進行のためにＩＥＴＦでなにが必要かを含みました。
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.
ＤＮＳセキュリティ拡張の開発に関係しているグループ（ＤＮＳＳＥＣ）の
ミーティングが第４９番目のＩＥＴＦと関連して開催されました。論議は現
在の取り組み、ＤＮＳＳＥＣに何の問題があるか、ドラフト標準レベルへの
進行のためにＩＥＴＦでなにが必要かを含みました。ＤＮＳＳＥＣ[RFC 2535]
は、ＲＦＣ２５３５を最も最近の定義の核心として、数年間考慮中でした。
ＤＮＳＳＥＣは２つのワーキンググループ、ＤＮＳＥＣＴとＤＮＳＯＰの特
権の一部です。ＩＳＣのＢＩＮＤv８.２は仕様の一部を実装しました、ＢＩ
ＮＤv９が最初の完全実装を表します。１９９９年と２０００年に、半ダース
以上のワークショップが概念と実装の初期バージョンをテストするものと考
えられました。けれども今日まで、ＤＮＳＳＥＣは一般に使われていません。
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).
現在の全般的な考えは、ＤＮＳＳＥＣが１）重要、２）流行、３）難しい、
４）未熟であるということです。技術の本当の状態を獲得して、そして必要
な仕事を識別するために、ＤＮＳＳＥＣに関係していることを知られるグルー
プの非公式の集会が第４９番目のＩＥＴＦと関連して持たれました。出席者
はNLnet LabsとThe Foundation for Internet InfrastructureとRIPE NCCと
ARINとCAIRN(ISIとNAI Labs)とNISTとDISAとRSSACとNetwork Associatesと
Verisign(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.
ミーティングの議題は３つの項目から成り立ちました。現在の研究目標につ
いてのそれぞれのグループからの報告がＤＮＳＳＥＣの問題の論議の後に続
きます。最終的に、ドラフト標準状態に達する目標に対し、これに必要なも
のは考慮されました。
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.
この報告はただミーティングの写しではありません、これは要約です。ここ
で提出された情報のいくらかがミーティングの後に関係者と直接連絡をとっ
て得られました。
1.1 What does the term "DNSSEC" mean?
1.1 用語「ＤＮＳＳＥＣ」は何を意味しますか？
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.
論議の間にされたコメントの１つがＤＮＳＳＥＣが１つの技術を参照してい
ないということです。用語は技術の「道具箱」と方法論に関係し、正確に使
われる時ＤＮＳの完全性を改善することができます。この発言は、ＤＮＳＳ
ＥＣのある部分が他の部分よりずっといっそう急速に進展していると見るこ
とができます。特に、ＴＳＩＧ[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.
次の４つのコンポーネントはＤＮＳＳＥＣの一部であると考えられます。イ
ンターネットスケールでデータの転送を守るよう意図されるＲＦＣ２５３５
と少数の関連文書（[RFC 3008]のような）で記述されるＤＮＳトラフィック
のディジタル署名保護の概念。ゾーン転送とＤＨＣＰ登録と他のリゾルバ−
ネームサーバトラヒック適用できる、スケールは小さいがより効率的なＴＳ
ＩＧメカニズム[RFC 2845]により問合せと回答を守る概念。ＴＳＩＧを使っ
た安全なダイナミック更新[RFC 3007]が、ＤＮＳＳＥＣの一部であると考え
られます。最終的に、ＣＥＲＴ資源レコード[RFC 2538]の定義はＤＮＳにセ
キュリティデータの配布分配メカニズムになる能力を与えます。
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.
このＤＮＳＳＥＣの要素の定義は決して決定的ではありません。正直言って、
これは幾分人工的な組分けです。ＤＮＳＳＥＣは今日ＤＮＳで行われている
安全管理のすべてをカバーするわけではありません、例えば、いつどうやっ
てデータをキャッシュするかの再検討[RFC 2181]は、ＤＮＳシステムを強固
にすることにおいて大きい役割を演じます。前の段落で記述されたＤＮＳＳ
ＥＣの４つの要素は、およそ同じ時において開発されたから、たいてい相互
に関係を持ちます。
2.0 Group Reports
2.0 グループ報告
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.
ミーティングの最初の部分は目的の報告から成り立ちました。これから努力
の分類学が仕事に途切れがあるかどうか見るためにされました。
2.1 NLnet Labs
2.1 NLnet研究所
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（ドイツ）
と.nl（オランダ）と.se（スウェーデン）、の理解を直接もたらしました。
今日までの仕事がゾーンにディジタル署名とＮＸＴレコードを適用すること
の問題です。結論は、「.com」ほどではないが、大きいゾーンに署名する時、
メモリやＣＰＵ速度に関係している真の問題がないという事です。NLnet研究
所はさらにこれを調べるために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研究所はＴＬＤ登記所と登記係と登録人が、ルートやＴＬＤや下のレベ
ルのゾーン再署名や鍵切り替えを適切にある買う手順を定義し、文書化しよ
うとしています。これまでの結果は、ＤＮＳＯＰの交換提案が、大きいＴＬ
Ｄで実行できないか不可能に思われるということです。NLnet研究所が、対応
するローカル鍵が位置しているゾーンだけに署名が維持される代わりの鍵と
署名取り扱い案のドラフトを作り出すでしょう。この案は、再署名の際に必
要な行動を２レベル（現ゾーンと子ゾーン）から１レベル（現ゾーン）に減
らし、鍵交換で必要な行動を３レベル（親ゾーン、現ゾーン、子ゾーン）か
ら２レベル（親ゾーンと現ゾーン）に減らします。
2.2 Verisign
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.
ベリサインの登記所オペレーションと企業要素はＤＮＳＳＥＣが、非常に大
きいゾーンで、ハードウェアの見地からだけではなく、制度上の見地から何
を意味するか調査していました。すでに商業化された委任を供給するサービ
スで、彼らはＤＮＳＳＥＣサービスを供給するために何が必要かを定義しよ
うと試みています。重要な問題はそれぞれの委任されたゾーンの鍵の親認証
です。
2.3 The Foundation for Internet Infrastructure
2.3 インターネット基盤の財団
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.
インターネット基盤の財団、スウェーデンの組織、は２つの部分のプロジェ
クトを運営しています。１つの部分がＤＮＳＳＥＣ関係者の「トポロジー」
に向けられます、プロジェクトの他の部分が道具の一般的な開発に向けられ
ます。
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.
研究はＤＮＳＳＥＣを動かす時の管理上の問題を調べています。１つの問題
はＤＮＳＳＥＣの使用に関する４者の相互作用です。４者とは登記所と登記
係と登録人とＤＮＳオペレーターです。これらの４者の任意の組合せは、情
報工学部門の一部として自身のＤＮＳを操作する登録人のように、１人かも
しれません。
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.
研究の他の部分がリゾルバで起きることを見ています。目的はがISAKMP（Ｉ
ＰＳＥＣ鍵交渉ソフトウェア）による安全なＮＴＰ４と電子メールのような
ＤＮＳＳＥＣを可能にするツールを含みます。この努力の一部がsigz.net実
験で実行されます、この情報がwww.sigz.netに存在します。
2.4 RSSAC
2.4 ＲＳＳＡＣ
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.
ＲＳＳＡＣ（ルートサーバーシステム諮問委員会）はＴＳＩＧが価値がある
という結論に到達し、そして配置されるべきです。しかしながら、配置スケ
ジュールがありません。
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.
ＤＮＳＳＥＣの残りは、商用導入される前にもっと良く新しい機能の影響を
理解する必要があります。現在潜在的なテストベッドに関係している問題が
文書化されています。２つの基本的な仮定がルートサーバを含むＤＮＳＳＥ
Ｃテストベッドが望ましく、そしてこのようなテストベッドが長期テストを
考慮するであろうということです。後の仮定は、多数の独立なＤＮＳ階層で、
どのように繰り返しゾーン鍵認証が起こるかの理解に基づきます。
2.5 CAIRN
2.5 ケルン
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.
ケルン（共同拡張相互作用研究ネットワーク）は共同研究のためにＤＡＲＰ
Ａによって後援されたネットワークです。ＤＮＳＳＥＣに関する資金を供給
された活動がＦＭＥＳＨＤで、ＤＮＳＳＥＣの信頼フォールトトレラントメッ
シュの簡易表記です。この活動の取り組みは、ＤＮＳ木のいくらかが利用で
きないか、あるいは保証がない時、リゾルバの信頼鎖を作る手段を決定する
ことです。早期のこれについて遂行可能な安全なシェルの拡張がＤＮＳＳＥ
Ｃから鍵を検索するはずです。この活動の一部として、非主要プロバイダゾー
ンでのＤＮＳＳＥＣの使用が実行されて、調査されています。
2.6 NIST
2.6 ＮＩＳＴ
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.
ＮＩＳＴはＤＮＳＳＥＣに関して性能情報を集めています。ＤＮＳＳＥＣを
採用する際の恐れの１つが既存のＤＮＳマシンの作業負荷の追加です。この
取り組みの希望は恐れを数量化し、これが真なのか想像なのかを見ることで
す。
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).
もし時間が許すなら、ＤＮＳＳＥＣの使用の失敗を探すであろう（Ｊａｖａ
で実装される）ゾーン完全性を調べるプログラムを実装する努力があるかも
しれません。基本となるコードが存在しますが、仕事が必要です（現在のベー
スラインを越えて）。
2.7 DISA
2.7 ＤＩＳＡ
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.
合衆国防衛情報システム政府機関はＢＩＮＤにＤＮＳＳＥＣを実装する資金
を供給しています。特定の興味についてＤＮＳＳＥＣ仕様が正しいことを確
かにし、ＢＩＮＤは仕様書を支持し、そしてそのＢＩＮＤは合衆国国防省で
使用中のオペレーティング・システムの上で利用可能です。ＤＩＳＡはすべ
てのこの取り組みを通して開発したコード行が、ＢＩＮＤリリースのストッ
クの一部として、公的に利用可能にされると思います。
2.8 RIPE NCC
2.8 RIPE NCC
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はＩＰ登記所のＤＮＳＳＥＣの影響を見ています。RIPE NCCはＤＮ
ＳＳＥＣの展開を調整して、そして支援することを計画しています。RIPE
NCCがヨーロッパの地域インターネット登記所であるから、フォーカスは逆
翻訳木（ＩＰｖ４でin-addr.arpa）上のＤＮＳＳＥＣの展開にあるでしょう。
2.9 ARIN
2.9 ARIN
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.
ＡＲＩＮはin-addr.arpa下で委任されたゾーンに署名する際の使用に関して
ＤＮＳＳＥＣを調査しています。ＡＲＩＮはNANOG 20が２０００年１０月に
ワシントンＤＣで持ったＤＮＳＳＥＣワークショップに参加しました。ＡＲ
ＩＮは同じくカリフォルニアのサンディエゴでIETF 49の後に行ったＩＰｖ６
−ＤＮＳＳＥＣワークショップに参加しました。さらに、ＡＲＩＮはＤＮＳ
ＳＥＣや限定されたテストを含む様々なＤＮＳ実験をテストの実行専用のサー
バを立てました。
2.10 Network Associates
2.10 ネットワーク仲間
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.
ＮＡＩはＤＮＳＳＥＣに従ってtislabs.comゾーンを動かすことを 地域ラン
ニングを得ることを推進しています。これは情報工学部門の標準的な運営の
中でＤＮＳＳＥＣを利用する非インターネット・サービスプロバイダ（ＩＰ
トランシット、ＩＰアドレス割り当て、ドメイン名処理実体のいずれか）の
例ではありません。
2.11 ip6.int. domain
2.11 ip6.int.ドメイン
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.ドメインの正式ネームサーバは、ＣＥＲＴレコードとＴＳＩＧを支
援することが可能であるためにほとんど更新されています。これが完全に達
成されそして提案が承認されたら、ＴＳＩＧとＣＲＥＴレコードが使われる
でしょう。それ以上のＤＮＳＳＥＣの仕事は未知です。
2.12 Topology Based Domain Search
2.12 トポロジーに基づくドメイン捜索
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.
トポロジーに基づくドメイン捜索（ＴＢＤＳ）は、どのようにＤＮＳがイン
ターネットのつながっていない部分上で動作し続けるかを調査するためＤＡ
ＲＰＡによって資金を供給された活動です。対象となる話題（あるいはこの
プロジェクトの範囲、あるいはプロジェクトと関連するもの）は分裂鍵と自
己署名ゾーン（鍵）と多数署名アルゴリズムの使用です。目的は、ＩＰＳＥ
ＣとFreeSwanのような活動のために分散ＣＡの創造を容易にして、署名され
た基礎ゾーンの設立です。
3.0 Taxonomy of efforts and What is missing
3.0 取り組みの分類と欠けているもの
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.
着手されている取り組みはは、大きいドメイン登記所からドメイン名消費者
まで、仕事のエリアの広い範囲をカバーするように思われます。仕事が商用
ゾーンで進行し（署名、鍵管理）、そしてＤＮＳＳＥＣ安全データの使用
（リゾルバ）が開始しています。
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.
論議から、注意に欠けている明白なエリアがありませんでした。しかしなが
らあるエリアでの追加入力が必要です、特にＤＮＳＳＥＣの使用（アプリケー
ションとＩＴ部門）をすることでです。
4.0 Questions facing DNSSEC
4.0 ＤＮＳＳＥＣが直面している問題
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.
第４９番目のＩＥＴＦミーティングによって、ＤＮＳＳＥＣ上の最も緊急の
問題は「それは展開可能か？」です。この質問を強調したので、ミーティン
グは質問のリストを生成して、そして答えが知られているか、あるいは質問
を扱う仕事が開始されていることのいずれかが真であることを確かにしまし
た。
4.1 Is it deployable? When?
4.1 展開可能ですか？ いつですか？
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.
これへの答えはいつもの「今でない」でした。いつは、常に未来−「およそ
１年」−です。展開可能な点に到達するために、一連のワークショップが
１９９９年の春から持たれました。
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.
この時点で、より長期のワークショップが必要とされることはいっそう明確
になっています。ワークショップの動きをやり通すことで、プロトコル仕様
に影響を与える問題の発覚の数は減少し、実装問題も同様です。そして、１
日間か２日間のワークショップが配置に達するまでを短くしました。
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.
１.１章で気づき、そして２章で簡単に触れたように、ＤＮＳＳＥＣとＴＳＩ
Ｇの１つの要素は他より進歩したということです。ゾーン転送を守るための
ＴＳＩＧの使用は、たとえＤＮＳＳＥＣの他の要素がそうではないとしても、
「工程の本当に良い考え」にすでに成熟させられます。しかしながら、ロー
カルリゾルバとそれらの「デフォルト」再帰ネームサーバ間のトラフィック
を守るためにＴＳＩＧを使うことはまだもっと多くの仕事を必要とします。
4.2 Does DNSSEC work? Is it the right approach?
4.2 ＤＮＳＳＥＣが動きますか？それは正しいアプローチですか？
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.
現在、提案など、仕様書を作ることに多くの取り組みがあります。この時点
で仕様書を判断する取り組み、特にＮＸＴレコードと可能な取り換えの価値
について、があります。
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.
鍵と署名レコードの価値にほとんど問題があると思われません。ゾーン境界
線を超える鍵認証についてまだいくつかの必要な研究があります。このよう
な仕事は少なくとも予定されます。
4.3 How will client software make use of DNSSEC?
4.3 どのようにクライアントソフトウェアがＤＮＳＳＥＣを利用するでしょうか？
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.
既存のアプリケーションで、機能を遂行するためにＤＮＳＳＥＣを直接に使
用するようにする多くの取り組みがあります。
When or whether DNSSEC will be understood in the (using POSIX-like
terms) operating systems "gethostbyname" and similar routines has not
been addressed.
１つのそのような例がセキュアシェルです。「gethostbyname」と類似のルー
チンが扱われていない、（ＰＯＳＩＸのような用語を使っている）オペレー
ティング・システムで、ＤＮＳＳＥＣが理解されるのか、いつなのか。
4.4 What are the remaining issues?
4.4 残っている問題は何ですか？
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?
まだ少数のプロトコル問題があります。ＮＸＴ資源レコードは正真正銘デー
タが存在しないことを示す手段を供給するよう意図されます。問題は、提案
された解決が、一部の目から見ての、問題より悪いかもしれないということ
です。ＤＮＳＥＸＴワーキンググループで考慮中の代わりの提案、ＮＯ資源
レコード、があります。現在動いているＤＮＳＥＸＴは次の質問を考慮して
います：正真正銘データの存在を否定する必要がありますか、もしそうなら、
ＮＸＴ（現在使用）とＮＯのどちらがいいですか？
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.
もう１つのあまり定義されていない問題が子の署名の親認証のためにメカニ
ズムです。これのプロトコル要素が安定しているけれども、操作上の考慮は
そうではなく、２章で努力によって証拠づけられるように言わています。Ｄ
ＮＳＳＥＣ相互作用が同じく標準登記所−登記係プロトコル上の論議で参照
されました。
5.0 Progressing to Draft Standard
5.0 ドラフト標準への進捗
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.
ＤＮＳＳＥＣのＩＥＴＦゴールは標準化手順[RFC 2026]を通しての文書の進
捗です。現在、ＲＦＣ２５３５は標準化要求レベルにおいて２番目の繰り返
しです。もう一度提案されたサイクルが必要です。これの後の、次のゴール
はドラフトです。
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.
ドラフト標準レベルを通過するために、２つの主な必要条件が満たされなく
てはなりません。２つ以上の協同使用可能な実装があるに違いありません。
十分な成功した運用経験が同じくなければなりません。
5.1 Revision of RFC 2535 via DNSEXT
5.1 ＤＮＳＥＸＴによるＲＦＣ２５３５の修正
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.
ＤＮＳＥＸＴは間もなく、実装とテスト経験に基いて更新と明確化のため、
ＲＦＣ２５３５仕様書（とその支持文書）の書き直しを始めるでしょう。
5.2 Operations document(s) via DNSOP
5.2 ＤＮＳＯＰによるオペレーション文書
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.
ＤＮＳＯＰはＤＮＳＳＥＣ活動の上に基くオペレーション文書のフォーラム
であり続けるでしょう。共同体がこのグループにもっと多くの文書を供給す
る必要があります。
5.3 Interoperability
5.3 相互運用性
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.
ＤＮＳＳＥＣの相互運用性の証明、ＤＮＳＳＥＣの仕事を行う２つの異なっ
た実装の対話の意味することは、今日まで、ただＢＩＮＤだけが真剣にＤＮ
ＳＳＥＣを実装しているので、問題があります。他のＤＮＳＳＥＣ機能の部
分的な実装があります、それで部分的な互換性実演の可能性は存在するかも
しれません。
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.
ミーティングの間に、明記された目標に対して、第２のＤＮＳＳＥＣ実装に
１８カ月が必要とされることは悟られました。部屋の中の人々が、これにつ
いて出来ることを始めるだろうと、述べていました。
6.0 Acknowledgements
6.0 謝辞
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).
次の人々はミーティングに出席して、そして／あるいはこの報告のための文
章を供給しました（順不同）：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 Considerations
7.0 ＩＡＮＡの考慮
This document does not involve assigned numbers in any way.
この文書は番号割当を伴いません。
8.0 Security Considerations
8.0 セキュリティの考慮
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.
この文書は、ＤＮＳのセキュリティ拡張の議論であるけれども、これ自身セ
キュリティに影響を与えません。セキュリティ問題が起こるところで、それ
らは適切な文書のセキュリティ考慮で論じられるでしょう。
9.0 References
9.0 参考文献
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.
ＲＦＣのテキストは次のＵＲＬを求めることでWebブラウザで検索されるか
もしれません：ftp://ftp.isi.edu/in-notes/rfc<wxyz>.txt、「wxyz」が
ＲＦＣ番号です。
[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 Editor's Address
10.0 著者のアドレス
Edward Lewis
3060 Washington Rd (Rte 97)
Glenwood, MD 21738
Phone: +1(443)259-2352
EMail: lewis@tislabs.com
11.0 Full Copyright Statement
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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。