RFC 3225 - Indicating Resolver Support of DNSSEC 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3225
タイトル : RFC 3225 - DNSSECのリゾルバーサポートを示す
翻訳編集 : 自動生成

[要約] RFC 3225は、DNSSECのリゾルバのサポートを示すための方法を提案しています。このRFCの目的は、DNSSECの導入と展開を促進し、セキュリティを向上させることです。

Network Working Group                                          D. Conrad
Request for Comments: 3225                                 Nominum, Inc.
Category: Standards Track                                  December 2001

Indicating Resolver Support of DNSSEC

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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.

DNSSEC（ドメイン名システムセキュリティ拡張機能）を操作的に展開するために、DNSSEC Awareサーバーは、リゾルバーがそれらのRRを理解できるという明示的な兆候がある場合にのみ、DNSSEC RRの自動包含を実行する必要があります。このドキュメントでは、EDNS0ヘッダーで少し使用することを提案して、その明示的な兆候を提供し、その通知を実装するために必要なプロトコルの変更を説明します。

1. Introduction

1. はじめに

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、キー、および/または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.

このドキュメントでは、これらのマイナスの影響を回避する方法について説明します。つまり、DNSSECを有するサーバーは、これらのRRSを理解できることをリゾルバーから明示的な兆候がある場合にのみ、SIG、キー、および/またはNXT RRSで応答する必要があります。

For the purposes of this document, "DNSSEC security RRs" are considered RRs of type SIG, KEY, or NXT.

このドキュメントの目的のために、「DNSSECセキュリティRRS」は、SIG、キー、または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].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。

2. Rationale

2. 根拠

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セキュリティRRSを理解またはサポートしていません。DNSSEC署名ゾーンに対してこのようなリゾルバーからのクエリを受信すると、DNSSEC仕様は、名前サーバーが適切なDNSSECセキュリティRRSで応答する必要があることを示します。DNS UDPデータグラムは512バイト[RFC1035]に制限されているため、DNSSECセキュリティRRSを含む応答は、切り捨てられた応答が返され、Resolverが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セキュリティRRを含む応答を処理できない非DNSSEC認識リゾルバーが、リゾルバーの障害（最悪の場合）または回答全体が無視されるという報告があります（より良いケース）。

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セキュリティRRSを受け取る準備ができている（理解していない場合）を受け取る準備ができていることを名前サーバーに明示的に通知します。

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.

別のアプローチは、EDNS0ヘッダーの存在を、DNSSECのクライアント側のサポートの暗黙的な兆候として使用することです。このアプローチは、EDNS0がサポートされているアプリケーションがあり、DNSSECの使用が不適切であるため、選択されていません。

3. Protocol Changes

3. プロトコルの変更

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セキュリティRRSを受け入れる（理解していない場合）クライアントが受け入れる能力の明示的な通知のために選択されたメカニズムは、クエリのEDNS0 OptヘッダーのZフィールドの最も重要なビットを使用しています。このビットは、「dnssec ok」（do）ビットと呼ばれます。EDNS0 OPT Meta-RRのコンテキストでは、DO BITは、EDNS0 OPT Meta-RRの「拡張Rcodeおよびフラグ」部分の3番目と4番目のバイトの最初のビットであり、次のように構成されています。

                +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.

クエリのDOビットを1に設定すると、リゾルバーがDNSSECセキュリティRRSを受け入れることができることがサーバーに示されます。DOビットクリア（ゼロに設定）は、ResolverがDNSSECセキュリティRRSを処理する準備ができていないことを示し、それらのRRは応答で返されてはなりません（DNSSECセキュリティ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.

より明確に、DNSSECを有する名前アーバーは、doビットがリクエストに設定されていない限り、[RFC2535]で指定されているように応答を認証するためにSIG、キー、またはNXT RRSを挿入してはなりません。明示的なSIG、キー、NXT、または任意のクエリに一致するセキュリティレコード、またはAXFRまたはIXFRクエリのゾーンデータの一部であることは、DO BITが設定されたかどうかが含まれています。

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セキュリティRRSを予想しないでください。

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 BITセットを使用したクエリに応じた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レコードのTTLフィールドにエンコードされます（RFC2671セクション4.6）。

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

このドキュメントは、これらのビットの1つを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.

この文書は、オラファー・グドムンツソン、アンドレアス・グスタフソン、ブライアン・ウェリントン、ランディ・ブッシュ、ロブ・オーストイン、スティーブ・ベロヴィン、エリック・ノードマークからの意見を伴うボブ・ハレーによる大まかなドラフトに基づいています。

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] 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月。

[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

David Conrad Nominum Inc. 950 Charter Street Redwood City、CA 94063 USA

   Phone: +1 650 381 6003
   EMail: david.conrad@nominum.com

Full Copyright Statement

完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。