RFC3225 日本語訳
3225 Indicating Resolver Support of DNSSEC. D. Conrad. December 2001. (Format: TXT=11548 bytes) (Updated by RFC4033, RFC4034, RFC4035) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Conrad Request for Comments: 3225 Nominum, Inc. Category: Standards Track December 2001
コメントを求めるワーキンググループD.コンラッドの要求をネットワークでつないでください: 3225年のNominum Inc.カテゴリ: 標準化過程2001年12月
Indicating Resolver Support of DNSSEC
DNSSECのレゾルバサポートを示します。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
レゾルバがそれらのRRsを理解できるという明白な指示があるときだけ、DNSSEC(ドメインネームシステムSecurity Extensions)を操作上配布するために、DNSSECの意識しているサーバはDNSSEC RRsの自動包含を実行するべきです。 このドキュメントは、その明白な指示を提供する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、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.
このドキュメントはこれらの負の衝撃を避けるメソッドについて議論します、レゾルバからのそれらのRRsを理解できるという明白な指示があるときだけ、すなわち、DNSSEC意識しているサーバがSIG、KEY、そして/または、NXT RRsと共に反応するべきです。
For the purposes of this document, "DNSSEC security RRs" are considered RRs of type SIG, KEY, or NXT.
このドキュメントの目的のために、「DNSSECセキュリティRRs」はタイプSIGのRRs、KEY、またはNXTであると考えられます。
Conrad Standards Track [Page 1] RFC 3225 Indicating Resolver Support of DNSSEC December 2001
2001年12月にDNSSECのレゾルバサポートを示すコンラッド標準化過程[1ページ]RFC3225
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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セキュリティがRRsであるとDNSSEC意識していないレゾルバから来ていて、理解するか、またはサポートしません。 ゾーンであると署名されるDNSSECのためにそのようなレゾルバからの質問を受けるとき、DNSSEC仕様は、ネームサーバが適切なDNSSECセキュリティRRsと共に応じなければならないのを示します。 DNS UDPデータグラムが512バイト[RFC1035]に制限されるとき、DNSSECセキュリティRRsを含む応答で、返されて、レゾルバは、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セキュリティRRsを含む応答を扱うことができない非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のクライアントサイドサポートが2進であると思われます--クライアントが、すべてのDNSSECセキュリティRRsを受け取っても構わないと思っているか、またはそれはいずれも受け入れることを望んでいません。 そういうものとして、1ビットは、クライアントサイド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ヘッダーの存在を使用するだろうことです。 サポートされますが、DNSSECの使用がEDNS0が不適当である利用があるかもしれなくて、このアプローチは選ばれませんでした。
Conrad Standards Track [Page 2] RFC 3225 Indicating Resolver Support of DNSSEC December 2001
2001年12月にDNSSECのレゾルバサポートを示すコンラッド標準化過程[2ページ]RFC3225
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」(する)ビットと呼ばれます。 EDNS0 OPTメタ-RRの文脈で以下の3の番目ものの最初のビットとEDNS0 OPTメタ-RRの「拡張RCODEと旗」一部の4番目のバイトであり、構造化されたビットをしてください:
+0 (MSB) +1 (LSB) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | EXTENDED-RCODE | VERSION | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: |DO| Z | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+0(MSB) +1(LSB) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | 拡張RCODE| バージョン| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: |してください。| 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つにビットをしてください。設定、レゾルバがDNSSECセキュリティRRsを受け入れることができるのをサーバに示します。 する、きれいにされた(ゼロに設定します)ビットが、レゾルバがDNSSECセキュリティRRsを扱うために用意ができていないのを示して、応答でそれらのRRsを返してはいけない、(RRsが明らかに質問されるDNSSECセキュリティ) コピーされたコネが応答であったに違いないなら質問のビットをしてください。
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意識しているネームサーバが[RFC2535]の指定されるとしての応答を認証するためにSIG、KEY、またはNXT RRsを挿入してはいけない、要求に設定されました。 ビットをしてください。明白なSIG、KEY、NXT、またはどんな質問にも合っているか、またはAXFRかIXFR質問のためのゾーンデータの一部であるセキュリティ記録が含まれている、設定されました。
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意識しているサーバがセットしなければならない、状態にかかわらず再帰的な要求のビットをする、開始しているレゾルバ要求のビットをしてください。 しかしながら、データをクライアントに返す前に、噛み付いているセット、再帰的なDNSSEC意識しているサーバが取り外されなければならないのをDNSSECセキュリティRRsをしている、キャッシュされたデータを持っていないレゾルバが、要求する開始を変更してはいけないなら。
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].
イベントでは、サーバがそれが持っている質問への応答をNOTIMP、FORMERRまたはSERVFAILに返す、噛み付いているセットをしてください、そして、レゾルバSHOULD NOTはDNSSECセキュリティRRsを予想して、[RFC2671]のセクション5.3によると、SHOULDはEDNS0なしで質問を再試行します。
Conrad Standards Track [Page 3] RFC 3225 Indicating Resolver Support of DNSSEC December 2001
2001年12月にDNSSECのレゾルバサポートを示すコンラッド標準化過程[3ページ]RFC3225
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.
質問に対応したDNSSECデータの欠如、鍛造されて、セットが応答が情報が利用可能である帯状にならないセキュリティであるかもしれませんが、全く意味するのに要してはいけないビットか変えられた(きれいにされたビットをする)質問の非偽造している応答をしてください。
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に噛み付いたので、このドキュメントはこれらのビットの1つを予約します。 最も噛み付かれた左が割り当てられるよう要求されています。 したがって、OPTの記録的なTTL分野のUSEは似ているでしょう。
+0 (MSB) +1 (LSB) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | EXTENDED-RCODE | VERSION | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: |DO| Z | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+0(MSB) +1(LSB) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | 拡張RCODE| バージョン| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: |してください。| 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.
ボブ・ハレーのこのドキュメントはOlafurグドムンソン、アンドレアス・グスタファソン、ブライアン・ウェリントン、ランディ・ブッシュ、ロブAustein、スティーブBellovin、およびエリックNordmarkからの入力で素案に基づいています。
References
参照
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡張機能」、RFC2671、1999年8月。
Conrad Standards Track [Page 4] RFC 3225 Indicating Resolver Support of DNSSEC December 2001
2001年12月にDNSSECのレゾルバサポートを示すコンラッド標準化過程[4ページ]RFC3225
Author's Address
作者のアドレス
David Conrad Nominum Inc. 950 Charter Street Redwood City, CA 94063 USA
デヴィッドコンラッドNominum Inc.950憲章通りカリフォルニア94063レッドウッドシティー(米国)
Phone: +1 650 381 6003 EMail: david.conrad@nominum.com
以下に電話をしてください。 +1 6003年の650 381メール: david.conrad@nominum.com
Conrad Standards Track [Page 5] RFC 3225 Indicating Resolver Support of DNSSEC December 2001
2001年12月にDNSSECのレゾルバサポートを示すコンラッド標準化過程[5ページ]RFC3225
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Conrad Standards Track [Page 6]
コンラッド標準化過程[6ページ]
一覧
スポンサーリンク