この文書はRFC3755の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group S. Weiler
Request for Comments: 3755 SPARTA, Inc.
Updates: 3658, 2535 May 2004
Category: Standards Track
Legacy Resolver Compatibility for Delegation Signer (DS)
委任署名（ＤＳ）の旧式なリゾルバ互換性
Status of this Memo
この文書の状態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
概要
As the DNS Security (DNSSEC) specifications have evolved, the syntax
and semantics of the DNSSEC resource records (RRs) have changed.
Many deployed nameservers understand variants of these semantics.
Dangerous interactions can occur when a resolver that understands an
earlier version of these semantics queries an authoritative server
that understands the new delegation signer semantics, including at
least one failure scenario that will cause an unsecured zone to be
unresolvable. This document changes the type codes and mnemonics of
the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions.
ＤＮＳセキュリティ（ＤＮＳＳＥＣ）仕様が進展するにつれて、ＤＮＳＳＥ
Ｃ資源レコード（ＲＲ）の構文と語義は変化しました。多くの配置されたネー
ムサーバがこれらの様々な意味を理解します。古い意味を理解するリゾルバ
が新しい署名委任の意味を問合せる時に、少なくとも安全でないゾーンが解
決できなくなる１つの失敗のシナリオがある、危険な対話が生じます。この
文書はそれらの対話を避けるためのＤＮＳＳＥＣ資源レコード(ＲＲ)のタイ
プコードと名称（ＳＩＧ、ＫＥＹ、ＮＸＴ）を変えます。
1. Introduction
1. はじめに
The DNSSEC protocol has been through many iterations whose syntax and
semantics are not completely compatible. This has occurred as part
of the ordinary process of proposing a protocol, implementing it,
testing it in the increasingly complex and diverse environment of the
Internet, and refining the definitions of the initial Proposed
Standard. In the case of DNSSEC, the process has been complicated by
DNS's criticality and wide deployment and the need to add security
while minimizing daily operational complexity.
ＤＮＳＳＥＣプロトコルは構文と語義の互換性が完全できない反復でした。
これは、プロトコル提案と実装とインターネットのますます複雑で多様な環
境でのテストと初期の標準提案の定義の改良の一般的標準提案手順の一部の
結果として起こりました。ＤＮＳＳＥＣの場合、手順はＤＮＳの重要性と広
い実装と、毎日の操作の複雑さを最小にしながら、セキュリティを加える必
要性によって複雑にされました。
A weak area for previous DNS specifications has been lack of detail
in specifying resolver behavior, leaving implementors largely on
their own to determine many details of resolver function. This,
combined with the number of iterations the DNSSEC specifications have
been through, has resulted in fielded code with a wide variety of
behaviors. This variety makes it difficult to predict how a protocol
change will be handled by all deployed resolvers. The risk that a
change will cause unacceptable or even catastrophic failures makes it
difficult to design and deploy a protocol change. One strategy for
managing that risk is to structure protocol changes so that existing
resolvers can completely ignore input that might confuse them or
trigger undesirable failure modes.
前のＤＮＳ仕様の弱い部分はリゾルバの動作の指定で、主に独立な実装者に
リゾルバの機能の多くの詳細の決定を委ねる、詳細の欠如でした。これは、
ＤＮＳＳＥＣ仕様の繰り返しと混ざり、多種多様な動作のコードをもたらし
ました。この多種多様さはプロトコル変更がすべての配置されたリゾルバに
どう処理されるか予測することを難しくします。変更により、受け入れ難い
かさらに大惨事の障害を起こすというリスクは、プロトコル変更を設計し展
開することを難しくします。そのリスクを処理する１つの戦略は、既存のリ
ゾルバが混乱するか望ましくない失敗を引き起こすかもしれない入力を完全
に無視することができるように、プロトコル構造の変更です。
This document addresses a specific problem caused by Delegation
Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR
that are incompatible with the semantics in [RFC2535]. Answers
provided by DS-aware servers can trigger an unacceptable failure mode
in some resolvers that implement RFC 2535, which provides a great
disincentive to sign zones with DS. The changes defined in this
document allow for the incremental deployment of DS.
この文書は委任署名（ＤＳ）[RFC3658]導入により、ＮＸＴ資源レコードにも
たらされた[RFC2535]と互換性のない新しい意味によって起こされた、特定の
問題を扱います。ＤＳ対応サーバから供給された応答はＲＦＣ２５３５を実
装するあるリゾルバで受け入れ難い失敗状態を引き起こし、これはＤＳのあ
る署名ゾーンのを妨げます。この文書で定義された変更はＤＳの逐次的な展
開を考慮します。
1.1. Terminology
1.1. 用語
In this document, the term "unsecure delegation" means any delegation
for which no DS record appears at the parent. An "unsecure referral"
is an answer from the parent containing an NS RRset and a proof that
no DS record exists for that name.
この文書で、用語「非安全委任」はDSレコードが親に現われない委任を意味
します。「非安全照会」は、ＮＳ資源レコード集合と、その名前のＤＳレコー
ドが存在しない証明を含む、親からの応答です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
この文書のキーワードは"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
[RFC2119]で記述されるように解釈されるはずです。
1.2. The Problem
1.2. 問題
Delegation Signer (DS) introduces new semantics for the NXT RR that
are incompatible with the semantics in RFC 2535. In RFC 2535, NXT
records were only required to be returned as part of a non-existence
proof. With DS, an unsecure referral returns, in addition to the NS,
a proof of non-existence of a DS RR in the form of an NXT and
SIG(NXT). RFC 2535 didn't specify how a resolver was to interpret a
response with RCODE=0, AA=0, and both an NS and an NXT in the
authority section. Some widely deployed 2535-aware resolvers
interpret any answer with an NXT as a proof of non-existence of the
requested record. This results in unsecure delegations being
invisible to 2535-aware resolvers and violates the basic
architectural principle that DNSSEC must do no harm -- the signing of
zones must not prevent the resolution of unsecured delegations.
委任署名者（ＤＳ）は、ＲＦＣ２５３５の意味と非互換なＮＸＴ資源レコー
ドの新しい意味を導入します。ＲＦＣ２５３５で、ＮＸＴレコードは非存在
の証明の一部としてだけ返されることが要求されました。ＤＳで、非安全照
会がＮＳ以外に、ＮＸＴと署名（ＮＸＴ）の形で、ＤＳ資源レコードの非実
在の証明を返します。ＲＦＣ２５３５はリゾルバがRCODE=0で、AA=0で、ＮＳ
とＮＸＴの両方が権威部にある応答を翻訳するか明示しませんでした。ある
広く配置された２５３５対応リゾルバがNXTを伴う応答を求められたレコード
の非実在の証明と解釈します。これは非安全委任が２５３５対応リゾルバに
見えないという結果になり、そしてＤＮＳＳＥＣが害をしてはならないとい
う基本的な構築原則に違反します−ゾーンの署名は非安全委任の解決を妨げ
てはなりません。
2. Possible Solutions
2. 可能な解決策
This section presents several solutions that were considered.
Section 3 describes the one selected.
この章は考慮されたいくつかの解決策を示します。３章が選択された解決策
を記述します。
2.1. Change SIG, KEY, and NXT type codes
2.1. 署名と鍵とＮＸＴの種別コード変更
To avoid the problem described above, legacy (RFC2535-aware)
resolvers need to be kept from seeing unsecure referrals that include
NXT records in the authority section. The simplest way to do that is
to change the type codes for SIG, KEY, and NXT.
上記の問題を避けるために、旧式（ＲＦＣ２５３５対応）リゾルバがが権威
章でＮＸＴレコードを含む非安全照会を見ることを阻止される必要がありま
す。それをする最も単純な方法は署名と鍵とＮＸＴの種別コードを変えるこ
とです。
The obvious drawback to this is that new resolvers will not be able
to validate zones signed with the old RRs. This problem already
exists, however, because of the changes made by DS, and resolvers
that understand the old RRs (and have compatibility issues with DS)
are far more prevalent than 2535-signed zones.
この明白な欠点は、新しいリゾルバが古い資源レコードと一緒に署名された
ゾーンを有効にすることが可能でないであろうということです。しかしなが
ら、この問題はＤＳによってされた変更のためにすでに存在します、そして
古い資源レコードを理解し（そしてＤＳ互換性問題を持つ）リゾルバは２５
３５署名ゾーンよりはるかに存在します。
2.2. Change a subset of type codes
2.2. タイプコードの一部を変更
The observed problem with unsecure referrals could be addressed by
changing only the NXT type code or another subset of the type codes
that includes NXT. This has the virtue of apparent simplicity, but
it risks introducing new problems or not going far enough. It's
quite possible that more incompatibilities exist between DS and
earlier semantics. Legacy resolvers may also be confused by seeing
records they recognize (SIG and KEY) while being unable to find NXTs.
Although it may seem unnecessary to fix that which is not obviously
broken, it's far cleaner to change all of the type codes at once.
This will leave legacy resolvers and tools completely blinded to
DNSSEC -- they will see only unknown RRs.
非安全照会における観察された問題は、ＮＸＴ種別コードあるいはＮＸＴを
含む他の種別コードの一部だけを変えることにで扱えます。これは外見上明
白な単純さの長所がありますが、あえて新しい問題を導入するか、あるいは
十分でありません。ＤＳと以前の意味の間にもっと多くの不適合が存在する
ことは非常にありえます。旧式なリゾルバが、ＮＸＴを見ることが不可能で
あるが、認識するレコード（署名と鍵）を見ることで同じく困惑しているか
もしれません。明らかに壊れていないのに修理することは不必要に思われる
かもしれないけれども、すぐに種別コードのすべてを変えるのははるかにき
れいです。これはＤＮＳＳＥＣをわからない旧式なリゾルバとツールをその
ままにするでしょう−それらはただ未知の資源レコードを見るだけでしょう。
2.3. Replace the DO bit
2.3. ＤＯビットの置換え
Another way to keep legacy resolvers from ever seeing DNSSEC records
with DS semantics is to have authoritative servers only send that
data to DS-aware resolvers. It's been proposed that assigning a new
EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), and
having authoritative servers send DNSSEC data only in response to
queries with the DA bit set, would accomplish this. This bit would
presumably supplant the DO bit described in [RFC3225].
旧式リゾルバがＤＳの意味のＤＮＳＳＥＣレコードを見ることを阻止するも
う１つの方法は、正式なサーバがＤＳ対応リゾルバだけにデータを送ること
です。ＤＳ対応を示す新しいＥＤＮＳＯフラグ（試験的に「ＤＡ」と呼ばれ
る）を割り当て、正式サーバがＤＡビットを設定された問合せにだけＤＮＳ
ＳＥＣデータを送るようにすることで、これを達成することが提案されまし
た。このビットは多分[RFC3225]で記述したＤＯビットを置き換えるでしょう。
This solution is sufficient only if all 2535-aware resolvers zero out
EDNS0 flags that they don't understand. If one passed through the DA
bit unchanged, it would still see the new semantics, and it would
probably fail to see unsecure delegations. Since it's impractical to
know how every DNS implementation handles unknown EDNS0 flags, this
is not a universal solution. It could, though, be considered in
addition to changing the RR type codes.
この解決策は、すべての２５３５対応リゾルバが理解しないＥＤＮＳＯフラ
グをゼロで設定する場合に限り十分です。もしＤＡビット変化させずに通過
させたら、これは新しい意味を見て、恐らく非安全委任の参照に失敗するで
しょう。すべてのＤＮＳ実装の未知のＥＤＮＳＯフラグの処理を知るのは非
実用的であるので、これは普遍的な解決策ではありません。けれども、資源
レコード種別コードを変えることに加えて考慮ができます。
2.4. Increment the EDNS version
2.4. ＥＤＮＳバージョンを増加
Another possible solution is to increment the EDNS version number as
defined in [RFC2671], on the assumption that all existing
implementations will reject higher versions than they support, and
retain the DO bit as the signal for DNSSEC awareness. This approach
has not been tested.
他の可能な解決策は、すべての既存の実装はサポートするより高いバージョ
ンを拒絶するとの仮定で、ＤＯビットをＤＮＳＳＥＣ対応としたまま
[RFC2671]で定義されたＥＤＮＳバージョン番号を増加させることです。この
方法は試されませんでした。
2.5. Do nothing
2.5. 何もしない
There is a large deployed base of DNS resolvers that understand
DNSSEC as defined by the standards track RFC 2535 and [RFC2065] and,
due to under specification in those documents, interpret any answer
with an NXT as a non-existence proof. So long as that is the case,
zone owners will have a strong incentive to not sign any zones that
contain unsecure delegations, lest those delegations be invisible to
such a large installed base. This will dramatically slow DNSSEC
adoption.
標準トラックＲＦＣ２５３５と[RFC2065]で定義されるＤＮＳＳＥＣを理解し
て、それらの文書の仕様下でＮＸＴを含む応答を非存在の証明として理解す
る、ＤＮＳリゾルバ実装が多数あります。それが本当である限り、ゾーン所
有者が、委任を多数の実装で見えなすることがないように、非安全委任を含
むゾーンに署名をしない強い誘因を持つでしょう。これは劇的にＤＮＳＳＥ
Ｃ採用を遅くするでしょう。
Unfortunately, without signed zones there's no clear incentive for
operators of resolvers to upgrade their software to support the new
version of DNSSEC, as defined in RFC 3658. Historical data suggests
that resolvers are rarely upgraded, and that old nameserver code
never dies.
不幸にも、署名されたゾーンがなければリゾルバオペレータが、ＲＦＣ３６
５８で定義されるＤＮＳＳＥＣの新しいバージョンをサポートするためにソ
フトウェアを更新する明確な誘因がありません。歴史的に見て、リゾルバが
めったに更新されず，そしてその古いネームサーバ規則は決して死にません。
Rather than wait years for resolvers to be upgraded through natural
processes before signing zones with unsecure delegations, addressing
this problem with a protocol change will immediately remove the
disincentive for signing zones and allow widespread deployment of
DNSSEC.
非安全委任の存在するゾーンに署名する前に、自然にリゾルバが更新される
のを待つより、このプロトコル変更における問題を扱うことはゾーン署名の
障害を除き、ＤＮＳＳＥＣの広範囲の展開を許すでしょう。
3. Protocol changes
3. プロトコル変更
This document changes the type codes of SIG, KEY, and NXT. This
approach is the cleanest and safest of those discussed above, largely
because the behavior of resolvers that receive unknown type codes is
well understood. This approach has also received the most testing.
この文書は署名と鍵とＮＸＴの種別コードを変えます。この方法は、未知の
種別コードを受け取るリゾルバの動作がかなり理解されるから、上に論じら
れた中で最もきれいで最も安全です。この方法は最も多くのテストを受けま
した。
To avoid operational confusion, it's also necessary to change the
mnemonics for these RRs. DNSKEY will be the replacement for KEY,
with the mnemonic indicating that these keys are not for application
use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace
SIG, and NSEC (Next SECure) will replace NXT. These new types
completely replace the old types, except that SIG(0) [RFC2931] and
TKEY [RFC2930] will continue to use SIG and KEY.
運用上の混乱を避けるために、これらの資源レコードの名称を変更する事も
必要です。DNSKEYが鍵の新しい名前で、これらの鍵が[RFC3445]のアプリケー
ションの使用のためでないことを示します。RRSIG（資源レコード署名)が署
名の新しい名前で、NSEC(次の安全)がＮＸＴの新しい名前です。SIG(0)
[RFC2931]と処理鍵[RFC2930]が署名と鍵を使い続ける以外、これらの新しい
種別は完全に古い種別を置き換えます。
The new types will have exactly the same syntax and semantics as
specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for
the following:
新しいタイプは、以下を除き、ＲＦＣ２５３５とＲＦＣ３６５８で署名と鍵
とＮＸＴに指定されるのと正確に同じ構文論と意味を持つでしょう：
1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC
RRs MUST NOT be compressed,
1) [RFC3597]に準じて、RRSIGとNSEC資源レコードの埋め込みのドメイン名が
圧縮されてはなりません(MUST NOT)。
2) Embedded domain names in RRSIG and NSEC RRs are not downcased for
purposes of DNSSEC canonical form and ordering nor for equality
comparison, and
2) RRSIGとNSEC資源レコードの埋め込みのドメイン名が、ＤＮＳＳＥＣの正
規形式と同一性比較のため、小文字にされてはなりません、そして。
3) An RRSIG with a type-covered field of zero has undefined
semantics. The meaning of such a resource record may only be
defined by IETF Standards Action.
3) 種別カバーフィールドがゼロのRRSIGの意味は不確定です。このような資
源レコードの意味はＩＥＴＦ標準化行動でだけ定義されるかもしれません。
If a resolver receives the old types, it SHOULD treat them as unknown
RRs and SHOULD NOT assign any special meaning to them or give them
any special treatment. It MUST NOT use them for DNSSEC validations
or other DNS operational decision making. For example, a resolver
MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs.
If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive
special treatment. As an example, if a SIG is included in a signed
zone, there MUST be an RRSIG for it. Authoritative servers may wish
to give error messages when loading zones containing SIG or NXT
records (KEY records may be included for SIG(0) or TKEY).
もしリゾルバが古いタイプを受け取るなら、それらを未知の資源レコードと
扱うべきで(SHOULD)、それらに特別な意味を割り当てるか特別な待遇を与え
るべきではありません(SHOULD NOT)。ＤＮＳＳＥＣ検証や他のＤＮＳ運用上
の決断にそれらを使ってはなりません(MUST NOT)。例えば、リゾルバがSIG検
証にDNSKEYを使ったり、RRSIG検証にKEYを使ってはなりません(MUST NOT)。
もしSIGやKEYやNXT資源レコードがゾーンに含まれる場合、特別な待遇を受け
てはなりません(MUST NOT)。例えば、もしSIGが署名ゾーンに含められるなら、
RRSIGがあるに違いありません。権威サーバが、SIGやNXTレコード（KEYレコー
ドがSIG(0)やTKEYのために含まれるかもしれない）を含むゾーンを読み込
む際に、エラーメッセージを与えることを望むかもしれません。
As a clarification to previous documents, some positive responses,
particularly wildcard proofs and unsecure referrals, will contain
NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as negative
answers merely because they contain an NSEC.
前の文書の明確化のため、ある積極的応答で、特にワイルドカード証明と非
安全照会、はNSEC資源レコードを含んでいるでしょう。リゾルバは、NSECを
含んでいるという理由だけで、NSEC資源レコードと一緒にある答えを否定的
な答えとして扱ってはなりません(MUST NOT)。
4. IANA Considerations
4. ＩＡＮＡ考慮
4.1. DNS Resource Record Types
4.1. ＤＮＳ資源レコードタイプ
This document updates the IANA registry for DNS Resource Record Types
by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs,
respectively.
この文書はRRSIGとNSECとDNSKEY資源レコードに、それぞれ種別４６と４７と
４８を割り当てることで、ＤＮＳ資源レコード種別のＩＡＮＡ登記所を更新
します。
Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
TKEY [RFC2930] use only.
種別２４と２５（SIGとKEY）がＳＩＧ（０）[RFC2931]と処理鍵[RFC2930]処
理鍵での使用のみのために維持されます。
Type 30 (NXT) should be marked as Obsolete.
種別３０（ＮＸＴ）が時代遅れと印しを付けられるべきです。
4.2. DNS Security Algorithm Numbers
4.2. ＤＮＳセキュリティアルゴリズム番号
To allow zone signing (DNSSEC) and transaction security mechanisms
(SIG(0) and TKEY) to use different sets of algorithms, the existing
"DNS Security Algorithm Numbers" registry is modified to include the
applicability of each algorithm. Specifically, two new columns are
added to the registry, showing whether each algorithm may be used for
zone signing, transaction security mechanisms, or both. Only
algorithms usable for zone signing may be used in DNSKEY, RRSIG, and
DS RRs. Only algorithms usable for SIG(0) and/or TSIG may be used in
SIG and KEY RRs.
ゾーン署名（ＤＮＳＳＥＣ）と処理セキュリティメカニズム（ＳＩＧ（０）
と処理鍵）で異なるアルゴリズムを許すために、既存の「ＤＮＳセキュリティ
アルゴリズム番号」登記所は、それぞれのアルゴリズムの適用性を含むため
に修正されます。特に、それぞれのアルゴリズムがゾーン署名と処理セキュ
リティメカニズムで使用できるかを示す、２つの新しい列が加えられます。
ただゾーン署名に有用なだけのアルゴリズムが、DNSKEYとRRSIGとDS資源レコー
ドで使われるかもしれません。ただSIG(0)とTSIGでだけ有用なアルゴリズム
がSIGとKEY資源レコードで使われるかもしれません。
All currently defined algorithms except for Indirect (algorithm 252)
remain usable for transaction security mechanisms. Only RSA/SHA-1
[RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and
254) may be used for zone signing. Note that the registry does not
contain the requirement level of each algorithm, only whether or not
an algorithm may be used for the given purposes. For example,
RSA/MD5, while allowed for transaction security mechanisms, is NOT
RECOMMENDED, per [RFC3110].
非直接（アルゴリズム２５２）以外のすべての現在定義されたアルゴリズム
は処理セキュリティメカニズムで有用なままでいます。ただＲＳＡ／ＳＨＡ−
１[RFC3110]とＤＳＡ／ＳＨＡ−１[RFC2536]とプライベートのアルゴリズム
（種別２５３と２５４）だけがゾーン署名に使われるかもしれません。登記
所は、アルゴリズムが所定の目的のために使われるか否かだけを含み、それ
ぞれのアルゴリズムの要求レベルを含んでいないことに注意を払ってくださ
い。例えば、ＲＳＡ／ＭＤ５は、処理セキュリティメカニズムに割り当てら
れるが、[RFC3110]で勧められません(NOT RECOMMENDED)。
Additionally, the presentation format algorithm mnemonics from
[RFC2535] Section 7 are added to the registry. This document assigns
RSA/SHA-1 the mnemonic RSASHA1.
さらに、[RFC2535]の７章からのプレゼンテーションフォーマットアルゴリズ
ムの名称が登記所に加えられます。この書類はＲＳＡ／ＳＨＡ−１の名称に
RSASHA１を割り当てます。
As before, assignment of new algorithms in this registry requires
IETF Standards Action. Additionally, modification of algorithm
mnemonics or applicability requires IETF Standards Action. Documents
defining a new algorithm must address the applicability of the
algorithm and should assign a presentation mnemonic to the algorithm.
前と同様に、この登記所での新しいアルゴリズムの割当てがＩＥＴＦ標準化
行動を必要とします。さらに、アルゴリズム名称や適用性の修正がＩＥＴＦ
標準化行動を必要とします。新しいアルゴリズムを定義している文書はアル
ゴリズムの適用性を扱わなくてはならなくて、アルゴリズムに名称を割り当
てるべきです。
4.3. DNSKEY Flags
4.3. DNSKEYフラグ
Like the KEY resource record, DNSKEY contains a 16-bit flags field.
This document creates a new registry for the DNSKEY flags field.
KEY資源レコードのように、DNSKEYは１６ビットのフラグフィールドを含んで
います。この文書はDNSKEYのフラグフィールドの新しい登記所を作ります。
Initially, this registry only contains an assignment for bit 7 (the
ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF
Standards Action.
初めに、この登記所はビット７（ゾーンビット）の割当だけを含んでいるだ
けです。ビット０-６と８-１５はＩＥＴＦ標準化行動でだけ割当て利用可能
です。
4.4. DNSKEY Protocol Octet
4.4. DNSKEYプロトコルオクテット
Like the KEY resource record, DNSKEY contains an eight bit protocol
field. The only defined value for this field is 3 (DNSSEC). No
other values are allowed, hence no IANA registry is needed for this
field.
KEY資源レコードのように、DNSKEYは８ビットのプロトコルフィールドを含ん
でいます。唯一のこのフィールドのための定義された値は３（ＤＮＳＳＥＣ）
です。他のどのような値も許されません、それ故ＩＡＮＡ登記所がこのフィー
ルドに必要とされません。
5. Security Considerations
5. セキュリティの考察
The changes introduced here do not materially affect security. The
implications of trying to use both new and legacy types together are
not well understood, and attempts to do so would probably lead to
unintended and dangerous results.
ここで紹介された変更は本質的にセキュリティに影響を与えません。新旧の
種別を一緒に使おうとする意味はうまく理解されません、そしてそうする試
みが恐らく思いがけない、そして危険な結果に導くでしょう。
Changing type codes will leave code paths in legacy resolvers that
are never exercised. Unexercised code paths are a frequent source of
security holes, largely because those code paths do not get frequent
scrutiny.
種別コードを変えることは旧式リゾルバで決して使われないコードパスを残
すでしょう。予期しないコードパスは、それらのコードパスが頻繁な精査を
されないことにより、セキュリティ・ホールの原因になりやすいです。
Doing nothing, as described in section 2.5, will slow DNSSEC
deployment. While this does not decrease security, it also fails to
increase it.
２.５章で記述されるように、何もしないことはＤＮＳＳＥＣ展開を遅くする
でしょう。これがセキュリティ管理を減少させないが、同時に増やし損ねます。
6. References
6. 参考文献
6.1. Normative References
6.1. 参照する参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
RFC 2930, September 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s)", RFC 2931, September 2000.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
6.2. Informative References
6.2. 有益な参考文献
[RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
Security Extensions", RFC 2065, January 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001.
[RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
7. Acknowledgments
7. 謝辞
The changes introduced here and the analysis of alternatives had many
contributors. With apologies to anyone overlooked, those include:
Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis,
Bill Manning, Paul Vixie, and Suzanne Woolf.
ここで紹介された変更と選択肢の分析は多くの貢献者がいます。見逃しがあ
ればすいませんが、以下を含みます：Michael GraffとJohan Ihrenと
Olaf KolkmanとMark KostersとEd LewisとBill ManningとPaul Vixieと
Suzanne Woolf。
Thanks to Jakob Schlyter and Mark Andrews for identifying the
incompatibility described in section 1.2.
１.２章で記述された不適合を識別することに対してJakob Schlyterと
Mark Andrewsに感謝します。
In addition to the above, the author would like to thank Scott Rose,
Olafur Gudmundsson, and Sandra Murphy for their substantive comments.
上記のほかに、著者は実質的なコメントに対してScott Roseと
Olafur GudmundssonとSandra Murphyに感謝します。
8. Author's Address
8. 著者のアドレス
Samuel Weiler
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
USA
EMail: weiler@tislabs.com
9. Full Copyright Statement
9. 著作権表示全文
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
著作権（Ｃ）インターネット学会（２００４）。この文書はＢＣＰ７８に含
まれる権利と許可と制限の適用を受け、そしてこの中に明らかにされる以外
は著者がすべての権利を維持します。
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。