RFC4431 日本語訳

Network Working Group                                         M. Andrews
Request for Comments: 4431                   Internet Systems Consortium
Category: Informational                                        S. Weiler
                                                            SPARTA, Inc.
                                                           February 2006

コメントを求めるワーキンググループM.アンドリュース要求をネットワークでつないでください: 4431年のインターネットシステム共同体カテゴリ: 情報のS.ウィーラースパルタInc.2006年2月

       The DNSSEC Lookaside Validation (DLV) DNS Resource Record

DNSSEC Lookaside合法化(DLV)DNSリソース記録

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   This document defines a new DNS resource record, called the DNSSEC
   Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors
   outside of the DNS delegation chain.

DNSSEC Lookaside Validation(DLV)RRは、このドキュメントが新しいDNSリソース記録を定義すると呼びました、DNS委譲チェーンの外でDNSSEC信頼アンカーを発行するために。

1.  Introduction

1. 序論

   DNSSEC [1] [2] [3] authenticates DNS data by building public-key
   signature chains along the DNS delegation chain from a trust anchor,
   ideally a trust anchor for the DNS root.

DNSSEC[1][2][3]は、DNS委譲チェーンに沿って信頼アンカー、DNS根のための理想的に信頼アンカーから公開鍵署名チェーンを組立てることによって、DNSデータを認証します。

   This document defines a new resource record for publishing such trust
   anchors outside of the DNS's normal delegation chain.  Use of these
   records by DNSSEC validators is outside the scope of this document,
   but it is expected that these records will help resolvers validate
   DNSSEC-signed data from zones whose ancestors either aren't signed or
   refuse to publish delegation signer (DS) records for their children.

このドキュメントはDNSの正常な委譲チェーンの外でそのような信頼アンカーを発行するための新しいリソース記録を定義します。 このドキュメントの範囲の外にDNSSEC validatorsによるこれらの記録の使用がありますが、これらの記録が、レゾルバが先祖が署名されないか、または彼らの子供のために委譲署名者(DS)記録を発表するのを拒否するゾーンからのDNSSECによって署名されたデータを有効にするのを助けると予想されます。

2.  DLV Resource Record

