RFC3755 日本語訳

Network Working Group                                          S. Weiler
Request for Comments: 3755                                  SPARTA, Inc.
Updates: 3658, 2535                                             May 2004
Category: Standards Track

コメントを求めるワーキンググループS.ウィーラー要求をネットワークでつないでください: 3755のスパルタInc.アップデート: 3658、2535年2004年5月のカテゴリ: 標準化過程

        Legacy Resolver Compatibility for Delegation Signer (DS)

代表団署名者のための遺産レゾルバの互換性(DS)

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Copyright(C)インターネット協会(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.

DNS Security(DNSSEC)仕様が発展するのに従って、DNSSECリソース記録(RRs)の構文と意味論は変化しました。 多くの配備されたネームサーバがこれらの意味論の異形を理解しています。 これらの意味論の以前のバージョンを理解しているレゾルバが新しい代表団署名者意味論を理解している正式のサーバについて質問するとき、危険な相互作用は起こることができます、非安全にされたゾーンが「非-溶解性」であることを引き起こす少なくとも1つの失敗シナリオを含んでいて。 このドキュメントは、それらの相互作用を避けるためにDNSSEC RRs(SIG、KEY、およびNXT)のタイプコードとニーモニックを変えます。

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.

DNSSECプロトコルが構文と意味論は完全に互換性があるというわけではない多くの繰り返しでありました。 これはプロトコルを提案する普通の過程の一部として起こりました、それを実行して、インターネットのますます複雑でさまざまの環境でそれをテストして、初期のProposed Standardの定義を洗練して。 DNSSECの場合では、過程はDNSの臨界、広い展開、および毎日の操作上の複雑さを最小にしている間にセキュリティを加える必要性によって複雑にされました。

   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

前のDNS仕様のための弱い領域はレゾルバの振舞いを指定することにおいて、詳細の不足です、主に一人で作成者がレゾルバ機能の多くの詳細を決定するのを残して。 DNSSEC仕様があって、広いバラエティーがあるなった中でさばかれたコードを持っている繰り返しの数に結合されたこれ

Weiler                      Standards Track                     [Page 1]

RFC 3755          Legacy Resolver Compatibility for DS          May 2004

ウィーラーStandardsは2004年5月にDSのためにRFC3755遺産レゾルバの互換性を追跡します[1ページ]。

   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.

振舞い。 このバラエティーで、プロトコル変化がすべての配備されたレゾルバによってどう扱われるかを予測するのは難しくなります。 変化が容認できないか壊滅的な失敗さえ引き起こすというリスクで、プロトコル変化を設計して、配備するのは難しくなります。 構造プロトコル変化にはその危険を管理するための1つの戦略が、既存のレゾルバが彼らを混乱させるか、または望ましくない故障モードの引き金となるかもしれない入力を完全に無視できるように、あります。

   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.

このドキュメントは[RFC2535]の意味論と非互換なNXT RRのためにDelegation Signer(DS)の新しい意味論の[RFC3658]導入で引き起こされたその特定の問題を訴えます。 DS意識しているサーバによって提供された答えはRFC2535を実行する何人かのレゾルバで容認できない故障モードの引き金となることができます。RFCは、DSをゾーンと契約するためにすばらしい行動を妨げるものを提供します。 本書では定義された変化は増加のためにDSの展開を許します。

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.

本書では、「unsecure代表団」という用語はDS記録が全く親に現れないどんな代表団も意味します。 「unsecure紹介」は、NS RRsetを含む親からの答えと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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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.

代表団Signer(DS)はRFC2535の意味論と非互換なNXT RRのために新しい意味論を紹介します。 RFC2535では、NXT記録が、非存在証拠の一部として返すのに必要であっただけです。 DSと共に、unsecure紹介はNSに加えてNXTとSIG(NXT)の形のDS RRの非存在の証拠を返します。 RFC2535はレゾルバはどのようにRCODE=0、AA=0と共に応答を解釈して、権威部でNSとNXTの両方を解釈することになっているかを指定しませんでした。 要求された記録の非存在の証拠としてNXTとのどんな答えも解釈する広く配備された2535年について意識しているレゾルバもあります。 これは、2535年について意識しているレゾルバに、目に見えないunsecure代表団をもたらして、DNSSECが危害を加えてはいけないという基本的な建築原則に違反します--ゾーンの調印は非安全にされた代表団の解決を防いではいけません。

2.  Possible Solutions

2. 可能なソリューション

   This section presents several solutions that were considered.
   Section 3 describes the one selected.

このセクションは考えられたいくつかの解決策を提示します。 セクション3は選択されたものについて説明します。

Weiler                      Standards Track                     [Page 2]

RFC 3755          Legacy Resolver Compatibility for DS          May 2004

ウィーラーStandardsは2004年5月にDSのためにRFC3755遺産レゾルバの互換性を追跡します[2ページ]。

2.1.  Change SIG, KEY, and NXT type codes

2.1. 変化SIG、KEY、およびNXTはコードをタイプします。

   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.

上で説明された問題を避けるために、遺産の(RFC2535意識する)のレゾルバは、権威部でNXT記録を含んでいるunsecure紹介を見るのから妨げられる必要があります。 それをする最も簡単な方法はSIG、KEY、および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.

これへの明らかな欠点は新しいレゾルバが古いRRsを契約されたゾーンを有効にすることができないということです。 しかしながら、この問題がDSによって行われた変更のために既に存在していて、古いRRs(DSの互換性の問題を持つ)を理解しているレゾルバは2535でサインされたゾーンよりはるかに一般的です。

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.

NXTを含んでいるNXTタイプコードかタイプコードの別の部分集合だけを変えることによって、unsecure紹介に関する観測された問題を記述できるでしょう。 これには、見かけの簡単さの美徳がありますが、それは、新しい問題を紹介するか、または十分遠くに行く危険を冒しません。 より多くの両立し難いことがDSと以前の意味論の間に存在するのは、かなり可能です。 また、遺産レゾルバは、NXTsを見つけることができない間、彼らが認識する記録(SIGとKEY)を見ることによって、混乱するかもしれません。 明らかに壊されないそれを修理するのが不要に思えるかもしれませんが、すぐにタイプコードのすべてを変えるのははるかに清潔です。 これは完全にDNSSECに目をくらまされた遺産レゾルバとツールを置き去りにするでしょう--それらは未知の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].

