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

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

[要約] RFC 4955は、DNSセキュリティ（DNSSEC）の実験に関する情報を提供するものであり、DNSSECの導入と展開に関する問題を解決するための実験を行うことを目的としています。

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

DNS Security (DNSSEC) Experiments

DNSセキュリティ（DNSSEC）実験

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）The IETF Trust（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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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 RRSetにリストされているアルゴリズムのいずれをサポートしていない場合、リゾルバーには親から子供につながるサポートされた認証パスがありません。リゾルバーは、上記のようにDS RRSetが存在しないことを証明した認証されたNSEC RRSETの場合と同じようにこのケースを扱う必要があります。

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 RRSetにリストされているアルゴリズムのいずれをサポートしていない場合、リゾルバーは子ゾーンへの認証パスを確認できません。この場合、リゾルバーは子ゾーンをまるで署名しているかのように扱う必要があります。

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.

この動作は厳密に必須ではありませんが（必須でマークされていますが）、バリデーターが実質的に異なる動作を実装することはほとんどありません。基本的に、バリーターが子ゾーンに使用可能な信頼のチェーンを持っていない場合、ゾーンからの応答を不安定（推奨行動）として扱うか、反応を偽物として扱うという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名は、実験の著者の管理下にある必要があります。次に、この実験では、既知の必須アルゴリズムとオプションのアルゴリズムの間のマッピングがこのプライベートアルゴリズム識別子スペースに定義されます。あるいは、実験では、代わりにオブジェクト識別子（OID）プライベートアルゴリズムスペース（アルゴリズム番号254を使用）を使用するか、非プライベートアルゴリズム番号を選択する場合がありますが、IANAの割り当てが必要です。

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

たとえば、実験では、その説明でDNS名「DNSSEC- Experiment-a.example.com」を基本名として指定し、「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.

リゾルバーは、これらのアルゴリズム識別子の1つ以上が署名したゾーンに存在する場合にのみ、実験のセマンティクスを認識する必要があります。これは、リゾルバーが理解できる他のものから1つの実験のセマンティクスを分離するために必要です。

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. 気づいていないバリデーターがRFC 4035でレイアウトされたルールに正確に従わない場合（たとえば、検証する前にDNSSECレコードを解釈すること）、または実験が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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

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

[2] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Weiler、S。およびR. Austein、「DNSSECBISの説明と実装ノート」、2007年3月、進行中の作業。

Author's Address

著者の連絡先

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

David Blacka Verisign、Inc。21355 Ridgetop Circle Dulles、VA 20166 US

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

Full Copyright Statement

完全な著作権声明

著作権（c）The IETF Trust（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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

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