2. DLVリソース記録

   The DLV resource record has exactly the same wire and presentation
   formats as the DS resource record, defined in RFC 4034, Section 5.
   It uses the same IANA-assigned values in the algorithm and digest
   type fields as the DS record.  (Those IANA registries are known as
   the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
   Numbers" registries.)

DLVリソース記録には、RFC4034で定義されたDSリソース記録としてまさに同じワイヤとプレゼンテーション形式があります、セクション5。 DSが記録するようにそれはアルゴリズムとダイジェストタイプ分野で同じIANA-割り当てられた値を使用します。 (それらのIANA登録は「DNSセキュリティアルゴリズム番号」と「DS RRタイプアルゴリズム番号」登録として知られています。)

Andrews & Weiler             Informational                      [Page 1]

RFC 4431                  DLV Resource Record              February 2006

[1ページ]RFC4431DLVリソース記録2006年2月の情報のアンドリュースとウィーラー

   The DLV record is a normal DNS record type without any special
   processing requirements.  In particular, the DLV record does not
   inherit any of the special processing or handling requirements of the
   DS record type (described in Section 3.1.4.1 of RFC 4035).  Unlike
   the DS record, the DLV record may not appear on the parent's side of
   a zone cut.  A DLV record may, however, appear at the apex of a zone.

DLV記録は少しも特別な処理所要がなければ正常なDNSレコード種類です。 特に、DLV記録は特別な処理のどれかかDSレコード種類の取り扱い要件(セクション3.1.4では、.1RFC4035について説明する)を引き継ぎません。 DS記録と異なって、DLV記録は親のゾーンカットの側に載らないかもしれません。 しかしながら、DLV記録はゾーンの頂点に現れるかもしれません。

3.  Security Considerations

3. セキュリティ問題

   For authoritative servers and resolvers that do not attempt to use
   DLV RRs as part of DNSSEC validation, there are no particular
   security concerns -- DLV RRs are just like any other DNS data.

DNSSEC合法化の一部としてDLV RRsを使用するのを試みない正式のサーバとレゾルバのために、どんな特定の安全上の配慮もありません--DLV RRsはまさしくいかなる他のDNSデータにも似ています。

   Software using DLV RRs as part of DNSSEC validation will almost
   certainly want to impose constraints on their use, but those
   constraints are best left to be described by the documents that more
   fully describe the particulars of how the records are used.  At a
   minimum, it would be unwise to use the records without some sort of
   cryptographic authentication.  More likely than not, DNSSEC itself
   will be used to authenticate the DLV RRs.  Depending on how a DLV RR
   is used, failure to properly authenticate it could lead to
   significant additional security problems including failure to detect
   spoofed DNS data.

DNSSEC合法化の一部としてDLV RRsを使用するソフトウェアがほぼ確実に彼らの使用に規制を課したくなりますが、記録がどう使用されているかに関する子細について、より完全に説明するドキュメントによってそれらの規制が説明されるのを残すのは最も良いです。 最小限では、ある種の暗号の認証なしで記録を使用するのは賢明でないでしょう。 おそらく、DNSSEC自身は、DLV RRsを認証するのに使用されるでしょう。 DLV RRがどう使用されているかによって、適切にそれを認証しない場合、偽造しているDNSデータを検出しないことを含むことにおける重要な追加担保問題を引き起こすかもしれません。

   RFC 4034, Section 8, describes security considerations specific to
   the DS RR.  Those considerations are equally applicable to DLV RRs.
   Of particular note, the key tag field is used to help select DNSKEY
   RRs efficiently, but it does not uniquely identify a single DNSKEY
   RR.  It is possible for two distinct DNSKEY RRs to have the same
   owner name, the same algorithm type, and the same key tag.  An
   implementation that uses only the key tag to select a DNSKEY RR might
   select the wrong public key in some circumstances.

RFC4034(セクション8)はDS RRに特定のセキュリティ問題について説明します。 それらの問題は等しくDLV RRsに適切です。 特定の注意では、キー・タグ分野は効率的にDNSKEY RRsを選択するのを助けるのに使用されますが、それは唯一独身のDNSKEY RRを特定しません。 2異なったDNSKEY RRsには同じ所有者名、同じアルゴリズムタイプ、および同じキー・タグがあるのは、可能です。 DNSKEY RRを選択するのにキー・タグだけを使用する実装はいくつかの事情の間違った公開鍵を選択するかもしれません。

   For further discussion of the security implications of DNSSEC, see
   RFC 4033, RFC 4034, and RFC 4035.

DNSSECのセキュリティ含意のさらなる議論に関しては、RFC4033、RFC4034、およびRFC4035を見てください。

4.  IANA Considerations

4. IANA問題

   IANA has assigned DNS type code 32769 to the DLV resource record from
   the Specification Required portion of the DNS Resource Record Type
   registry, as defined in [4].

IANAはDNS Resource Record Type登録のSpecification Required部分からのDLVリソース記録へのタイプコード32769をDNSに割り当てました、[4]で定義されるように。

   The DLV resource record reuses the same algorithm and digest type
   registries already used for the DS resource record, currently known
   as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
   Numbers" registries.

DLVリソース記録は登録が記録的で、現在「DNSセキュリティアルゴリズム番号」と「DS RRタイプアルゴリズム番号」登録として知られているDSリソースに既に使用した同じアルゴリズムとダイジェストタイプを再利用します。

Andrews & Weiler             Informational                      [Page 2]

RFC 4431                  DLV Resource Record              February 2006

[2ページ]RFC4431DLVリソース記録2006年2月の情報のアンドリュースとウィーラー

5.  Normative References

5. 引用規格

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

[1]はArendsします、R.、Austein、R.、ラーソン、M.、マッシー、D.、S.ローズと、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。

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

[2] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。

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

[3] Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。

   [4]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name
        System (DNS) IANA Considerations", BCP 42, RFC 2929,
        September 2000.

[4] イーストレーク、D.、ブルンナー-ウィリアムズ、E.、およびB.マニング、「ドメインネームシステム(DNS)IANA問題」、BCP42、RFC2929、2000年9月。

Authors' Addresses

作者のアドレス

   Mark Andrews
   Internet Systems Consortium
   950 Charter St.
   Redwood City, CA  94063
   US

聖レッドウッドシティー、アンドリュースインターネットシステム共同体950Charterカリフォルニア 94063が米国であるとマークしてください。

   EMail: Mark_Andrews@isc.org

メール: Mark_Andrews@isc.org

   Samuel Weiler
   SPARTA, Inc.
   7075 Samuel Morse Drive
   Columbia, Maryland  21046
   US

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

   EMail: weiler@tislabs.com

メール: weiler@tislabs.com

Andrews & Weiler             Informational                      [Page 3]

RFC 4431                  DLV Resource Record              February 2006

[3ページ]RFC4431DLVリソース記録2006年2月の情報のアンドリュースとウィーラー

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   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.

このドキュメントは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 provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Andrews & Weiler             Informational                      [Page 4]

アンドリュースとウィーラーInformationalです。[4ページ]