DS意味論で遺産レゾルバがDNSSEC記録を見るのを妨げる別の方法は正式のサーバにDS意識しているレゾルバにそのデータを送らせるだけであることです。 DS-認識(試験的に"DA"と呼ばれる)に合図するために新しいEDNS0フラグビットを割り当てて、正式のサーバを発信させると単にDAビットによる質問に対応したDNSSECデータが設定するこれが達成されるよう提案されました。 おそらく、このビットが取って代わるだろう、[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.

すべての2535年について意識しているレゾルバが彼らが理解していない出ているEDNS0旗のゼロに合っている場合にだけ、この解決策は十分です。 1つが変わりがない状態でDAビットを通り抜けるなら、それはまだ新しい意味論を見ているでしょうに、そして、たぶん、unsecure代表団を見ないでしょう。 あらゆるDNS実現がどのように未知のEDNS0旗を扱うかを知るのが非実用的であるので、これは普遍的な解決策ではありません。 もっとも、変化に加えてRRがコードをタイプすると考えることができました。

Weiler                      Standards Track                     [Page 3]

RFC 3755          Legacy Resolver Compatibility for DS          May 2004

ウィーラーStandardsは2004年5月にDSのためにRFC3755遺産レゾルバの互換性を追跡します[3ページ]。

2.4.  Increment the EDNS version

2.4. EDNSバージョンを増加してください。

   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]で定義されるすべての既存の実現が支持するより高いバージョンを拒絶するという前提で付番して、保有するEDNSを増加することである、DNSSEC認識のための信号としてビットをしてください。 このアプローチはテストされていません。

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.

