Network Working Group B. Wellington
Request for Comments: 3655 O. Gudmundsson
Updates: 2535 November 2003
Category: Standards Track
Redefinition of DNS Authenticated Data (AD) bit
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy.
この文書は、実装経験に基づいて、RFC 2535で定義された仕様を変更し、DNSヘッダ内の認証されたデータ（AD）ビットは有用ではありません。この文書では、すべての答えやレコードが何の答えは、暗号検証された応答には存在しないか、そうでない場合は、サーバーのローカルセキュリティポリシーを満たしていることを証明する場合にのみ設定されているADビットな再定義します。
Familiarity with the DNS system [RFC1035] and DNS security extensions [RFC2535] is helpful but not necessary.
DNSシステム[RFC1035]とDNSセキュリティ拡張[RFC2535]に精通して役に立つが、必要ありません。
As specified in RFC 2535 (section 6.1), the AD (Authenticated Data) bit indicates in a response that all data included in the answer and authority sections of the response have been authenticated by the server according to the policies of that server. This is not especially useful in practice, since a conformant server SHOULD never reply with data that failed its security policy.
RFC 2535（セクション6.1）で指定されているように、AD（認証データ）ビットは、応答の答えと権威セクションに含まれるすべてのデータは、そのサーバーのポリシーに従って、サーバーによって認証されたことを受けて示しています。準拠サーバがセキュリティポリシーを失敗したデータを使用して返信することはありませんので、これは、実際には特に有用ではありません。
This document redefines the AD bit such that it is only set if all data in the response has been cryptographically verified or otherwise meets the server's local security policy. Thus, neither a response containing properly delegated insecure data, nor a server configured without DNSSEC keys, will have the AD set. As before, data that failed to verify will not be returned. An application running on a host that has a trust relationship with the server performing the recursive query can now use the value of the AD bit to determine whether the data is secure.
このドキュメントは、応答内のすべてのデータが暗号的に検証またはそれ以外の場合は、サーバーのローカルセキュリティポリシーを満たしてきた場合にのみ設定されるようにADビットを再定義します。このように、どちらも適切に委任安全でないデータを含む応答、またDNSSECキーなしで設定されたサーバは、ADが設定されていません。前と同じように、検証に失敗したデータが返されません。今データが安全であるかどうかを判断するためにADビットの値を使用することができます再帰クエリを実行するサーバーとの信頼関係を持っているホスト上で動作するアプリケーション。
A full DNSSEC capable resolver called directly from an application can return to the application the security status of the RRsets in the answer. However, most applications use a limited stub resolver that relies on an external recursive name server which incorporates a full resolver. The recursive nameserver can use the AD bit in a response to indicate the security status of the data in the answer, and the local resolver can pass this information to the application. The application in this context can be either a human using a DNS tool or a software application.
アプリケーションから直接呼び出すフルDNSSEC対応リゾルバは答えにアプリケーションへのRRsetのセキュリティステータスを返すことができます。しかし、ほとんどのアプリケーションは、フルリゾルバを搭載し、外部再帰ネームサーバに依存している限られたスタブリゾルバを使用します。再帰ネームサーバは、回答データのセキュリティ状態を示すために応答してADビットを使用することができ、そしてローカルリゾルバは、アプリケーションにこの情報を渡すことができます。この文脈でのアプリケーションは、DNSツールやソフトウェア・アプリケーションを使用して、ヒトのいずれかになります。
The AD bit SHOULD be used by the local resolver if and only if it has been explicitly configured to trust the remote resolver. The AD bit SHOULD be ignored when the recursive name server is not trusted.
明示的にリモートリゾルバを信頼するように設定されている場合にのみ場合ADビットは、ローカルリゾルバによって使用されるべきです。再帰ネームサーバが信頼されていないとき、ADビットは無視されるべきです。
An alternate solution would be to embed a full DNSSEC resolver into every application, but this has several disadvantages.
代替ソリューションは、すべてのアプリケーションに完全なDNSSECリゾルバを埋め込むことであろうが、これはいくつかの欠点を有しています。
- DNSSEC validation is both CPU and network intensive, and caching SHOULD be used whenever possible.
- DNSSEC検証はCPUとネットワークの両方集約的であり、そしてキャッシングは可能な限り使用されるべきです。
- DNSSEC requires non-trivial configuration - the root key must be configured, as well as keys for any "islands of security" that will exist until DNSSEC is fully deployed. The number of configuration points should be minimized.
- ルートキーを設定する必要があります、だけでなく、DNSSECが完全に展開されるまで存在するすべての「セキュリティの島」のキー - DNSSECは非自明な設定が必要です。設定点の数が最小化されるべきです。
The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
この文書におけるキーワード "MAY"、 "MAY NOT" "MUST"、 ""、 ""、 ""、 "" 推奨すべきでないMUST NOTは、BCP 14、RFC 2119 [RFC2119に記載されているように解釈されるべきです]。
The definition of the AD bit in RFC 2535, Section 6.1, is changed.
RFC 2535、セクション6.1でADビットの定義は、変更されました。
The presence of the CD (Checking Disabled) bit in a query does not affect the setting of the AD bit in the response. If the CD bit is set, the server will not perform checking, but SHOULD still set the AD bit if the data has already been cryptographically verified or complies with local policy. The AD bit MUST only be set if DNSSEC records have been requested via the DO bit [RFC3225] and relevant SIG records are returned.
クエリ内のCD（チェック無効）ビットの存在は、応答でADビットの設定には影響を与えません。 CDビットが設定されている場合、サーバーはチェックを行いませんが、既にデータが暗号的に検証またはローカルポリシーに準拠している場合は、まだADビットを設定する必要があります。 DNSSECレコードはDOビット[RFC3225]を介して要求されており、関連するSIGレコードが返された場合はADビットのみを設定しなければなりません。
Section 6.1 of RFC 2535 says:
RFC 2535の6.1節は述べています：
"The AD bit MUST NOT be set on a response unless all of the RRs in the answer and authority sections of the response are either Authenticated or Insecure."
「応答の答えと権威セクションにあるRRの全てが認証または安全でないのどちらかである場合を除きます。ADビットは、応答に設定してはなりません」
The replacement text reads:
置換テキストを読み取ります。
"The AD bit MUST NOT be set on a response unless all of the RRsets in the answer and authority sections of the response are Authenticated."
「応答の答えと権威セクション内のRRsetの全てが認証されない限り、ADビットは、応答に設定してはいけません。」
"The AD bit SHOULD be set if and only if all RRs in the answer section and any relevant negative response RRs in the authority section are Authenticated."
「と権威セクションの解答セクションのすべてのRRと関連するすべての否定応答のRRが認証されている場合だけADビットを設定する必要があります。」
A recursive DNS server following this modified specification will only set the AD bit when it has cryptographically verified the data in the answer.
それは暗号的な答えでデータを検証したときに、この変更仕様以下の再帰的なDNSサーバはADビットを設定します。
A primary server for a secure zone MAY have the policy of treating authoritative secure zones as Authenticated. Secondary servers MAY have the same policy, but SHOULD NOT consider zone data Authenticated unless the zone was transferred securely and/or the data was verified. An authoritative server MUST only set the AD bit for authoritative answers from a secure zone if it has been explicitly configured to do so. The default for this behavior SHOULD be off.
安全なゾーンのプライマリサーバが認証済みとして権威のセキュアゾーンを治療するためのポリシーを持っているかもしれません。セカンダリサーバは、同じポリシーを持っているかもしれませんが、ゾーンが確実に転送されたおよび/またはデータが確認された場合を除き、ゾーンデータが認証されたと考えるべきではありません。明示的にそうするように設定されている場合、権威サーバは、セキュアゾーンから正式な回答をADビットを設定しなければなりません。この動作のデフォルトはオフであるべきです。
Note that having the AD bit clear on an authoritative answer is normal and expected behavior.
公式の答えにADビットがクリア有するノーマルと期待される動作であることに注意してください。
The setting of the AD bit by authoritative servers affects only the small set of resolvers that are configured to directly query and trust authoritative servers. This only affects servers that function as both recursive and authoritative. Iterative resolvers SHOULD ignore the AD bit.
権威サーバによるADビットの設定は、直接照会し、権威サーバを信頼するように設定されているリゾルバの小さなセットのみに影響します。これは、再帰的かつ権威の両方として機能するサーバーに影響します。反復リゾルバは、ADビットを無視する必要があります。
The cost of verifying all signatures on load by an authoritative server can be high and increases the delay before it can begin answering queries. Verifying signatures at query time is also expensive and could lead to resolvers timing out on many queries after the server reloads zones.
権限のあるサーバーで負荷上のすべての署名を検証のコストが高くなり、それがクエリの応答を開始する前に、遅延が増加することができます。問合せ時に署名を検証することも高価であり、サーバがゾーンを再読み込みした後、リゾルバは、多くのクエリにタイムアウトにつながる可能性があります。
Organizations requiring that all DNS responses contain cryptographically verified data will need to separate the authoritative name server and signature verification functions, since name servers are not required to validate signatures of data for which they are authoritative.
すべてのDNS応答が暗号的に検証されたデータが含まれていることを必要とする組織は、ネームサーバが、彼らは権威であるためにデータの署名を検証するために必要とされていないため、権威ネームサーバと署名検証機能を分離する必要があります。
A response containing data marked Insecure in the answer or authority section MUST never have the AD bit set. In this case, the resolver SHOULD treat the data as Insecure whether or not SIG records are present.
データを含む応答は、ADビットがセットされていてはいけません答えや権威セクションに安全でないとマーク。この場合、リゾルバは、SIGレコードが存在するか否かを安全でないとしてデータを扱うべきです。
A resolver MUST NOT blindly trust the AD bit unless it communicates with a recursive nameserver over a secure transport mechanism or using a message authentication such as TSIG [RFC2845] or SIG(0) [RFC2931] and is explicitly configured to trust this recursive name server.
そのようなTSIG [RFC2845]またはSIG（0）[RFC2931]として再帰的なセキュアトランスポートメカニズム上のネームサーバまたはメッセージ認証を使用して通信し、明示的にこの再帰ネームサーバを信頼するように設定されていない限り、リゾルバは盲目的ADビットを信頼してはいけません。
The AD bit is intended to allow the transmission of the indication that a resolver has verified the DNSSEC signatures accompanying the records in the Answer and Authority section. The AD bit MUST only be trusted when the end consumer of the DNS data has confidence that the intermediary resolver setting the AD bit is trustworthy. This can only be accomplished via an out of band mechanism such as:
ADビットはリゾルバ回答と権威セクションのレコードを伴うDNSSEC署名を検証した指示の送信を可能にするように意図されています。 DNSデータの最終消費者は、ADビットを設定仲介リゾルバが信頼できるという確信を持っているとき、ADビットは、信頼されなければなりません。これはこのようなバンドの機構のうち介して達成することができます。
- Fiat: An organization that can dictate whether it is OK to trust certain DNS servers.
- フィアット：特定のDNSサーバを信頼するかどうかを決定づけるOKであることができ、組織。
- Personal: Because of a personal relationship or the reputation of a recursive nameserver operator, a DNS consumer can decide to trust that recursive nameserver.
- 個人：ので、個人的な関係や再帰的なネームサーバのオペレータの評判の、DNSの消費者は、その再帰的なネームサーバを信頼することを決定することができます。
- Knowledge: If a recursive nameserver operator posts the configured policy of a recursive nameserver, a consumer can decide that recursive nameserver is trustworthy.
- 知識：再帰的なネームサーバのオペレータの記事再帰ネームサーバの設定されたポリシー場合、消費者は、再帰的なネームサーバが信頼できると判断することができます。
In the absence of one or more of these factors AD bit from a recursive name server SHOULD NOT be trusted. For example, home users frequently depend on their ISP to provide recursive DNS service; it is not advisable to trust these recursive nameservers. A roaming/traveling host SHOULD not use recursive DNS servers offered by DHCP when looking up information where security status matters.
再帰ネームサーバからこれらの要因のADビットのうちの1つまたは複数の不在信頼するべきではありません。例えば、ホームユーザが頻繁に再帰的なDNSサービスを提供するために、彼らのISPによって異なります。これらの再帰的なネームサーバを信頼することはお勧めできません。ホストを旅ローミングは/情報セキュリティ状態の問題を探すときにDHCPが提供する再帰的なDNSサーバーを使用しないでください。
In the latter two cases, the end consumer must also completely trust the path to the trusted recursive name servers, or a secure transport must be employed to protect the traffic.
後者の2つのケースでは、最終消費者はまた、完全に信頼された再帰ネームサーバへのパスを信頼しなければならない、または安全な輸送は、トラフィックを保護するために使用しなければなりません。
When faced with a situation where there are no satisfactory recursive nameservers available, running one locally is RECOMMENDED. This has the advantage that it can be trusted, and the AD bit can still be used to allow applications to use stub resolvers.
利用可能な十分な再帰的なネームサーバが存在しない状況に直面すると、ローカルに1を実行することを推奨します。これは、信頼することができるという利点があり、ADビットは、まだアプリケーションがスタブリゾルバを使用することを可能にするために使用することができます。
This document redefines a bit in the DNS header. If a resolver trusts the value of the AD bit, it must be sure that the responder is using the updated definition, which is any DNS server/resolver supporting the DO bit [RFC3225].
この文書では、DNSヘッダ内のビットを再定義します。リゾルバは、ADビットの値を信頼している場合、応答者がDOビットをサポートしている任意のDNSサーバ/リゾルバで更新定義、[RFC3225]を使用していることを確認する必要があります。
Authoritative servers can be explicitly configured to set the AD bit on answers without doing cryptographic checks. This behavior MUST be off by default. The only affected resolvers are those that directly query and trust the authoritative server, and this functionality SHOULD only be used on servers that act both as authoritative and recursive name servers.
権威サーバは、明示的に暗号化のチェックをしない答えにADビットを設定するように構成することができます。この動作はデフォルトでオフでなければなりません。唯一の影響を受けたリゾルバは、直接権限のあるサーバーを照会し、信頼しているものであり、この機能は唯一の権威と再帰ネームサーバの両方として動作するサーバー上で使用されてください。
Resolvers (full or stub) that blindly trust the AD bit without knowing the security policy of the server generating the answer can not be considered security aware.
盲目的に答えを生成するサーバーのセキュリティポリシーを知らなくても、ADビットを信頼（完全またはスタブ）リゾルバは、セキュリティを意識し考えることはできません。
A resolver MUST NOT blindly trust the AD bit unless it communicates such as IPsec, or using message authentication such as TSIG [RFC2845] or SIG(0) [RFC2931]. In addition, the resolver must have been explicitly configured to trust this recursive name server.
そのようなTSIG [RFC2845]またはSIG（0）[RFC2931]とのIPsec、またはメッセージ認証を使用してこのような通信をしない限り、リゾルバは盲目的ADビットを信頼してはいけません。また、リゾルバは、明示的に、この再帰ネームサーバーを信頼するように設定されている必要があります。
None.
無し。
None. This document does not change any textual data in any protocol.
無し。このドキュメントは、任意のプロトコルで任意のテキストデータは変更されません。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
The following people have provided input on this document: Robert Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark, Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen.
ロバート・エルツ、アンドレアス・グスタフソン、ボブハレー、スティーブン・ヤコブ、エリックNordmarkと、エドワード・ルイス、ヤコブSchlyter、ロイ・アレンズ、テッドLindgreen：次の人は、この文書の入力を提供してきました。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", 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月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]いるVixie、P.、グドムンソン、O.、イーストレイク3日、D.とB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、RFC 2845、2000年5月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0))", RFC 2931, September 2000.
[RFC2931]イーストレイク、D.、 "DNS要求とトランザクション署名（SIG（0））"、RFC 2931、2000年9月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225]コンラッド、D.、 "DNSSECのレゾルバサポートを示す"、RFC 3225、2001年12月。
Brian Wellington Nominum Inc. 2385 Bay Road Redwood City, CA, 94063 USA
ブライアンウェリントンノミナム社2385ベイロードレッドウッドシティ、CA、94063 USA
EMail: Brian.Wellington@nominum.com
メールアドレス：Brian.Wellington@nominum.com
Olafur Gudmundsson 3821 Village Park Drive Chevy Chase, MD, 20815 USA
オラフルグドムンソン3821ビレッジパークドライブチェビーチェイス、メリーランド、20815 USA
EMail: ogud@ogud.com
メールアドレス：ogud@ogud.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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 assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。