[要約] RFC 3655は、DNSの認証済みデータ（AD）ビットの再定義に関するものであり、DNSセキュリティの向上を目的としています。
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
DNS認証データ（AD）ビットの再定義
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.
Copyright（c）The Internet Society（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有能リゾルバーは、アプリケーションに返信されるRRSetsのセキュリティステータスを返すことができます。ただし、ほとんどのアプリケーションは、完全なリゾルバーを組み込んだ外部再帰名サーバーに依存する限られたスタブリゾルバーを使用しています。再帰的な名前サーバーは、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ビットは、リモートリゾルバーを信頼するように明示的に構成されている場合にのみ、ローカルリゾルバーが使用する必要があります。再帰的な名前サーバーが信頼されていない場合、広告ビットは無視する必要があります。
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」、「「必須」、「必須」、「そうでない」、「そうでなければ」、「そうでない」、「そうではない」、「推奨」、このドキュメントのキーは、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ビットを設定する必要があります。ADビットは、DOビット[RFC3225]を介してDNSSECレコードが要求され、関連するSIGレコードが返された場合にのみ設定する必要があります。
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."
「回答の回答と権限のセクションのすべてが認証されていない限り、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.
信頼できる答えで広告を少し明確にすることは、正常で予想される動作であることに注意してください。
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.
権威あるサーバーによる広告ビットの設定は、権威あるサーバーを直接クエリおよび信頼するように構成されている小さなリゾルバーのセットのみに影響します。これは、再帰的かつ権威ある両方として機能するサーバーにのみ影響します。反復リゾルバーは、広告ビットを無視する必要があります。
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.
AnswerまたはAuthorityのセクションで安全でないマークされたデータを含む応答は、ADビットを設定してはなりません。この場合、Resolverは、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]などのメッセージ認証を使用して、この再帰名サーバーを信頼するように明示的に構成されている場合を除き、広告ビットを盲目的に信頼してはなりません。。
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ビットは、ResolverがAnswer and Authorityセクションの記録に伴うDNSSECシグネチャを検証したことを示す兆候の送信を可能にすることを目的としています。ADビットは、DNSデータの最終消費者が、ADビットを設定する中間リゾルバーが信頼できるという自信を持っている場合にのみ信頼する必要があります。これは、以下のようなバンド外のメカニズムを介してのみ実現できます。
- Fiat: An organization that can dictate whether it is OK to trust certain DNS servers.
- Fiat：特定のDNSサーバーを信頼しても問題ないかどうかを決定できる組織。
- 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.
これらの要因の1つまたは複数が再帰的な名前サーバーからのADビットがない場合、信頼されるべきではありません。たとえば、ホームユーザーは頻繁にISPに依存して再帰的なDNSサービスを提供します。これらの再帰的な名前サーバーを信頼することはお勧めできません。ローミング/旅行ホストは、セキュリティステータスが重要な情報を調べるときに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ヘッダーで少し再定義されます。Resolverが広告ビットの値を信頼している場合、Responderが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.
権威あるサーバーは、暗号化チェックを行わずにADSビットを回答に設定するように明示的に構成できます。この動作はデフォルトでオフにする必要があります。唯一の影響を受けるレゾルバーは、権威あるサーバーを直接クエリして信頼するものであり、この機能は、権威ある名前サーバーと再帰名サーバーの両方として機能するサーバーでのみ使用する必要があります。
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.
回答を生成するサーバーのセキュリティポリシーを知らずに広告ビットを盲目的に信頼するリゾルバー（フルまたはスタブ）は、セキュリティに気付くとは見なされません。
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.
Resolverは、IPSECなどの通信、またはTSIG [RFC2845]やSIG（0）[RFC2931]などのメッセージ認証を使用しない限り、広告ビットを盲目的に信頼してはなりません。さらに、リゾルバーは、この再帰名サーバーを信頼するように明示的に構成されている必要があります。
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.
次の人々は、ロバート・エルツ、アンドレアス・グスタフソン、ボブ・ハレー、スティーブン・ジェイコブ、エリック・ノードマーク、エドワード・ルイス、ヤコブ・シュライター、ロイ・アレンズ、テッド・リンドグリーンの意見を提供しています。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、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.、Gudmundsson、O.、Eastlake 3rd、D。and B. Wellington、「DNS（TSIG）のシークレットキートランザクション認証」、RFC 2845、2000年5月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0))", RFC 2931, September 2000.
[RFC2931] Eastlake、D。、「DNSリクエストとトランザクション署名（SIG（0））」、RFC 2931、2000年9月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225] Conrad、D。、「DNSSECのリゾルバーサポートを示す」、RFC 3225、2001年12月。
Brian Wellington Nominum Inc. 2385 Bay Road Redwood City, CA, 94063 USA
ブライアン・ウェリントン・ノミナム・インク2385ベイ・ロード・レッドウッド・シティ、カリフォルニア州、94063 USA
EMail: Brian.Wellington@nominum.com
Olafur Gudmundsson 3821 Village Park Drive Chevy Chase, MD, 20815 USA
Olafur Gudmundsson 3821 Village Park Drive Chevy Chase、MD、20815 USA
EMail: ogud@ogud.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。