Network Working Group D. Conrad
Request for Comments: 3225 Nominum, Inc.
Category: Standards Track December 2001
Indicating Resolver Support of 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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification.
リゾルバがこれらのRRを理解できることを明示がある場合に運用DNSSEC（ドメインネームシステムセキュリティ拡張）を展開するためには、DNSSEC対応サーバはDNSSEC RRの自動含めることを実行する必要があります。この文書は、明示的な指示を提供するEDNS0ヘッダ内のビットの使用を提案し、その通知を実装するために必要なプロトコルの変更を記載しています。
DNSSEC [RFC2535] has been specified to provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. However, as DNSSEC is deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware servers. In such situations, the DNSSEC-aware server (responding to a request for data in a signed zone) will respond with SIG, KEY, and/or NXT records. For reasons described in the subsequent section, such responses can have significant negative operational impacts for the DNS infrastructure.
DNSSEC [RFC2535]は、暗号化、デジタル署名を使用して、セキュリティ対応リゾルバとアプリケーションへのデータの整合性と認証を提供するために指定されています。 DNSSECが展開されているようしかし、非DNSSEC対応クライアントは、おそらくDNSSEC対応のサーバーを照会します。そのような状況では、DNSSEC対応サーバ（署名されたゾーン内のデータに対する要求に応答する）がSIG、KEY、及び/又はNXTレコードで応答します。以降のセクションで説明した理由により、そのような応答は、DNSインフラストラクチャのための有意な負の運用の影響を持つことができます。
This document discusses a method to avoid these negative impacts, namely DNSSEC-aware servers should only respond with SIG, KEY, and/or NXT RRs when there is an explicit indication from the resolver that it can understand those RRs.
この文書では、それは、これらのRRを理解することができますリゾルバからの明示的な兆候があるとき、すなわちDNSSEC対応サーバーのみSIG、KEY、および/またはNXT用のRRで応答しなければならないこれらの悪影響を回避する方法について説明します。
For the purposes of this document, "DNSSEC security RRs" are considered RRs of type SIG, KEY, or NXT.
このドキュメントの目的のために、「DNSSECセキュリティRRは」タイプSIG、KEY、またはNXTのRRを考えられています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Initially, as DNSSEC is deployed, the vast majority of queries will be from resolvers that are not DNSSEC aware and thus do not understand or support the DNSSEC security RRs. When a query from such a resolver is received for a DNSSEC signed zone, the DNSSEC specification indicates the nameserver must respond with the appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to 512 bytes [RFC1035], responses including DNSSEC security RRs have a high probability of resulting in a truncated response being returned and the resolver retrying the query using TCP.
DNSSECが展開されると最初に、クエリの大半は意識DNSSECされていないので、DNSSECセキュリティRRを理解したり、サポートしていませんリゾルバからとなります。このようなレゾルバからのクエリはDNSSEC署名済みゾーンの受信されたときに、DNSSEC仕様は、ネームサーバが適切なDNSSECセキュリティ資源レコードで応答しなければならない示します。 DNS UDPデータグラムが512バイト[RFC1035]に限定されるように、DNSSECセキュリティRRを含む応答が切り捨て応答をもたらすの高い確率戻されるとレゾルバリトライTCPを使用してクエリを持っています。
TCP DNS queries result in significant overhead due to connection setup and teardown. Operationally, the impact of these TCP queries will likely be quite detrimental in terms of increased network traffic (typically five packets for a single query/response instead of two), increased latency resulting from the additional round trip times, increased incidences of queries failing due to timeouts, and significantly increased load on nameservers.
TCPのDNSクエリは、接続セットアップとティアダウンのために大きなオーバーヘッドになります。操作上、これらのTCPクエリの影響がありそうな増加ネットワークトラフィックの面で非常に有害となります（通常は2つではなく、単一のクエリ/レスポンスのための5つのパケット）追加の往復時間から生じ、待ち時間の増加は、原因失敗したクエリの発生率を増加させました大幅にタイムアウト、およびネームサーバへの負荷を増加させました。
In addition, in preliminary and experimental deployment of DNSSEC, there have been reports of non-DNSSEC aware resolvers being unable to handle responses which contain DNSSEC security RRs, resulting in the resolver failing (in the worst case) or entire responses being ignored (in the better case).
また、DNSSECの予備的かつ実験的な展開で、中（非DNSSEC対応リゾルバは、（最悪の場合には）失敗したレゾルバで、その結果、DNSSECセキュリティRRを含んで応答を処理することができないというか、全体の応答は無視されているとの報告がなされていますより良い場合）。
Given these operational implications, explicitly notifying the nameserver that the client is prepared to receive (if not understand) DNSSEC security RRs would be prudent.
明示的に（理解していない場合）、クライアントがDNSSECセキュリティRRは賢明だろう受け取るために準備されたネームサーバに通知し、これらの操作の影響を考えます。
Client-side support of DNSSEC is assumed to be binary -- either the client is willing to receive all DNSSEC security RRs or it is not willing to accept any. As such, a single bit is sufficient to indicate client-side DNSSEC support. As effective use of DNSSEC implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS enhanced DNS header) are scarce, and there may be situations in which non-compliant caching or forwarding servers inappropriately copy data from classic headers as queries are passed on to authoritative servers, the use of a bit from the EDNS0 header is proposed.
DNSSECのクライアント側のサポートは、バイナリであると仮定される - のいずれかのクライアントは、すべてのDNSSECセキュリティRRを受信する意思があるか、いずれかを受け入れることを望んでいません。そのため、単一のビットは、クライアント側のDNSSECサポートを示すのに十分です。 DNSSECの有効利用がEDNS0 [RFC2671]の必要性を意味するように、「古典的な」（非EDNS拡張DNSヘッダ）のビットが不足している、および非準拠キャッシュまたは転送サーバが不適切古典からデータをコピーする状況があるかもしれませんクエリは権威サーバに渡されるようにヘッダは、EDNS0ヘッダからのビットを使用することが提案されています。
An alternative approach would be to use the existence of an EDNS0 header as an implicit indication of client-side support of DNSSEC. This approach was not chosen as there may be applications in which EDNS0 is supported but in which the use of DNSSEC is inappropriate.
別のアプローチは、DNSSECのクライアント側サポートの暗黙の指標としてEDNS0ヘッダの存在を使用することであろう。このアプローチは、EDNS0がサポートされているが、ここでDNSSECの使用が不適切である用途があるかもしれないとして選択されませんでした。
The mechanism chosen for the explicit notification of the ability of the client to accept (if not understand) DNSSEC security RRs is using the most significant bit of the Z field on the EDNS0 OPT header in the query. This bit is referred to as the "DNSSEC OK" (DO) bit. In the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of the third and fourth bytes of the "extended RCODE and flags" portion of the EDNS0 OPT meta-RR, structured as follows:
（理解していない場合）DNSSECセキュリティRRを受け入れるために、クライアントの能力を明示的に通知するために選ばれたメカニズムは、クエリ内のEDNS0のOPTヘッダ上のZフィールドの最上位ビットを使用しています。このビットは、「DNSSECのOK」（DO）ビットと呼ばれています。 EDNS0 OPTメタRRの文脈において、DOビットは次のように構成され、EDNS0 OPTメタRRの「拡張RCODEとフラグ」部分の第三及び第四のバイトの最初のビットです。
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Setting the DO bit to one in a query indicates to the server that the resolver is able to accept DNSSEC security RRs. The DO bit cleared (set to zero) indicates the resolver is unprepared to handle DNSSEC security RRs and those RRs MUST NOT be returned in the response (unless DNSSEC security RRs are explicitly queried for). The DO bit of the query MUST be copied in the response.
クエリで1にDOビットを設定すると、リゾルバがDNSSECセキュリティRRを受け入れることができることをサーバーに通知します。 DOは、ビットクリア（ゼロに設定）リゾルバはDNSSECセキュリティRRを処理するために準備ができていないですし、（DNSSECセキュリティのRRが明示的に照会されていない限り）それらのRRが応答で返されてはならないを示しています。クエリのDOビットが応答にコピーされなければなりません。
More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, or NXT RRs to authenticate a response as specified in [RFC2535] unless the DO bit was set on the request. Security records that match an explicit SIG, KEY, NXT, or ANY query, or are part of the zone data for an AXFR or IXFR query, are included whether or not the DO bit was set.
DOビットが要求に設定されていない限り、より明示的に、DNSSEC対応ネームサーバは、[RFC2535]で指定された応答を認証するSIG、KEY、またはNXT RRを挿入してはなりません。明示的なSIG、KEY、NXT、または任意のクエリに一致する、またはAXFRまたはIXFRクエリのゾーンデータの一部であるセキュリティレコードは、DOビットがセットされたかどうか含まれています。
A recursive DNSSEC-aware server MUST set the DO bit on recursive requests, regardless of the status of the DO bit on the initiating resolver request. If the initiating resolver request does not have the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC security RRs before returning the data to the client, however cached data MUST NOT be modified.
再帰的なDNSSEC対応サーバが開始リゾルバ要求にかかわらず、DOビットの状態を、再帰的な要求にDOビットを設定しなければなりません。 DOを持っていません開始リゾルバ要求ビットをセットした場合、再帰的なDNSSEC対応サーバはクライアントにデータを返す前に、DNSSECセキュリティRRを削除しなければならない、しかし、キャッシュされたデータを変更してはいけません。
In the event a server returns a NOTIMP, FORMERR or SERVFAIL response to a query that has the DO bit set, the resolver SHOULD NOT expect DNSSEC security RRs and SHOULD retry the query without EDNS0 in accordance with section 5.3 of [RFC2671].
サーバはDOビットが設定有するクエリにNOTIMP、FORMERR又はSERVFAIL応答を返す場合には、リゾルバはDNSSECセキュリティRRを期待すべきではないと[RFC2671]のセクション5.3に従ってEDNS0なしでクエリを再試行すべきです。
Security Considerations
セキュリティの考慮事項
The absence of DNSSEC data in response to a query with the DO bit set MUST NOT be taken to mean no security information is available for that zone as the response may be forged or a non-forged response of an altered (DO bit cleared) query.
DOビットが設定されたクエリに応答してDNSSECデータが存在しない場合には、セキュリティ情報を意味しないと解釈してはいけません応答は（ビットがクリアDO）変更されたクエリの応答を偽造または非偽造することができるように、そのゾーンのために利用可能です。
IANA Considerations
IANAの考慮事項
EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record, these bits are encoded into the TTL field of the OPT record (RFC2671 section 4.6).
EDNS0 [RFC2671]はOPTレコードの拡張フラグとして16ビットを定義し、これらのビットはOPTレコード（RFC2671のセクション4.6）のTTLフィールドに符号化されます。
This document reserves one of these bits as the OK bit. It is requested that the left most bit be allocated. Thus the USE of the OPT record TTL field would look like
この文書はOKビットとしてこれらのビットのいずれかを予約しています。一番左のビットが割り当てられることを要求されています。したがって、OPTレコードのTTLフィールドの使用は次のようになります。
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Acknowledgements
謝辞
This document is based on a rough draft by Bob Halley with input from Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush, Rob Austein, Steve Bellovin, and Erik Nordmark.
この文書はオラフルグドムンソン、アンドレアス・グスタフソン、ブライアンウェリントン、ランディブッシュ、ロブAusteinと、スティーブBellovin氏、およびエリックNordmarkとからの入力にボブハレーによって草稿に基づいています。
References
リファレンス
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]いるVixie、P.、 "DNS用拡張メカニズム（EDNS0）"、RFC 2671、1999年8月。
Author's Address
著者のアドレス
David Conrad Nominum Inc. 950 Charter Street Redwood City, CA 94063 USA
デヴィッド・コンラッドノミナム社950憲章通りカリフォルニア州レッドウッドシティー94063 USA
Phone: +1 650 381 6003 EMail: david.conrad@nominum.com
電話：+1 650 381 6003 Eメール：david.conrad@nominum.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。