RFC 4955 - DNS Security (DNSSEC) Experiments 日本語訳

URL : https://tools.ietf.org/html/rfc4955
タイトル : RFC 4955 - DNSセキュリティ（DNSSEC）実験
翻訳編集 : 自動生成

Network Working Group                                          D. Blacka
Request for Comments: 4955                                VeriSign, Inc.
Category: Standards Track                                      July 2007

                   DNS Security (DNSSEC) Experiments

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）IETFトラスト（2007）。

Abstract

抽象

This document describes a methodology for deploying alternate, non-backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC.

このドキュメントは、標準のDNSSECの展開を中断することなく、実験方法で代替、非下位互換性、DNSセキュリティ（DNSSEC）の方法論を展開するための方法を記載しています。

Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Definitions and Terminology . . . . . . . . . . . . . . . . . . 2
   3.  Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   4.  Method  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  Defining an Experiment  . . . . . . . . . . . . . . . . . . . . 4
   6.  Considerations  . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Use in Non-Experiments  . . . . . . . . . . . . . . . . . . . . 5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6

1. Overview

1。概要

Historically, experimentation with DNSSEC alternatives has been a problematic endeavor. There has typically been a desire to both introduce non-backwards-compatible changes to DNSSEC and to try these changes on real zones in the public DNS. This creates a problem when the change to DNSSEC would make all or part of the zone using those changes appear bogus (bad) or otherwise broken to existing security-aware resolvers.

歴史的に、DNSSECの選択肢との実験は、問題の努力となっています。通常、DNSSECに非後方互換の変更を導入し、パブリックDNSに実際のゾーンにこれらの変更をしようとするの両方に望まれています。これは、DNSSECへの変更は、偽の（悪い）か、そうでない場合は、既存のセキュリティ対応リゾルバに壊れて表示されるすべてを作るか、またはそれらの変更を使用してゾーンの一部となる問題を作成します。

This document describes a standard methodology for setting up DNSSEC experiments. This methodology addresses the issue of coexistence with standard DNSSEC and DNS by using unknown algorithm identifiers to hide the experimental DNSSEC protocol modifications from standard security-aware resolvers.

この文書では、DNSSECの実験を設定するための標準的な方法を説明します。この方法は、標準のセキュリティ対応リゾルバからの実験DNSSECプロトコルの変更を非表示にするには、未知のアルゴリズム識別子を使用して、標準のDNSSECとDNSとの共存の問題を解決します。

2. Definitions and Terminology

2.定義と用語