標準化過程RFC2535と[RFC2065]によって定義されるようにDNSSECを理解して、それらのドキュメントの下の仕様のため非存在証拠としてNXTとのどんな答えも解釈するDNSレゾルバの大きい配備されたベースがあります。 ゾーン所有者には、それがそうである限り、unsecure代表団を含むどんなゾーンにもサインしない強い動機があるでしょう、それらの代表団がそのような大きいインストールされたベースに目に見えないといけないので。 これはDNSSEC採用を劇的に遅くするでしょう。

   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.

残念ながら、サインされたゾーンがなければ、レゾルバのオペレータがDNSSECの新しいバージョンを支持するために彼らのソフトウェアをアップグレードさせるどんな明確な誘因もありません、RFC3658で定義されるように。 史料は、レゾルバがめったにアップグレードしないで、また古いネームサーバコードが決して消え失せないのを示します。

   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.

むしろ、プロトコル変化でこのその問題を訴えると、年間unsecure代表団をゾーンと契約する前にレゾルバがナチュラル・プロセスでアップグレードするのを待っているより、行動を妨げるものがすぐに、ゾーンにサインするために取り除かれて、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.

このドキュメントはSIG、KEY、およびNXTのタイプコードを変えます。 このアプローチは最も清潔で上で議論した中で最も安全なものです、主に未知のタイプコードを受け取るレゾルバの振舞いがよく理解されているので。 また、このアプローチは最も多くのテストを受けました。

   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.

また、操作上の混乱を避けるために、これらのRRsのためにニーモニックを変えるのも必要です。 DNSKEYはKEYへの交換品になるでしょう、ニーモニックが、これらのキーがアプリケーション使用のためのものでないことを示していて、[RFC3445]単位で。 RRSIG(リソースRecord SIGnature)はSIGに取って代わるでしょう、そして、NSEC(次のSECure)はNXTを取り替えるでしょう。 これらの新しいタイプは古い型の後任に完全になります、SIG(0)[RFC2931]とTKEY[RFC2930]が、SIGとKEYを使用し続けるのを除いて。

Weiler                      Standards Track                     [Page 4]

RFC 3755          Legacy Resolver Compatibility for DS          May 2004

ウィーラーStandardsは2004年5月にDSのためにRFC3755遺産レゾルバの互換性を追跡します[4ページ]。

   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:

新しいタイプは以下を除いたRFC2535とRFC3658にまさに同じ構文とSIG、KEY、およびNXTのための指定されるとしての意味論を持つでしょう:

   1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC
      RRs MUST NOT be compressed,

1) [RFC3597]と一致していて、RRSIGとNSEC RRsに埋め込まれたドメイン名を圧縮してはいけません。

   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 RRsの埋め込まれたドメイン名がDNSSEC標準形と注文の目的と平等比較のためにdowncasedされない。

   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には、未定義の意味論があります。 そのようなリソース記録の意味はIETF Standards Actionによって定義されるだけであるかもしれません。

   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が未知のRRsとしてそれらを扱って、SHOULD NOTはどんな特別な意味も彼らに割り当てるか、またはどんな特別な処理も彼らに与えます。 それはDNSSEC合法化か他のDNSの操作上の意志決定にそれらを使用してはいけません。 例えば、レゾルバは、RRSIGsを有効にするのにSIGを有効にするか、またはKEYsを使用するのにDNSKEYsを使用してはいけません。 SIG、KEY、またはNXT RRsがゾーンに含まれているなら、彼らは特別な処理を受けてはいけません。 例として、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.

前のドキュメントへの明確化として、いくつかの積極的な応答(特にワイルドカード証拠とunsecure紹介)が、NSEC RRsを含むでしょう。 単にNSECを含んでいるので、レゾルバはNSEC RRsとの答えを否定的な返答として扱ってはいけません。

4.  IANA Considerations

4. IANA問題

4.1.  DNS Resource Record Types

4.1. DNSリソースレコード種類

   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.

