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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
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セキュリティ（DNSSEC）仕様が進化してきたように、DNSSECリソースレコード（RR）の構文とセマンティクスが変更されました。多くの展開のネームサーバーは、これらのセマンティクスの変異体を理解しています。これらのセマンティクスの以前のバージョンを理解しリゾルバがセキュリティで保護されていないゾーンが解決できないことになります少なくとも一つの障害シナリオを含め、新しい委任署名の意味を理解して、権威サーバに照会したときに危険な相互作用が発生する可能性があります。この文書は、それらの相互作用を回避するためにDNSSECのRR（SIG、KEY、およびNXT）のタイプコードとニーモニックを変更します。
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プロトコルは、その構文と意味完全に互換性はありません多くの反復を完了したものです。これは、プロトコルを提案し、それを実装し、インターネットのますます複雑で多様な環境の中でそれをテストし、初期提案された標準の定義を精製する通常のプロセスの一部として発生しています。 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 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.
以前のDNS仕様の弱い領域がリゾルバ機能の多くの詳細を決定するために、独自に大きく実装を残し、リゾルバの挙動を指定する際に、詳細の欠如となっています。これは、DNSSECの仕様が通じていた反復回数と組み合わせて、行動の多種多様なフィールド化コードをもたらしました。この品種は、それが困難なプロトコルの変更は、すべてのデプロイリゾルバによってどのように処理するかを予測することができます。変更が受け入れられない、あるいは致命的な障害を引き起こすというリスクは、それが困難なプロトコルの変更を設計し、展開することができます。そのリスクを管理するための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のための新たなセマンティクスの委任署名者（DS）[RFC3658]導入によって引き起こされる特定の問題に対処します。 DS対応のサーバが提供する回答は、DSのゾーンに署名するのに最適な阻害要因を提供してRFC 2535を実装し、いくつかのリゾルバでは許容できない故障モードをトリガすることができます。この文書で定義された変更は、DSの増分の展開を可能とします。
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レコードが親に表示されていないいる任意の委任を意味します。 「安全でない照会は、」NS RRセットと全く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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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.
委任署名者（DS）はRFC 2535でRFC 2535でのセマンティクスと互換性がないNXTのRRのための新しい意味論を紹介し、NXTレコードは唯一の非存在証明の一部として返される必要がありました。 DS、NS、NXTとSIG（NXT）の形でDS RRの非存在の証明に加えて、安全でない紹介戻る有します。 RFC 2535は、リゾルバがRCODE = 0と応答を解釈する方法を指定したAA = 0、およびNSと権限]セクションでNXTの両方ませんでした。いくつかの広く展開されている2535-対応リゾルバは、要求されたレコードの非存在の証拠としてNXTとの任意の答えを解釈します。これは、セキュリティ保護されていない代表団は、2535-対応リゾルバに見えないものをもたらし、DNSSECは何の害もしないしなければならないことを基本的なアーキテクチャの原則に違反する - ゾーンの署名は、無担保代表団の解決を妨げてはなりません。
This section presents several solutions that were considered. Section 3 describes the one selected.
このセクションでは、考えられていたいくつかの解決策を提示します。第3節では、選択された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.
上記の問題を回避するには、レガシー（RFC2535対応の）リゾルバは権威セクションのNXTレコードを含め、安全でない紹介を見てから保管する必要があります。そのための最も簡単な方法は、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.
これには明らかな欠点は、新しいリゾルバが古いのRRで署名されたゾーンを検証することはできないということです。この問題はすでにので、DSによって行われた変更を、しかし、存在し、古いRRを理解（とDSとの互換性の問題を持っている）リゾルバはこれまで2535年署名のゾーンよりも普及しています。
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を含む種別コードの別のサブセットを変えることによって対処することができます。これは明白なシンプルさの美徳を持っていますが、それは新しい問題を導入するか、十分に行っていないリスク。これは、より多くの非互換性は、DSと以前のセマンティクスの間に存在していることは非常に可能です。レガシーリゾルバもNXTsを見つけることができない一方で、彼らは認識したレコード（SIGとKEY）を見て混乱することができます。それは明らかに壊れていないものを修正する必要はないように見えるかもしれないが、それは一度に型コードのすべてを変更することがはるかにきれいです。これは完全にDNSSECを知らされていないレガシーリゾルバとツールを残すだろう - 彼らは唯一の未知のRRが表示されます。
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-対応リゾルバにそのデータを送信することです。 （仮に「DA」と呼ばれる）DS-意識を知らせるために新しいEDNS0フラグビットを割り当て、権威サーバが唯一のDAビットが設定されたクエリに応じて、DNSSECデータを送る持つが、これを実現することを提案されています。このビットは、おそらく、[RFC3225]に記載のDOビットに取って代わることになります。
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ビットを通過した場合、それはまだ新しい意味を見ること、そしてそれはおそらく安全でない委任を見るために失敗します。それはすべてのDNS実装は、未知のEDNS0フラグをどのように処理するかを知ることが非現実的なので、これは普遍的解決策ではありません。それは、しかし、RRタイプコードを変更することに加えて考えることができます。
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]で定義されるように、すべての既存の実装は、それらがサポートするよりも高いバージョンを拒否し、DNSSEC意識する信号としてDOビットを保持することを前提に、EDNSバージョン番号をインクリメントすることです。このアプローチは、テストされていません。
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.
それらの文書での仕様の下、非存在証明としてNXTを持つ任意の答えを解釈するために、標準規格で定義されているDNSSECを理解RFC 2535および[RFC2065]を追跡し、DNSリゾルバの大規模な展開ベースがあります。だから、長い間それがそうであるように、ゾーンの所有者は、これらの代表団は、このような大規模なインストールベースには見えないことがないよう、安全でない委任を含むすべてのゾーンに署名しないように強いインセンティブを持つことになります。これは劇的に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の新しいバージョンをサポートするためにソフトウェアをアップグレードするための明確な動機がありません、RFCで定義されている3658.過去のデータは、リゾルバはめったにアップグレードされていないことを示唆し、その古いネームサーバコードは死ぬことはありません。
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.
リゾルバはすぐに署名ゾーンの阻害要因を取り除き、DNSSECの広範な展開を許可するプロトコルを変更してこの問題に対処する、セキュアでない代表団とのゾーンに署名する前に自然のプロセスを通じて、アップグレードするために何年待つのではなく。
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.
業務の混乱を避けるために、それはこれらのRRのニーモニックを変更することも必要です。 DNSKEYニーモニックは[RFC3445]あたり、これらのキーは、アプリケーションの使用のためではないことを示すと、キーの交換であろう。 RRSIG（リソースレコード署名）がSIGに置き換えられます、そしてNSEC（次のセキュア）は、NXTに置き換えられます。これらの新しいタイプは、完全にSIGとKEYを使用し続けることSIG（0）[RFC2931]やTKEY [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:
RFC 2535、以下を除き、RFC 3658にSIG、KEY、およびNXT用に指定されているように新しいタイプがまったく同じ構文とセマンティクスを持つことになります。
1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC RRs MUST NOT be compressed,
1）[RFC3597]と一致して、RRSIGとNSEC資源レコードに埋め込まれたドメイン名は、圧縮してはいけません
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 RRの中に埋め込まれたドメイン名が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標準化行動によって定義することができます。
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).
リゾルバが古いタイプを受信した場合、それは不明のRRとして扱う必要があり、それらに特別な意味を割り当てたり、それらに特別な治療を与えるべきではありません。これは、DNSSECの検証や他のDNS運用の意思決定のためにそれらを使用してはなりません。例えば、リゾルバはのSIGを検証したりRRSIGsを検証するためにキーを使用するDNSKEYsを使用してはなりません。 SIG、KEY、またはNXTのRRがゾーンに含まれている場合、彼らは特別な治療を受けてはなりません。 SIGは、署名されたゾーンに含まれている場合の例として、それのためのRRSIGがなければなりません。権威サーバは、（KEYレコードがSIG（0）またはTKEYのために含めてもよい）SIGを含むゾーンまたはNXTレコードをロードするときにエラーメッセージを与えることを望むかもしれません。
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 RRを含んでいます。リゾルバは、彼らがNSECが含まれているという理由だけで、負の答えとしてNSECのRRとの回答を処理してはなりません。
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のRRにタイプ46、47、および48を割り当てることにより、DNSリソースレコードのタイプのための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）が廃止されましマークする必要があります。
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のRRで使用することができます。のみ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].
間接（アルゴリズム252）を除いて、現在定義されているすべてのアルゴリズムは、トランザクションセキュリティメカニズムのために使用可能なままです。 RSA / SHA-1 [RFC3110]、DSA / SHA-1 [RFC2536]、およびプライベートアルゴリズム（タイプ253と254）のみがゾーン署名のために使用することができます。レジストリは、アルゴリズムは、所与の目的のために使用することができるだけかどうか、各アルゴリズムの要求レベルが含まれていないことに留意されたいです。例えば、RSA / MD5、トランザクションセキュリティメカニズムに許可しながら、[RFC3110]あたり、推奨されません。
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からプレゼンテーションフォーマットアルゴリズムニーモニックは、レジストリに追加されます。この文書では、RSA / SHA-1ニーモニックRSASHA1を割り当てます。
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標準化行動を必要とします。また、アルゴリズムのニーモニックまたは適用性の修正は、IETF標準化行動を必要とします。新しいアルゴリズムを定義する文書は、アルゴリズムの適用可能性に対処しなければなりませんし、アルゴリズムにプレゼンテーションニーモニックを割り当てる必要があります。
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（ゾーンビット）の割り当てを含んでいます。ビット0-6と8-15はIETF標準化行動によって割り当て可能です。
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レジストリは、このフィールドのために必要ではありません。
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.
何もしない、セクション2.5で説明したように、DNSSECの展開が遅くなります。これは、セキュリティが低下しませんが、それはまた、それを高めるために失敗しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC2536]イーストレイク、D.、 "DSA鍵とドメインネームシステム（DNS）でのSIG"、RFC 2536、1999年3月。
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]イーストレイク、D.、 "DNSのための秘密鍵確立（TKEYのRR）"、RFC 2930、2000年9月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", RFC 2931, September 2000.
[RFC2931]イーストレイク、D.、 "DNS要求とトランザクション署名（SIG（0）S）"、RFC 2931、2000年9月。
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3110]イーストレーク、D.、 "ドメインネームシステムにおけるRSA / SHA-1のSIGとRSA鍵（DNS）"、RFC 3110、2001年5月。
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003.
[RFC3658]グドムンソン、O.、 "委任署名者（DS）リソースレコード（RR）"、RFC 3658、2003年12月。
[RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC2065]イーストレイク、第三、D.およびC.カウフマン、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2065、1997年1月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]いるVixie、P.、 "DNS用拡張メカニズム（EDNS0）"、RFC 2671、1999年8月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225]コンラッド、D.、 "DNSSECのレゾルバサポートを示す"、RFC 3225、2001年12月。
[RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445]マッセイ、D.、およびS.ローズ、RFC 3445 "KEYリソースレコード（RR）の範囲を制限"、2002年12月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]グスタフソン、A.、 "未知のDNSリソースレコード（RR）の取扱いタイプ"、RFC 3597、2003年9月。
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.
変更内容は、ここで紹介し、代替案の分析は、多くの貢献がありました。見落として誰にも謝罪して、それらが含まれます：マイケルGraffの、ヨハンIhren、オラフKolkman、マーク・Kosters、エド・ルイス、ビル・マニング、ポール・ヴィクシー、とスザンヌウルフを。
Thanks to Jakob Schlyter and Mark Andrews for identifying the incompatibility described in section 1.2.
セクション1.2に記載の非互換性を識別するためのヤコブSchlyterとマーク・アンドリュースに感謝します。
In addition to the above, the author would like to thank Scott Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive comments.
上記に加えて、作者は彼らの実質的なコメントにスコット・ローズ、オラフルグドムンソン、とサンドラ・マーフィーに感謝したいと思います。
Samuel Weiler SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 USA
サミュエル・ワイラーSPARTA、Inc.の7075サミュエル・モールスドライブコロンビア、MD 21046 USA
EMail: weiler@tislabs.com
メールアドレス：weiler@tislabs.com
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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。