[要約] RFC 3755は、Delegation Signer（DS）の遺産リゾルバの互換性に関するものであり、DNSSECの展開における問題を解決するために作成されました。このRFCの目的は、DSレコードを使用してDNSSECチェーンを確立するための遺産リゾルバのサポートを提供することです。
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)
代表団の署名者のためのレガシーリゾルバーの互換性（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）The Internet Society（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リソースレコード（RRS）の構文とセマンティクスが変更されました。多くの展開された名前アーバーは、これらのセマンティクスのバリエーションを理解しています。これらのセマンティクスの以前のバージョンを理解しているリゾルバーが、無担保ゾーンを解決できないようにする少なくとも1つの障害シナリオを含む、新しい委任署名者セマンティクスを理解する権威あるサーバーを照会する場合、危険な相互作用が発生する可能性があります。このドキュメントは、DNSSEC RRS（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-Awareサーバーが提供する回答は、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 RRSTを含む親からの答えであり、その名前に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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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のセマンティクスと互換性のないNXT RRの新しいセマンティクスを導入します。RFC2535では、NXTレコードは非存在証明の一部として返される必要がありました。DSを使用すると、NSに加えて、NXと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では、選択したものについて説明します。
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.
上記の問題を回避するには、Legacy（RFC2535-AWARE）リゾルバーは、当局セクションのNXTレコードを含む無関係な紹介を見るのを防ぐ必要があります。それを行う最も簡単な方法は、SIG、キー、および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署名のゾーンよりもはるかに一般的です。
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と以前のセマンティクスの間により多くの非互換性が存在する可能性は非常に高いです。また、レガシーリソースバーは、NXTを見つけることができなくなっている間に認識されているレコード（SIGおよびキー）を見ることで混同される場合があります。明らかに壊れていないものを修正する必要はないかもしれませんが、すべてのタイプコードを一度に変更するのははるかにクリーンです。これにより、レガシーレゾルバーとツールが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に認識したリゾルバーにのみ送信することです。新しいEDNS0フラグビットをDS-Awarnessを信号にするために割り当て（暫定的に「DA」と呼ばれる）、権威あるサーバーが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フラグをゼロにした場合にのみ十分です。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]で定義されているEDNSバージョン番号を増やし、DNSSEC意識のシグナルとしてDOビットを保持することです。このアプローチはテストされていません。
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.
標準トラックRFC 2535および[RFC2065]で定義されているDNSSECを理解するDNSリゾルバーの大きな展開ベースがあり、それらのドキュメントの仕様の下で、NXTを使用して回答を非存在証明として解釈します。それが事実である限り、ゾーンの所有者は、これらの代表団がこのような大きな設置ベースに見えないように、安全でない代表団を含むゾーンに署名しないという強いインセンティブを持っています。これにより、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.
残念ながら、署名されたゾーンがなければ、RFC 3658で定義されているように、RELSOVERの新しいバージョンのDNSSECをサポートするためにソフトウェアをアップグレードするための明確なインセンティブはありません。履歴データは、リゾルバーがめったにアップグレードされず、古い名前サーバーコードが死なないことを示唆しています。
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、キー、および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（0）[RFC2931]およびTKEY [RFC2930]がSIGとキーを使用し続けることを除いて、古いタイプを完全に置き換えます。
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 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 RRの埋め込みドメイン名は、DNSSECの標準形式および順序付けも平等比較のためにダウンケースではありません。
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).
リゾルバーが古いタイプを受信した場合、それらを未知のRRSとして扱う必要があり、それらに特別な意味を割り当てたり、特別な治療を与えたりするべきではありません。DNSSECの検証またはその他のDNS運用上の意思決定にそれらを使用してはなりません。たとえば、リゾルバーはDNSKEYを使用してSIGを検証したり、キーを使用してRRSIGを検証してはなりません。SIG、キー、またはNXT RRがゾーンに含まれている場合、特別な治療を受けてはなりません。例として、SIGが署名ゾーンに含まれている場合、RRSIGが必要です。権威あるサーバーは、SIGまたはNXTレコードを含むゾーンをロードするときにエラーメッセージを提供する場合があります（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 RRSが含まれます。リゾルバーは、NSECがNSECを含むという理由だけで、NSEC RRSで回答を否定的な答えとして扱ってはなりません。
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 RRSにタイプ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およびキー）は、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.
ゾーンSIING（DNSSEC）およびトランザクションセキュリティメカニズム（SIG（0）およびTKEY）がさまざまなアルゴリズムセットを使用できるようにするために、既存の「DNSセキュリティアルゴリズム」レジストリが変更され、各アルゴリズムの適用性が含まれます。具体的には、2つの新しい列がレジストリに追加され、各アルゴリズムがゾーン署名、トランザクションセキュリティメカニズム、またはその両方に使用できるかどうかを示します。ゾーン署名に使用可能なアルゴリズムのみが、DNSKEY、RRSIG、およびDS RRSで使用できます。SIG（0）および/またはTSIGに使用可能なアルゴリズムのみが、SIGおよびキーRRSで使用できます。
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.
キーリソースレコードと同様に、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.
キーリソースレコードと同様に、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC2536] EastLake、D。、「DSA Keys and Sigs in the Domain Name System（DNS）」、RFC 2536、1999年3月。
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930] Eastlake、D。、「DNSの秘密の鍵設立（TKEY RR）」、RFC 2930、2000年9月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", RFC 2931, September 2000.
[RFC2931] EastLake、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] EastLake、D。、「ドメイン名システム（DNS）のRSA/SHA-1 SIGSおよびRSAキー」、RFC 3110、2001年5月。
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003.
[RFC3658] Gudmundsson、O。、「委任署名者（DS）リソースレコード（RR）」、RFC 3658、2003年12月。
[RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC2065]イーストレイク、3rd、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] Conrad、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] Massey、D。、およびS. Rose、「主要なリソースレコード（RR）の範囲の制限」、RFC 3445、2002年12月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597] Gustafsson、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.
ここに導入された変更と代替の分析には、多くの貢献者がいました。見落とされがちな人に謝罪して、マイケル・グラフ、ヨハン・イーレン、オラフ・コルマン、マーク・コスターズ、エド・ルイス、ビル・マニング、ポール・ビクシー、スザンヌ・ウルフが含まれます。
Thanks to Jakob Schlyter and Mark Andrews for identifying the incompatibility described in section 1.2.
セクション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.
上記に加えて、著者は、実質的なコメントをしてくれたスコット・ローズ、オラファー・グドマンソン、サンドラ・マーフィーに感謝したいと思います。
Samuel Weiler SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 USA
Samuel Weiler Sparta、Inc。7075 Samuel Morse Drive Columbia、MD 21046 USA
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。