Network Working Group M. Andrews
Request for Comments: 4431 Internet Systems Consortium
Category: Informational S. Weiler
SPARTA, Inc.
February 2006
The DNSSEC Lookaside Validation (DLV) DNS Resource Record
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).
著作権（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.
この文書は、新しいDNSリソースレコードを定義して、DNS委譲チェーンの外DNSSECトラストアンカーを発行するため、DNSSECルックアサイドバリデーション（DLV）RRと呼ばれます。
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によってこれらのレコードの使用は、このドキュメントの範囲外ですが、これらのレコードは、リゾルバは、祖先のいずれかのゾーンからDNSSEC署名データが署名またはのための委任署名者（DS）レコードを公開することを拒否されていない検証に役立つことが期待されるバリ彼らの子供。
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リソースレコードは、それがアルゴリズムで同じIANAによって割り当てられた値を使用し、DSレコードとしてタイプフィールドをダイジェストRFC 4034で定義されたDSリソースレコード、5節とまったく同じワイヤおよびプレゼンテーション形式があります。 （これらのIANAレジストリは、「DNSセキュリティアルゴリズム番号」と「DS RRタイプアルゴリズム番号」レジストリとして知られています。）
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レコードタイプの特別な処理や取り扱い要件のいずれかを継承しません（RFC 4035のセクション3.1.4.1を参照）。 DSレコードとは異なり、DLVレコードはゾーンカットの親の側に表示されない場合があります。 DLVレコードは、しかし、ゾーンの頂点に表示されることがあります。
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 RRを使用しようとしない権威サーバとリゾルバのために、特別なセキュリティ上の懸念はありません - DLVのRRはちょうど、他の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 RRを使用したソフトウェアは、ほぼ確実にその使用に制約を課すことになるでしょうが、これらの制約は、最高のより完全レコードが使用されている方法の詳細を記述した文書で記述されるように残されています。最低でも、暗号化認証のいくつかの並べ替えなしでレコードを使用するために賢明だろう。より多くの可能性がない以上、DNSSEC自体がDLV RRを認証するために使用されます。 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.
RFC 4034、第8節は、DSのRRに固有のセキュリティ上の考慮事項について説明します。これらの考慮事項は、DLVのRRにも同様に適用可能です。特に注目すべきは、キータグフィールドを効率的にDNSKEY RRを選択するために使用されますが、それは一意に単一のDNSKEY RRを特定していません。二つの異なるDNSKEYのRRのは、同じ所有者名、同じアルゴリズムタイプ、および同じ鍵タグを持つことが可能です。 DNSKEY RRを選択するだけで、キーのタグを使用する実装は、いくつかの状況で間違った公開鍵を選択するかもしれません。
For further discussion of the security implications of DNSSEC, see RFC 4033, RFC 4034, and RFC 4035.
DNSSECのセキュリティへの影響のさらなる議論については、RFC 4033、RFC 4034、およびRFC 4035を参照してください。
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リソースレコードタイプレジストリの仕様必要な部分からDLVリソースレコードにDNSタイプコード32769が割り当てられている[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リソースレコード、ために使用されるタイプのレジストリをダイジェスト。
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[1]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[2]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのリソースレコード"、RFC 4034、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、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の考慮事項"、BCP 42、RFC 2929、2000年9月。
Authors' Addresses
著者のアドレス
Mark Andrews Internet Systems Consortium 950 Charter St. Redwood City, CA 94063 US
マーク・アンドリュースインターネットシステムコンソーシアム950チャーターセントレッドウッドシティ、CA 94063米国
EMail: Mark_Andrews@isc.org
メールアドレス：Mark_Andrews@isc.org
Samuel Weiler SPARTA, Inc. 7075 Samuel Morse Drive Columbia, Maryland 21046 US
サミュエル・ワイラーSPARTA、Inc.の7075サミュエル・モールスドライブコロンビア、メリーランド州21046米国
EMail: weiler@tislabs.com
メールアドレス：weiler@tislabs.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。