Throughout this document, familiarity with the DNS system (RFC 1035 [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and RFC 4035 [4]) is assumed.

この文書を通して、DNSシステムに精通（RFC 1035 [5]）とDNSセキュリティ拡張（RFC 4033 [2]は、RFC 4034 [3]、及びRFC 4035 [4]）と仮定されます。

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 RFC 2119 [1].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。

3. Experiments

3.実験

When discussing DNSSEC experiments, it is necessary to classify these experiments into two broad categories:

DNSSECの実験を議論するとき、2つの広いカテゴリーにこれらの実験を分類する必要があります。

Backwards-Compatible: describes experimental changes that, while not strictly adhering to the DNSSEC standard, are nonetheless interoperable with clients and servers that do implement the DNSSEC standard.

下位互換性：厳密にDNSSECの規格に準拠していないながら、という実験的な変更点について説明し、それにもかかわらず、DNSSECの標準を実装しないクライアントとサーバとの相互運用が可能です。

Non-Backwards-Compatible: describes experiments that would cause a standard security-aware resolver to (incorrectly) determine that all or part of a zone is bogus, or to otherwise not interoperate with standard DNSSEC clients and servers.

非下位互換性：標準セキュリティ対応リゾルバを引き起こす実験を記述する（間違って）ゾーンの全部または一部が偽であると判断し、あるいはそうでない場合は、標準のDNSSECクライアントとサーバとの相互運用しないこと。

Not included in these terms are experiments with the core DNS protocol itself.

これらの用語に含まれていないコアDNSプロトコル自体での実験です。

The methodology described in this document is not necessary for backwards-compatible experiments, although it certainly may be used if desired.

所望であれば、それは確かに使用することができるが、この文書に記載された方法は、下位互換性の実験のために必要ではありません。

4. Method

4.メソッド

The core of the methodology is the use of strictly unknown algorithm identifiers when signing the experimental zone, and more importantly, having only unknown algorithm identifiers in the DS records for the delegation to the zone at the parent.

親のゾーンへの委任のためのDSレコードで唯一の未知のアルゴリズム識別子を持つ、もっと重要な実験的なゾーンに署名する、とするときの方法論の核心は、厳密には、未知のアルゴリズム識別子を使用することです。

This technique works because of the way DNSSEC-compliant validators are expected to work in the presence of a DS set with only unknown algorithm identifiers. From RFC 4035 [4], Section 5.2:

この技術は理由DNSSEC対応のバリデータのみ、未知のアルゴリズム識別子とDSセットの存在下で働くことが期待されている方法で動作します。 RFC 4035から[4]、セクション5.2：

If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described above.

バリデータが認証されたDS RRセットに記載されているアルゴリズムのいずれかをサポートしていない場合は、リゾルバは親から子へ有数一切サポートされている認証パスを持っていません。上記のように、それが認証NSEC資源レコード集合の場合は、何のDS RRセットが存在しないことを証明するであろうように、レゾルバは、このケースを扱うべきです。

And further:

そしてさらに：

If the resolver does not support any of the algorithms listed in an authenticated DS RRset, then the resolver will not be able to verify the authentication path to the child zone. In this case, the resolver SHOULD treat the child zone as if it were unsigned.

リゾルバが認証されたDS RRセットに記載されているアルゴリズムのいずれかをサポートしていない場合は、リゾルバは子ゾーンへの認証パスを確認することができません。それは符号なしであるかのようにこの場合、リゾルバは子ゾーンを扱うべきです。

Although this behavior isn't strictly mandatory (as marked by MUST), it is unlikely for a validator to implement a substantially different behavior. Essentially, if the validator does not have a usable chain of trust to a child zone, then it can only do one of two things: treat responses from the zone as insecure (the recommended behavior), or treat the responses as bogus. If the validator chooses the latter, this will both violate the expectation of the zone owner and defeat the purpose of the above rule. However, with local policy, it is within the right of a validator to refuse to trust certain zones based on any criteria, including the use of unknown signing algorithms.

この動作は、（MUSTでマークされる）厳密に必須ではありませんが、バリデータは実質的に異なる動作を実装することはほとんどありません。バリデータは、子ゾーンへの信頼の使用可能なチェーンを持っていない場合は基本的に、それが唯一の2つのいずれかを行うことができます。安全でない（推奨動作）とゾーンからの応答を処理する、または偽のような応答を扱います。バリデータが後者を選択した場合、これは、両方のゾーンの所有者の期待に違反し、上記ルールの目的を打ち負かします。しかし、ローカルポリシーと、それは未知の署名アルゴリズムの使用を含む任意の基準に基づいて、特定のゾーンを、信頼することを拒否するためにバリデータの権利の範囲内です。

Because we are talking about experiments, it is RECOMMENDED that private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1. Note that secure handling of private algorithms requires special handing by the validator logic. See "Clarifications and Implementation Notes for DNSSECbis" [6] for further details.) Normally, instead of actually inventing new signing algorithms, the recommended path is to create alternate algorithm identifiers that are aliases for the existing, known algorithms. While, strictly speaking, it is only necessary to create an alternate identifier for the mandatory algorithms, it is suggested that all optional defined algorithms be aliased as well.

我々は実験について話しているので、RFC 4034 [3]、付録A.1.1を参照してください（プライベートアルゴリズム番号を使用することをお勧めします。プライベートアルゴリズムの安全な取り扱いがバリロジックによって特別な取り扱いが必要であることに注意してください。詳細は、「明確化と実装の注意事項DNSSECbisは、」[6]の詳細については。）通常、代わりに実際に新たな署名アルゴリズムを発明の、推奨経路は、既存の、既知のアルゴリズムの別名である代替アルゴリズム識別子を作成することです。厳密に言えば、それは必須のアルゴリズムの代替識別子を作成するためにのみ必要であるが、すべてのオプション定義のアルゴリズムも同様にエイリアスされていることが示唆されています。

It is RECOMMENDED that for a particular DNSSEC experiment, a particular domain name base is chosen for all new algorithms, then the algorithm number (or name) is prepended to it. For example, for experiment A, the base name of "dnssec-experiment-a.example.com" is chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-experiment-a.example.com". However, any unique identifier will suffice.

