この文書はRFC3225の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (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.
運用上ＤＮＳＳＥＣ（ドメインネームシステムセキュリティ拡張）を実装す
るために、リゾルバがこれらの資源レコードを認識出ると明白な表示がある
時、ＤＮＳＳＥＣ対応サーバは自動的にＤＮＳＳＥＣ資源レコードの挿入を
行うべきです。この文書は明示的な表示を供給するためにＤＮＳ０ヘッダの
１ビットの使用を提案し、その通知を実行するために必要なプロトコル変更
を記述します。
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.
ＤＮＳＳＥＣ[RFC2535]は暗号のディジタル署名の使用を通してセキュリティ
対応リゾルバとアプリケーションにデータ完全性と認証を供給するために指
定されました。しかしながら、ＤＮＳＳＥＣの配置で、ＤＮＳＳＥＣ未対応
クライアントがＤＮＳＳＥＣ対応サーバに問い合わせる事がありそうです。
このような状態で、（署名ゾーンのデータの要求に返答している）ＤＮＳＳ
ＥＣ対応サーバは、署名と鍵とＮＸＴレコードを返すでしょう。次章で記述
された理由のために、このような回答はＤＮＳ基礎構造に重要な否定的な運
用上の影響があります。
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.
この文書はこれらの悪影響を避ける方法を論じます、すなわちＤＮＳＳＥＣ
対応サーバは、リゾルバから明示的にＤＮＳＳＥＣ資源レコードを理解でき
るとの表示がある場合にだけ、署名と鍵とＮＸＴ資源レコードを返すべきで
す。
For the purposes of this document, "DNSSEC security RRs" are
considered RRs of type SIG, KEY, or NXT.
この文書で「ＤＮＳＳＥＣセキュリティ資源レコード」とは、署名や鍵やＮ
ＸＴタイプの資源レコードです。
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"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"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.
初めに、ＤＮＳＳＥＣが配置される時、質問の大多数はＤＮＳＳＥＣ未対応
リゾルバからで、ＤＮＳＳＥＣセキュリティ資源レコードを理解しないかサ
ポートしないでしょう。このようなリゾルバからの質問がＤＮＳＳＥＣで署
名されたゾーンに送られてくる時、ＤＮＳＳＥＣ仕様はネームサーバが適切
なＤＮＳＳＥＣセキュリティ資源レコードと共に返答しなくてはならないこ
とを示します。ＤＮＳ ＵＤＰデータグラムが５１２バイト[RFC1035]に制限
されるから、ＤＮＳＳＥＣセキュリティ資源レコードを含む回答が、切り詰
められた回答を返す結果になる可能性が高く、リゾルバがＴＣＰを使って再
問合せをします。
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.
ＴＣＰ ＤＮＳ問合せが接続設定と切断のために重要なオーバーヘッドをもた
らします。運用上、これらのＴＣＰの問合せの影響はネットワークトラフィッ
クの増加と（典型的に１つの問合せ／応答で２パケットの代わりに５パケッ
トが必要になります）、追加の往復時間が遅延の増加と、追加の不要な問い
合わせのタイムアウトでの失敗と、ネームサーバの負荷の増加に関して多分
非常に有害であるでしょう。
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).
加えて、ＤＮＳＳＥＣの事前の実験的な配置で、ＤＮＳＳＥＣセキュリティ
資源レコードを含む回答を処理することが不可能なリゾルバがリゾルバ障害
（最悪の場合）や回答無視（良い場合）が報告されました。
Given these operational implications, explicitly notifying the
nameserver that the client is prepared to receive (if not understand)
DNSSEC security RRs would be prudent.
これらの運用上の意味で、明示的にクライアントが（もし理解できない）Ｄ
ＮＳＳＥＣセキュリティ資源レコードを受取る準備が出来ていると知らせる
ことは慎重であるでしょう。
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.
ＤＮＳＳＥＣのクライアント側のサポートが２つから成ると考えられます−
クライアントがすべてのＤＮＳＳＥＣセキュリティ資源レコードの受信をい
とわないか、あるいはいずれも受信したくないかのどちらかです。それで、
１ビットがクライアント側のＤＮＳＳＥＣサポートを示すことに十分です。
ＤＮＳＳＥＣの効率的な使用がＥＤＮＳ０[RFC2671]の必要を暗示するから、
「古典的」（非ＥＤＮＳ拡張ＤＮＳヘッダ）のビットは不足で、そして非対
応のキャッシュかフォワードサーバが、問合せが権威サーバへ渡されるとき
に古典的ヘッダから不適当にデータをコピーし、ＥＤＮＳ０ヘッダからの１
ビットの使用が提案される状況があるかもしれません。
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.
代わりのアプローチはＥＤＮＳ０ヘッダの存在をＤＮＳＳＥＣのクライアン
ト側のサポートの暗黙の表示として用いることでしょう。ＥＤＮＳ０をサポー
トするが、ＤＮＳＳＥＣの使用が不適当であるアプリケーションがあるかも
しれないから、この方法は選択されませんでした。
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:
クライアントのＤＮＳＳＥＣセキュリティ資源レコードの受け入れ（もしく
は理解）能力の明白な通知のために選ばれたメカニズムは問合せでＥＤＮＳ
０ ＯＰＴヘッダ上のＺフィールドの最上位ビットの使用です。このビットは
「ＤＮＳＳＥＣ承認」（ＤＯ）ビットと言います。ＥＤＮＳ０ ＯＰＴメタ資
源レコードＲＲで、ＤＯビットは、ＥＤＮＳ０ ＯＰＴメタ資源レコードの
「拡張ＲＣＯＤＥとフラグ」部の第３と第４バイトの第１ビットで、次のよ
うに組み立てられます：
+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.
質問でのＤＯビットの設定は、サーバにリゾルバがＤＮＳＳＥＣセキュリティ
資源レコードを受け入れることが可能であることを示します。ＤＯビットの
クリア（ゼロの設定）は、リゾルバがＤＮＳＳＥＣセキュリティ資源レコー
ドを処理する準備が出来ていないことを示し、これだの資源レコードは応答
で返されてはなりません(MUST NOT)（ＤＮＳＳＥＣセキュリティ資源レコー
ドが明示的に要求された場合を除く）。質問のＤＯビットが回答にコピーさ
れるに違いありません(MUST)。
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.
より明示的に、ＤＮＳＳＥＣ対応ネームサーバがはＤＯビットが要求で設定
されていなければ、[RFC2535]で指定されたように応答を認証するために署名
や鍵やＮＸＴレコードを入れてはなりません(MUST NOT)。明示的に署名や鍵
やＮＸＴやＡＮＹ問い合わせに一致するか、ＡＸＦＲかＩＸＦＲ問合せでの
ゾーンデータの一部としてのセキュリティレコードなは、ＤＯビットの設定
に関わらず含められます。
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.
再帰的ＤＮＳＳＥＣ対応サーバは、最初のリゾルバ要求に関わらず、再帰的
要求でＤＯビットを設定しなければなりません(MUST)。もし最初のリゾルバ
要求のＤＯビットが設定されていないなら、再帰的ＤＮＳＳＥＣ対応サーバ
は、キャッシュされたデータが修飾されてはならない(MUST NOT)としても、
クライアントにデータを返す前にＤＮＳＳＥＣセキュリティ資源レコードを
削除しなければなりません(MUST)。
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].
サーバがＤＯビットが設定されている問い合わせに対して、ＮＯＴＩＭＰや
ＦＯＲＭＥＲＲやＳＥＲＶＦＡＩＬ応答を返すときに、リゾルバはＤＮＳＳ
ＥＣセキュリティ資源レコードを期待するべきでなく(SHOULD NOT)、そして
[RFC2671]の５.３章のとおりにＥＤＮＳ０なしで問合せを再び行うべきです
(SHOULD)。
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.
ＤＯビット設定を持つ問合せに対しするＤＮＳＳＥＣデータなしの回答は、
回答が偽造されたか、変更された（ＤＯビットがクリアされた）問合せの偽
造されていない回答と考え、ゾーンでセキュリティ情報が利用可能ではない
と考えてはなりません(MUST NOT)。
IANA Considerations
ＩＡＮＡ考慮
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).
ＥＤＮＳ０[RFC2671]がＯＰＴレコードで１６ビット拡張フラグを定義します、
これらのビットはＯＰＴレコード（ＲＦＣ２６７１の４.６章）のＴＴＬフィー
ルドの中にコード化されます。
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
この文書はＯＫビットとしてこれらのビットの１つを予約します。最左ビッ
トが割り当てられることは要請されます。それでＯＰＴレコードのＴＴＬ
フィールドの使用が次のように見えるでしょう。
+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.
この文書はBob HalleyのラフなドラフトとOlafur GudmundssonとAndreas
GustafssonとBrian WellingtonとRandy BushとRob AusteinとSteve Bellovin
とErik Nordmarkの入力に基づきます。
References
参考文献
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
Author's Address
著者のアドレス
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
著作権表示全文
Copyright (C) The Internet Society (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.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。