この文書はRFC3655の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
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.
この文書はＲＦＣ２５３５で定義された仕様を変更します。実装経験から、
ＤＮＳヘッダの認証済データ（ＡＤ）ビットは有用ではありません。この文
書はＡＤビットを、もしすべての応答あるいは回答に応答がない事を示すレ
コードが暗号的に検証されたか、サーバのローカルポリシーに一致した場合
にのみ、設定すると再定義します。
1. Introduction
1. はじめに
Familiarity with the DNS system [RFC1035] and DNS security extensions
[RFC2535] is helpful but not necessary.
ＤＮＳシステム[RFC1035]とＤＮＳセキュリティ拡張[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.
ＲＦＣ２５３５（６.１章）で指定したように、応答のＡＤ（認証済データ）
ビットは、応答の回答と権威セクションのすべてのデータが、そのサーバの
ポリシーに従って認証されたことを示します。これは、従順なサーバがセキュ
リティポリシに違反したデータを返すべきではない(SHOULD)ので、実際は特に
有用ではありません。
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.
この文書はＡＤビットを、もしすべての回答のデータが暗号的に検証された
か、サーバのローカルセキュリティポリシに合致した場合のみに設定するよ
うに、再定義します。それで、正確に委任された不確実なデータを含んでい
る回答、とＤＮＳＳＥＣの鍵無しで構成を設定されたサーバが、いずれもＡ
Ｄを設定しないでしょう。前と同様に、検証に失敗したデータが返されない
でしょう。再起問合せを行うサーバと信頼関係を持っているホスト上で走ア
プリケーションが、データが安全であるかどうか決定するためにＡＤビット
値を使うことができます。
1.1. Motivation
1.1. 動機
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.
アプリケーションから直接呼ばれた完全ＤＮＳＳＥＣ対応リゾルバはアプリ
ケーションに応答の資源レコード集合のセキュリティ状態を返すことができ
ます。しかしながら、たいていのアプリケーションは、完全リゾルバである
外部再帰ネームサーバに依存する、限定的スタブリゾルバを使います。再帰
ネームサーバは応答でデータのセキュリティ状態を示唆するためにＡＤビッ
トを使うことができ、そしてローカルリゾルバはアプリケーションにこの情
報を渡すことができます。ここでのアプリケーションはＤＮＳツールを使っ
ている人あるいはソフトウェアアプリケーションです。
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.
ＡＤビットは、明示的に遠隔リゾルバを信頼するように設定された場合に限
り、そしてその場合には必ず、ローカルリゾルバによって使われるべきです
(SHOULD)。ＡＤビットは、再帰的ネームサーバが信頼されない時、無視され
るべきです(SHOULD)。
An alternate solution would be to embed a full DNSSEC resolver into
every application, but this has several disadvantages.
代わりの解決策はすべてのアプリケーションの中に完全ＤＮＳＳＥＣリゾル
バを埋め込むことですが、これはいくつかの欠点を持っています。
- DNSSEC validation is both CPU and network intensive, and caching
SHOULD be used whenever possible.
- ＤＮＳＳＥＣ認証はＣＰＵとネットワークに依存し、そしてキャッシュが
可能である時はいつでも使われるべきです(SHOULD)。
- 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.
- ＤＮＳＳＥＣは重要な設定を必要とします−ルート鍵と、ＤＮＳＳＥＣが
完全に実装されるまで存在する「セキュリティ孤島」のための鍵が設定さ
れる必要があります。設定場所はの数は最小であるべきです。
1.2. Requirements
1.2. 必要条件
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"と"SHOULD"
と"SHOULD NOT"と"RECOMMENDED"はＢＣＰ１４、ＲＦＣ２１１９[RFC2119]で
記述されるように解釈されるはずです。
1.3. Updated documents and sections
1.3. 更新される文書と章
The definition of the AD bit in RFC 2535, Section 6.1, is changed.
ＲＦＣ２５３５の６.１章のＡＤビットの定義は変えられます。
2. Setting of AD bit
2. ＡＤビットの設定
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.
要求のＣＤ（検査不可）ビットの設定は、応答のＡＤビットの設定に影響を
与えません。もしＣＤビットが設定されるなら、サーバは検査をしないでしょ
うが、もしデータがすでに暗号的に検証されたかローカルポリシに合致する
ならＡＤビットを設定すべきです(SHOULD)。ＤＯビット[RFC3225]でＤＮＳ
ＳＥＣレコードが求められ、関連した署名レコードが返ってきた場合にだけ、
ＡＤビットは設定されます(MUST)。
2.1. Setting of AD bit by recursive servers
2.1. 再帰サーバによるＡＤビット設定
Section 6.1 of RFC 2535 says:
ＲＦＣ２５３５の６.１章で以下が記述されます：
"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."
「ＡＤビットは、応答の回答と権威セクションの全ての資源レコードが認証
されたか不確実でない限り、設定してはなりません(MUST NOT)」
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."
「ＡＤビットは、応答の回答と権威セクションの全ての資源レコード集合が
認証されない限り、設定してはなりません(MUST NOT)」
"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."
「ＡＤビットは、もし回答セクションの全ての資源レコードと権威セクショ
ンの関連する否定的応答資源レコードが認証された場合にだけ、そしてそ
の場合には必ず、設定すべきです(SHOULD)」
A recursive DNS server following this modified specification will
only set the AD bit when it has cryptographically verified the data
in the answer.
この修正された仕様に従う再帰ＤＮＳサーバは、回答のデータが暗号的に検
証された時だけ、ＡＤビットを設定するだけでしょう。
2.2. Setting of AD bit by authoritative servers
2.2. 権威サーバによるＡＤビット設定
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.
安全なゾーンのプライマリサーバが、認証したように権限を持つ安全なゾー
ンを扱うポリシを持っているかもしれません(MAY)。セカンダリサーバが同じ
ポリシを持っているかもしれませんが(MAY)、ゾーンデータが安全に転送され
たか、データが検証されない限り、認証されている考えるべきではありませ
ん(SHOULD NOT)。権威サーバは、明示的に設定された場合にだけ、安全なゾー
ンからの権威回答のＡＤビットを設定するだけでなくてはなりません(MUST)。
この動作のデフォルトはオフであるべきです(SHOULD)。
Note that having the AD bit clear on an authoritative answer is
normal and expected behavior.
権威応答のＡＤビットが設定されていないのは標準的で予想される動作であ
ることに注意してください。
2.2.1. Justification for setting AD bit w/o verifying data
2.2.1. データ検証なしのＡＤビット設定の正当化
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.
権威サーバによるＡＤビット設定は、直接正式サーバに問い合わせて、そし
て信頼するように設定される、少数のリゾルバにだけに影響を与えます。こ
れは再帰と権威の両方の役割を果たすサーバに影響を与えるだけです。反復
リゾルバがＡＤビットを無視するべきです(SHOULD)。
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.
すべてのＤＮＳ回答が暗号的に検証されたデータを含んでいることを要求し
ている組織は、名前サーバが権威データの署名を有効にするように要求され
ないので、権威名前サーバと署名検証機能を分離する必要があるでしょう。
3. Interpretation of the AD bit
3. ＡＤビットの解釈
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.
回答か権威セクションに不確実と印されているデータを含む回答はＡＤビッ
トを設定してはなりません(MUST)。この場合、リゾルバは署名レコードが存
在しているか否かにかかわらず、データを不確実と扱うべきです(SHOULD)。
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.
リゾルバは、再帰名前サーバと安全なトランスポートメカニズム上で通信し
ているか、ＴＳＩＧ[RFC2845]やSIG(0)[RFC2931]のようなメッセージ認証を
使い、この再帰名前サーバを明確に信頼できると設定されない限り、でない
限りやみくもにＡＤビットを信頼してはなりません。
4. Applicability statement
4. 適用性宣言
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:
ＡＤビットはリゾルバが回答と権威セクションのレコードのＤＮＳＳＥＣ署
名を検証したという表示の伝達を意図します。ＡＤビットはＤＮＳデータの
最終利用者がＡＤビットを設定する中間リゾルバが信頼可能という確信を持っ
ている時だけ信頼されなくてはなりません(MUST)。これは以下のようなアウ
トバンドの方法でのみ達成できます：
- Fiat: An organization that can dictate whether it is OK to trust
certain DNS servers.
- 命令：ある特定のＤＮＳサーバを信頼することは問題がないかどうか指示
できる組織。
- Personal: Because of a personal relationship or the reputation of
a recursive nameserver operator, a DNS consumer can decide to
trust that recursive nameserver.
- 個人：再帰名前サーバオペレータとの個人的関係あるいは評判により、Ｄ
ＮＳ消費者がその再帰名前サーバを信頼することに決めることができます。
- 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.
これらの要因の一部でも足りない場合、再帰名前サーバからのＡＤビットは
信頼すべきではありません(SHOULD NOT)。例えば、ホームユーザがしばしば
ＩＳＰが再帰ＤＮＳサービスを供給することをあてにします；これらの再帰
名前サーバを信頼することは賢明ではありません。ローミング／旅行ホスト
が、セキュリティ状態が重要である情報を検索する時、ＤＨＣＰによって提
供される再帰ＤＮＳサーバを利用すべきではありません(SHOULD not)。
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.
後の２つの場合、末端消費者は信頼できる再帰名前サーバへのパスを完全に
信頼するか、あるいは安全なトランスポートがトラフィックを守るために利
用されているに違いありません。
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.
利用可能な満足な再帰名前サーバがない状態に直面した時、ローカルに動か
すことが勧められます(RECOMMENDED)。これは信頼できるという利点を持ち、
そしてＡＤビットはアプリケーションがスタブリゾルバを使うことを許すた
めにまだ使うことができます。
5. Security Considerations
5. セキュリティの考察
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].
この文書はＤＮＳヘッダの１ビットを再定義します。もしリゾルバがＡＤビッ
トの値を信頼するなら、応答者が、ＤＮＳサーバ／リゾルバがＤＯビット
[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.
権威サーバが、暗号検査をしないでＡＤビットを応答に設定するように、明
示的に設定されることができます。この行動はデフォルトでオフでなければ
なりません(MUST)。唯一の影響を受るリゾルバは、権威サーバに直接質問し
信頼するリゾルバで、そしてこの機能は権威サーバと再帰サーバの両方とし
て動作するサーバでだけ使われるべきです(SHOULD)。
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.
ＩＰｓｅｃや、ＴＳＩＧ[RFC2845]やＳＩＧ（０）[RFC2931]のようなメッセー
ジ認証を使用するなどで、伝達されないなら、リゾルバはやみくもにＡＤビッ
トを信頼してはなりません(MUST NOT)。加えて、リゾルバは明示的にこの再
帰ネームサーバを信頼するように設定されなければなりません。
6. IANA Considerations
6. ＩＡＮＡの考慮
None.
なし
7. Internationalization Considerations
7. 国際化の考慮
None. This document does not change any textual data in any
protocol.
なし。この文書はプロトコルのテキストデータを変えません。
8. Intellectual Property Rights Notice
8. 知的所有権宣言
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.
この文書に記述された実装や技術に関して主張される知的財産や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する調査をしたとは述べません。ＩＥＴＦ標準手続きと標準関連文書で
の権利に関しての手順の情報はＢＣＰ１１を見てください。出版に利用する
権利の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書
の実装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの
結果はＩＥＴＦ事務局で得られます。
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.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかＩＥＴＦ専務に情報を伝えてください。
9. Acknowledgments
9. 謝辞
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.
次の人々はこの文書のインプットを供給しました：Robert Elz、Andreas
Gustafsson、Bob Halley、Steven Jacob、Erik Nordmark、Edward Lewis、
Jakob Schlyter、Roy Arends、Ted Lindgreen。
10. Normative References
10. 参照する参考文献
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", 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.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0))", RFC 2931, September 2000.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001.
11. Authors' Addresses
11. 著者のアドレス
Brian Wellington
Nominum Inc.
2385 Bay Road
Redwood City, CA, 94063
USA
EMail: Brian.Wellington@nominum.com
Olafur Gudmundsson
3821 Village Park Drive
Chevy Chase, MD, 20815
USA
EMail: ogud@ogud.com
12. Full Copyright Statement
12. 著作権表示全文
Copyright (C) The Internet Society (2003). 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 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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。