特定のDNSSECの実験のために、特定のドメイン名ベースのアルゴリズム番号（または名前）が、それに付加され、すべての新しいアルゴリズムのために選択することが推奨されます。例えば、実験Aのために、「dnssec-experiment-a.example.com」のベース名が選択されます。次いで、アルゴリズム3（DSA）および5（RSASHA1）の別名は "3.dnssec-experiment-a.example.com" および "5.dnssec-experiment-a.example.com" であると定義されます。しかし、任意の一意の識別子で十分です。

Using this method, resolvers (or, more specifically, DNSSEC validators) essentially indicate their ability to understand the DNSSEC experiment's semantics by understanding what the new algorithm identifiers signify.

この方法を使用して、リゾルバ（または、より具体的には、DNSSECのバリデータ）は、本質的に新しいアルゴリズムの識別子が意味するもの理解することによって、DNSSEC実験の意味を理解する能力を示しています。

This method creates two classes of security-aware servers and resolvers: servers and resolvers that are aware of the experiment (and thus recognize the experiment's algorithm identifiers and experimental semantics), and servers and resolvers that are unaware of the experiment.

サーバとリゾルバ実験を認識している（したがって、実験のアルゴリズム識別子と実験的なセマンティクスを認識）、および実験の気付いていないサーバとリゾルバ：このメソッドは、セキュリティ対応のサーバとリゾルバの2つのクラスを作成します。

This method also precludes any zone from being both in an experiment and in a classic DNSSEC island of security. That is, a zone is either in an experiment and only possible to validate experimentally, or it is not.

この方法はまた、実験およびセキュリティのクラッシックDNSSEC島の両方であることから、任意のゾーンを排除します。これは、ゾーンが実験的に検証するための実験でのみ可能のいずれかであるか、そうではありません、です。

5. Defining an Experiment

5.実験の定義

The DNSSEC experiment MUST define the particular set of (previously unknown) algorithm identifiers that identify the experiment and define what each unknown algorithm identifier means. Typically, unless the experiment is actually experimenting with a new DNSSEC algorithm, this will be a mapping of private algorithm identifiers to existing, known algorithms.

DNSSEC実験は、実験を識別し、各未知のアルゴリズム識別子が何を意味するかを定義（以前は未知の）アルゴリズム識別子の特定のセットを定義しなければなりません。一般的に、実験が実際に新しいDNSSECアルゴリズムで実験されていない限り、これは既存の、既知のアルゴリズムにプライベートアルゴリズム識別子のマッピングになります。

Normally the experiment will choose a DNS name as the algorithm identifier base. This DNS name SHOULD be under the control of the authors of the experiment. Then the experiment will define a mapping between known mandatory and optional algorithms into this private algorithm identifier space. Alternately, the experiment MAY use the Object Identifier (OID) private algorithm space instead (using algorithm number 254), or MAY choose non-private algorithm numbers, although this would require an IANA allocation.

通常、実験はアルゴリズム識別子ベースとしてDNS名を選択します。このDNS名は、実験の作者の制御の下でなければなりません。次いで、実験は、このプライベートアルゴリズム識別子空間に公知の必須および任意のアルゴリズムとの間のマッピングを定義します。これはIANA割り当てを必要とするであろうが、交互に、実験は、代わりに（アルゴリズム番号254を使用して）オブジェクト識別子（OID）プライベートアルゴリズム空間を使用してもよいし、非プライベートアルゴリズム番号を選択することができます。

For example, an experiment might specify in its description the DNS name "dnssec-experiment-a.example.com" as the base name, and declare that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an alias of DNSSEC algorithm 5 (RSASHA1).

例えば、実験は、ベース名とその説明に「dnssec-experiment-a.example.comを」DNS名を指定し、「3.dnssec-experiment-a.example.comは」DNSSECの別名であることを宣言するかもしれませんアルゴリズム3（DSA）、それは "5.dnssec-experiment-a.example.com" DNSSECアルゴリズム5（RSASHA1）の別名です。

Resolvers MUST only recognize the experiment's semantics when present in a zone signed by one or more of these algorithm identifiers. This is necessary to isolate the semantics of one experiment from any others that the resolver might understand.

リゾルバは、これらのアルゴリズム識別子の一つ以上が署名したゾーンに存在する場合には、実験の意味を認識しなければなりません。これは、リゾルバが理解可能性のある他のものから一つの実験の意味を単離することが必要です。

In general, resolvers involved in the experiment are expected to understand both standard DNSSEC and the defined experimental DNSSEC protocol, although this isn't required.

これは必須ではないが、一般的に、実験に関与するレゾルバは、両方の標準DNSSECと定義実験DNSSECプロトコルを理解することが期待されます。

6. Considerations

6.留意事項

There are a number of considerations with using this methodology.

この方法論を使用したとの考慮事項がいくつかあります。

1. If an unaware validator does not correctly follow the rules laid out in RFC 4035 (e.g., the validator interprets a DNSSEC record prior to validating it), or if the experiment is broader in scope that just modifying the DNSSEC semantics, the experiment may not be sufficiently masked by this technique. This may cause unintended resolution failures.

1.気づかないバリがあり、正しく（例えば、バリデータが前にそれを確認するにDNSSECレコードを解釈する）RFC 4035にレイアウトされたルールに従うか、実験がスコープ内に広い場合だけDNSSECのセマンティクスを変更すること、実験していない場合十分にこの技術によってマスクされません。これは、意図しない解決エラーが発生することがあります。

2. It will not be possible for security-aware resolvers unaware of the experiment to build a chain of trust through an experimental zone.

2.これは、実験的なゾーンを通って信頼の連鎖を構築するための実験を知らないセキュリティ対応リゾルバのために行うことはできません。

7. Use in Non-Experiments

非実験における7.

This general methodology MAY be used for non-backwards compatible DNSSEC protocol changes that start out as or become standards. In this case:

この一般的な方法論はとして開始または標準となっ非下位互換性DNSSECプロトコルの変更のために使用されるかもしれません。この場合：

o The protocol change SHOULD use public IANA allocated algorithm identifiers instead of private algorithm identifiers. This will help identify the protocol change as a standard, rather than an experiment.

Oプロトコルの変更ではなく、民間のアルゴリズム識別子の公開IANAに割り当てられたアルゴリズム識別子を使用すべきです。これはかなり実験より、標準などのプロトコルの変更を識別するのに役立ちます。

o Resolvers MAY recognize the protocol change in zones not signed (or not solely signed) using the new algorithm identifiers.

Oリゾルバは、ゾーン内のプロトコルの変更は、新しいアルゴリズムの識別子を使用して（または単に署名されていない）に署名しないで認識することができます。

8. Security Considerations

8.セキュリティの考慮事項

Zones using this methodology will be considered insecure by all resolvers except those aware of the experiment. It is not generally possible to create a secure delegation from an experimental zone that will be followed by resolvers unaware of the experiment.

この方法論を使用したゾーンは、実験を意識したものを除くすべてのリゾルバによって安全でないとみなされます。実験を知らないリゾルバが続く実験区域から安全な委任を作成することは一般に不可能です。

Implementers should take into account any security issues that may result from environments being configured to trust both experimental and non-experimental zones. If the experimental zone is more vulnerable to attacks, it could, for example, be used to promote trust in zones not part of the experiment, possibly under the control of an attacker.

実装者は、アカウントに環境は両方の実験と非実験ゾーンを信頼するように設定されているから生じる可能性のあるセキュリティ上の問題を取る必要があります。実験的なゾーンが攻撃に対して脆弱である場合、例えば、おそらく攻撃者の制御下で、実験の一部ではない、ゾーンの信頼を促進するために使用することができます。

9. References

9.参考文献

9.1. Normative References

9.1. 引用規格

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[2]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。

[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.

[3]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのリソースレコード"、RFC 4034、2005年3月。

[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

[4]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。

9.2. Informative References

9.2. 参考文献

[5] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[5] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。

[6] Weiler, S. and R. Austein, "Clarifications and Implementation Notes for DNSSECbis", Work in Progress, March 2007.

[6]ワイラー、S.とR. Austeinと、 "DNSSECbisのための明確化と実装上の注意" を、進歩、2007年3月に仕事を。

Author's Address

著者のアドレス

David Blacka VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US

デビッドBlackaベリサイン社21355 Ridgetopサークルダレス、VA 20166米国

Phone: +1 703 948 3200 EMail: davidb@verisign.com URI: http://www.verisignlabs.com

電話：+1 703 948 3200 Eメール：davidb@verisign.com URI：http://www.verisignlabs.com

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（2007）。

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.

この文書では、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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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機能のための基金は現在、インターネット協会によって提供されます。