このドキュメントは、DNS Resource Record Typesのためにそれぞれタイプ46、47、および48をRRSIG、NSEC、およびDNSKEY RRsに選任することによって、IANA登録をアップデートします。

   Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
   TKEY [RFC2930] use only.

タイプ24と25(SIGとKEY)はSIG(0)[RFC2931]とTKEY[RFC2930]使用だけのために保有されます。

   Type 30 (NXT) should be marked as Obsolete.

タイプ30(NXT)はObsoleteとしてマークされるべきです。

Weiler                      Standards Track                     [Page 5]

RFC 3755          Legacy Resolver Compatibility for DS          May 2004

ウィーラーStandardsは2004年5月にDSのためにRFC3755遺産レゾルバの互換性を追跡します[5ページ]。

4.2.  DNS Security Algorithm Numbers

4.2. DNSセキュリティアルゴリズム番号

   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.

ゾーン調印(DNSSEC)と取引セキュリティー対策(SIG(0)とTKEY)が異なったセットのアルゴリズムを使用するのを許容するなら、既存の「DNSセキュリティアルゴリズム番号」登録は、それぞれのアルゴリズムの適用性を含むように変更されます。 明確に、2つの新しいコラムが登録に加えられます、各アルゴリズムがゾーン調印、取引セキュリティー対策、または両方に使用されるかもしれないかどうかを示して。 DNSKEY、RRSIG、およびDS RRsでゾーン調印に、使用可能なアルゴリズムだけを使用してもよいです。 SIGとKEY RRsでSIG(0)、そして/または、TSIGに、使用可能なアルゴリズムだけを使用してもよいです。

   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].

Indirect(アルゴリズム252)以外のすべての現在定義されたアルゴリズムが取引セキュリティー対策に使用可能なままで残っています。ゾーン調印に、RSA/SHA-1[RFC3110]、DSA/SHA-1[RFC2536]、および個人的なアルゴリズム(253と254をタイプする)だけを使用してもよいです。 登録がそれぞれのアルゴリズムの要件レベルを含まないことに注意してください、唯一です。アルゴリズムは与えられた目的に使用されるのであるかもしれないかどうか 例えば、取引セキュリティー対策のために許容されている間、[RFC3110]あたりRSA/MD5は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]セクション7からのプレゼンテーション形式アルゴリズムニーモニックは登録に加えられます。 このドキュメントは簡略記憶RSASHA1をRSA/SHA-1に割り当てます。

   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.

従来と同様、この登録の新しいアルゴリズムの課題はIETF Standards Actionを必要とします。 さらに、アルゴリズムニーモニックか適用性の変更はIETF Standards Actionを必要とします。 新しいアルゴリズムを定義するドキュメントは、アルゴリズムの適用性を記述しなければならなくて、プレゼンテーションニーモニックをアルゴリズムに割り当てるはずです。

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は旗がさばく16ビットを含んでいます。 このドキュメントは旗がさばく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.

初めは、この登録はビット7(ZONEビット)のための課題を含むだけです。 ビット0-6と8-15は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は8ビットのプロトコル分野を含んでいます。 この分野への唯一の定義された値が3(DNSSEC)です。 他の値は全く許容されていません、したがって、IANA登録が全くこの分野に必要ではありません。

Weiler                      Standards Track                     [Page 6]

RFC 3755          Legacy Resolver Compatibility for DS          May 2004

ウィーラーStandardsは2004年5月にDSのためにRFC3755遺産レゾルバの互換性を追跡します[6ページ]。

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.

タイプコードを変えると、コードは決して運動させられない遺産レゾルバの経路にむけて発つでしょう。 主にそれらのコード経路が頻繁な精査を得ないので、Unexercisedコード経路はセキュリティーホールの頻繁な源です。

   Doing nothing, as described in section 2.5, will slow DNSSEC
   deployment.  While this does not decrease security, it also fails to
   increase it.

セクション2.5で説明されるように何もしないと、DNSSEC展開は遅くされるでしょう。 これはセキュリティを下げませんが、また、それはそれを増加させません。

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.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
             2535, March 1999.

[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。

   [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
             (DNS)", RFC 2536, March 1999.

[RFC2536]イーストレーク、D.と、「ドメインネームシステム(DNS)におけるDSAキーとSIG」(RFC2536)は1999を行進させます。

   [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
             RFC 2930, September 2000.

[RFC2930]イーストレーク、D.、「DNS(TKEY RR)のための秘密鍵設立」、RFC2930、2000年9月。

   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
             (SIG(0)s)", RFC 2931, September 2000.

D.、「DNS要求と取引署名(SIG(0)s)」、RFC2931 2000年9月の[RFC2931]イーストレーク。

   [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
             Name System (DNS)", RFC 3110, May 2001.

[RFC3110] イーストレークと、D.と、「ドメインネームシステム(DNS)におけるRSA/SHA-1SIGとRSAキー」(RFC3110)は2001がそうするかもしれません。

   [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
             (RR)", RFC 3658, December 2003.

[RFC3658]グドムンソン、O.、「代表団署名者(DS)リソース記録(RR)」、RFC3658、2003年12月。

Weiler                      Standards Track                     [Page 7]

RFC 3755          Legacy Resolver Compatibility for DS          May 2004

ウィーラーStandardsは2004年5月にDSのためにRFC3755遺産レゾルバの互換性を追跡します[7ページ]。

6.2.  Informative References

6.2. 有益な参照

   [RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
             Security Extensions", RFC 2065, January 1997.

[RFC2065] イーストレークと3番目とD.とC.コーフマン、「ドメインネームシステムセキュリティ拡大」、RFC2065、1997年1月。

   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
             2671, August 1999.

[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡大メカニズム」、RFC2671、1999年8月。

   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
             3225, December 2001.

[RFC3225] コンラッド、D.、「DNSSECのレゾルバサポートを示します」、RFC3225、2001年12月。

   [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
             Resource Record (RR)", RFC 3445, December 2002.

[RFC3445] RFC3445、「主要なリソース記録(RR)の範囲を制限し」て、マッシー、D.、およびS.は上昇して、12月は2002です。

   [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
             (RR) Types", RFC 3597, September 2003.

[RFC3597]グスタファソン、A.、「未知のDNSリソース記録(RR)タイプの取り扱い」、RFC3597、2003年9月。

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.

ここで紹介された変化と代替手段の分析には、多くの貢献者がありました。 見落とされた人はだれもを無断借用させてもらってそれらは: マイケル・グラフ、ジョハンIhren(オラフKolkman)はKosters、Ed Lewis、ビル・マニング、ポールVixie、およびスザンヌ・ウルフをマークします。

   Thanks to Jakob Schlyter and Mark Andrews for identifying the
   incompatibility described in section 1.2.

ジェイコブSchlyterとマーク・アンドリュースにセクション1.2で説明された不一致を特定してくださってありがとうございます。

   In addition to the above, the author would like to thank Scott Rose,
   Olafur Gudmundsson, and Sandra Murphy for their substantive comments.

上記に加えて、作者は彼らの実質的なコメントについてスコット・ローズ、Olafurグドムンソン、およびサンドラ・マーフィーに感謝したがっています。

8.  Author's Address

8. 作者のアドレス

   Samuel Weiler
   SPARTA, Inc.
   7075 Samuel Morse Drive
   Columbia, MD 21046
   USA

サミュエルウィーラースパルタInc.7075サミュエル・モースDrive MD21046コロンビア(米国)

   EMail: weiler@tislabs.com

メール: weiler@tislabs.com

Weiler                      Standards Track                     [Page 8]

RFC 3755          Legacy Resolver Compatibility for DS          May 2004

ウィーラーStandardsは2004年5月にDSのためにRFC3755遺産レゾルバの互換性を追跡します[8ページ]。

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.

Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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はこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Weiler                      Standards Track                     [Page 9]

ウィーラー標準化過程[9ページ]