この文書はRFC2845の日本語訳です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group P. Vixie
Request for Comments: 2845 ISC
Category: Standards Track O. Gudmundsson
Updates: 1035 NAI Labs
D. Eastlake 3rd
Motorola
B. Wellington
Nominum
May 2000
Secret Key Transaction Authentication for DNS (TSIG)
ＤＮＳのための秘密鍵処理認証(TSIG)
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 (2000). All Rights Reserved.
Abstract
概要
This protocol allows for transaction level authentication using
shared secrets and one way hashing. It can be used to authenticate
dynamic updates as coming from an approved client, or to authenticate
responses as coming from an approved recursive name server.
このプロトコルは共有秘密鍵と一方向ハッシュ関数を使って処理レベル認証
を提供します。これは公認クライアントから来るダイナミック更新を認証し
たり、認められた再帰ネームサーバーから来るとして回答を認証するために
使うことができます。
No provision has been made here for distributing the shared secrets;
it is expected that a network administrator will statically configure
name servers and clients using some out of band mechanism such as
sneaker-net until a secure automated mechanism for key distribution
is available.
秘密鍵の共有手段はここでは準備していません；安全な自動鍵分配機構が利
用可能になるまで、ネットワーク管理者が、歩いて設定に行くような、なに
かネットワーク外の方法を使って静的にネームサーバーとクライアントを設
定すると考えられます。
1 - Introduction
1 - はじめに
1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
hierarchical distributed database system that provides information
fundamental to Internet operations, such as name <=> address
translation and mail handling information. DNS has recently been
extended [RFC2535] to provide for data origin authentication, and
public key distribution, all based on public key cryptography and
public key based digital signatures. To be practical, this form of
security generally requires extensive local caching of keys and
tracing of authentication through multiple keys and signatures to a
pre-trusted locally configured key.
1.1. ドメインネームシステム（ＤＮＳ）[RFC1034, RFC1035]は、名前＜＝＞
アドレス翻訳のようなインターネットオペレーションにとって重要な情報と
メール扱い情報を供給する階層的な分散データベースシステムです。ＤＮＳ
で最近データ源認証と公開鍵配布を供給するため拡張されました[RFC2535]、
これらは公開鍵暗号と公開鍵に基づくディジタル署名によります。実際の所、
この種のセキュリティは一般に大規模なローカルキャッシュと、認証のため
にあらかじめローカルに設定された鍵から署名と鍵の多数の連鎖を必要とし
ます。
1.2. One difficulty with the [RFC2535] scheme is that common DNS
implementations include simple "stub" resolvers which do not have
caches. Such resolvers typically rely on a caching DNS server on
another host. It is impractical for these stub resolvers to perform
general [RFC2535] authentication and they would naturally depend on
their caching DNS server to perform such services for them. To do so
securely requires secure communication of queries and responses.
[RFC2535] provides public key transaction signatures to support this,
but such signatures are very expensive computationally to generate.
In general, these require the same complex public key logic that is
impractical for stubs. This document specifies use of a message
authentication code (MAC), specifically HMAC-MD5 (a keyed hash
function), to provide an efficient means of point-to-point
authentication and integrity checking for transactions.
1.2. [RFC2535]計画の持つ困難の１つが一般的なＤＮＳ実装にはキャッシュ
を持たない単純なスタブ（切り株）リゾルバがある事です。このようなリゾ
ルバは一般に他のホスト上のキャッシュを持つＤＮＳサーバーに頼ります。
一般的な[RFC2535]認証を行うことはこれらのスタブリゾルバにとって非実用
的で、それらは当然このようなサービスをキャッシュを持つＤＮＳサーバー
に頼るでしょう。安全にこれをするには問合せと回答の安全な通信を必要と
します。[RFC2535]がこれをサポートするために公開鍵処理署名を供給します
が、署名は計算量的に生成に非常にコストがかかります。一般に、これらは
スタブのために非実用的な複雑な公開鍵処理を必要とします。この文書は、
処理を検査する効果的なポイントポイント認証と完全性を供給する、メッセー
ジ認証コード（ＭＡＣ）、特にHMAC-MD5（鍵付きハッシュ関数）、の使い方
を指定します。
1.3. A second area where use of straight [RFC2535] public key based
mechanisms may be impractical is authenticating dynamic update
[RFC2136] requests. [RFC2535] provides for request signatures but
with [RFC2535] they, like transaction signatures, require
computationally expensive public key cryptography and complex
authentication logic. Secure Domain Name System Dynamic Update
([RFC2137]) describes how different keys are used in dynamically
updated zones. This document's secret key based MACs can be used to
authenticate DNS update requests as well as transaction responses,
providing a lightweight alternative to the protocol described by
[RFC2137].
1.3. まじめな[RFC2535]公開鍵利用メカニズムが非実用的な２番目の場面は
ダイナミック更新[RFC2136]リクエスト認証です。[RFC2535]が問合せ署名を
共有しますが、[RFC2535]は処理署名と同じように計算量的に高価な公開鍵暗
号と複雑なロジックを必要とします。安全なドメインネームシステムダイナ
ミック更新([RFC2137])が異なる鍵をダイナミックゾーン更新でどのように使
うか説明します。この文書の秘密鍵によるMACは、[RFC2137]で記述されたプ
ロトコルに軽量の選択肢を供給し、処理取引同様に、ＤＮＳ更新要求の認証
で使えます。
1.4. A further use of this mechanism is to protect zone transfers.
In this case the data covered would be the whole zone transfer
including any glue records sent. The protocol described by [RFC2535]
does not protect glue records and unsigned records unless SIG(0)
(transaction signature) is used.
1.4. このメカニズムの他の用途はゾーン転送の保護です。この場合、保護範
囲は接着剤を含むゾーン全体でしょう。[RFC2535]で記述されたプロトコルは
SIG(0)（処理署名）を使わなければ接着剤レコードと無署名レコードを保護
しません。
1.5. The authentication mechanism proposed in this document uses
shared secret keys to establish a trust relationship between two
entities. Such keys must be protected in a fashion similar to
private keys, lest a third party masquerade as one of the intended
parties (forge MACs). There is an urgent need to provide simple and
efficient authentication between clients and local servers and this
proposal addresses that need. This proposal is unsuitable for
general server to server authentication for servers which speak with
many other servers, since key management would become unwieldy with
the number of shared keys going up quadratically. But it is suitable
for many resolvers on hosts that only talk to a few recursive
servers.
1.5. この文書で提案する認証メカニズムは２者間の信頼関係を確立するため
に共有秘密鍵を使います。このような鍵は、第三者が意図的などちらかにな
りすまさないように（模造ＭＡＣ）、プライベート鍵同様に保護しなければ
なりません。クライアントとローカルサーバーの間に単純で効果的な認証を
緊急に供給する必要がある場合、この提案はニーズを満たします。この提案
は、鍵管理が必要な共有鍵の数がどんどん増え実用的でなくなるだろうから、
多くの他のサーバーと話をするサーバー間の認証には一般に不適当です。け
れども少数の再帰サーバーと話をするだけのホストのリゾルバに適しています。
1.6. A server acting as an indirect caching resolver -- a "forwarder"
in common usage -- might use transaction-based authentication when
communicating with its small number of preconfigured "upstream"
servers. Other uses of DNS secret key authentication and possible
systems for automatic secret key distribution may be proposed in
separate future documents.
1.6. 間接的なキャッシュリゾルバとして動作するサーバ--普通は「フォワー
ダ」に使う--が少数の事前設定「上流」サーバと通信するのに処理認証を使
うかもしれません。ＤＮＳ秘密鍵認証のほかの使い方と自動的な秘密鍵配布
が未来の別の文書で提案されるかもしれません。
1.7. New Assigned Numbers
1.7. 新しく割当てられる番号
RRTYPE = TSIG (250)
ERROR = 0..15 (a DNS RCODE)
ERROR = 16 (BADSIG)
ERROR = 17 (BADKEY)
ERROR = 18 (BADTIME)
1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in [RFC
2119].
1.8. この文書のキーワード"MUST"と"REQUIRED"と"SHOULD"と"RECOMMENDED"
と"MAY"は[RFC 2119]で記述された様に解釈されるはずです。
2 - TSIG RR Format
2 - TSIG資源レコードフォーマット
2.1 TSIG RR Type
2.1 TSIG資源レコードタイプ
To provide secret key authentication, we use a new RR type whose
mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and
MUST not be cached. TSIG RRs are used for authentication between DNS
entities that have established a shared secret key. TSIG RRs are
dynamically computed to cover a particular DNS transaction and are
not DNS RRs in the usual sense.
秘密鍵認証を提供するため、名前がTSIGでタイプコードが２５０の新しい資
源レコードタイプを使います。TSIGはメタ資源レコードであり、キャッシュ
されてはなりません(MUST not)。TSIG資源レコードは共有秘密鍵を確立した
ＤＮＳエンティティー間の認証に使います。TSIG資源レコードはあるＤＮＳ
処理をカバーするため動的に計算され、通常のＤＮＳ資源レコードではあり
ません。
2.2 TSIG Calculation
2.2 TSIG計算
As the TSIG RRs are related to one DNS request/response, there is no
value in storing or retransmitting them, thus the TSIG RR is
discarded once it has been used to authenticate a DNS message. The
only message digest algorithm specified in this document is "HMAC-
MD5" (see [RFC1321], [RFC2104]). The "HMAC-MD5" algorithm is
mandatory to implement for interoperability. Other algorithms can be
specified at a later date. Names and definitions of new algorithms
MUST be registered with IANA. All multi-octet integers in the TSIG
record are sent in network byte order (see [RFC1035 2.3.2]).
TSIG資源レコードはある１つのＤＮＳ問合せ／回答に関連し、記憶したり再
送したりする事がないので、TSIG資源レコードはＤＮＳメッセージが本物と
証明するのに使われた途端に捨てられます。唯一のこの文書で指定された
メッセージ要約アルゴリズムは"HMAC- MD5"です（[RFC1321], [RFC2104]参
照）。"HMAC-MD5"アルゴリズムは互換性のために実装が必須です。他のアル
ゴリズムが後で指定できます。新しいアルゴリズムの名前と定義がＩＡＮＡ
に登録されなくてはなりません。すべてのTSIGレコードでマルチオクテット
整数はネットワークバイトオーダーで送られます （[RFC1035 2.3.2]参照）。
2.3. Record Format
2.3. レコードフォーマット
NAME The name of the key used in domain name syntax. The name
should reflect the names of the hosts and uniquely identify
the key among a set of keys these two hosts may share at any
given time. If hosts A.site.example and B.example.net share a
key, possibilities for the key name include
<id>.A.site.example, <id>.B.example.net, and
<id>.A.site.example.B.example.net. It should be possible for
more than one key to be in simultaneous use among a set of
interacting hosts. The name only needs to be meaningful to
the communicating hosts but a meaningful mnemonic name as
above is strongly recommended.
名前 鍵の名前はドメイン名前構文を使います。名前はホスト名前を反映し
て、２つのホストがその時共有する鍵の集合をユニークに鍵を識別し
ます。もしホストA.site.exampleとホストB.example.netは鍵を共有す
るなら、鍵の名前は<id>.A.site.example.や<id>.B.example.net.や
<id>.A.site.example.B.example.net.が考えられます。１つ以上の鍵
が接続ホスト間で同時に使用可能であるべきです。名前は通信してい
るホスト間で意味をもつ必要があるだけですが、上記のような意味の
ある名前が強く推薦されています。
The name may be used as a local index to the key involved and
it is recommended that it be globally unique. Where a key is
just shared between two hosts, its name actually only need
only be meaningful to them but it is recommended that the key
name be mnemonic and incorporate the resolver and server host
names in that order.
名前は鍵のローカルインデックスとして用いられるかもしれず、世界
的規模でユニークであることが勧められます。鍵は２つのホスト間で
共有され２者間で分かればいいだけだが、鍵名がわかりやすくリゾル
バとホスト名をその順で含むのが進められます。
TYPE TSIG (250: Transaction SIGnature)
タイプ TSIG(250:処理署名)
CLASS ANY
クラス 任意
TTL 0
ＴＴＬ ０
RdLen (variable)
資源データ長 (可変長)
RDATA
資源データ
Field Name Data Type Notes
フィールド名 データタイプ ノート
--------------------------------------------------------------
Algorithm Name domain-name Name of the algorithm
in domain name syntax.
アルゴリズム名 ドメイン名 ドメイン名形式のアルゴリズムの名前
Time Signed u_int48_t seconds since 1-Jan-70 UTC.
署名時刻 u_int48_t 1970年1月1日(UTC)からの秒数
Fudge u_int16_t seconds of error permitted
in Time Signed.
誤差 u_int16_t 署名時刻に許される誤差
MAC Size u_int16_t number of octets in MAC.
MACサイズ u_int16_t ＭＡＣのオクテット数
MAC octet stream defined by Algorithm Name.
MAC オクテット列 アルゴリズム名毎に定義
Original ID u_int16_t original message ID
元のＩＤ u_int16_t 元のメッセージのＩＤ
Error u_int16_t expanded RCODE covering
TSIG processing.
エラー u_int16_t TSIG処理をカバーする拡張応答コード
Other Len u_int16_t length, in octets, of
Other Data.
他の長さ u_int16_t 他のデータのオクテット単位の長さ
Other Data octet stream empty unless Error == BADTIME
他のデータ オクテット列 エラーが悪い時間でなければ空
2.4. Example
2.4. 例
NAME HOST.EXAMPLE.
TYPE TSIG
CLASS ANY
TTL 0
RdLen as appropriate
RDATA
Field Name Contents
-------------------------------------
Algorithm Name SAMPLE-ALG.EXAMPLE.
Time Signed 853804800
Fudge 300
MAC Size as appropriate
MAC as appropriate
Original ID as appropriate
Error 0 (NOERROR)
Other Len 0
Other Data empty
3 - Protocol Operation
3 - プロトコル処理
3.1. Effects of adding TSIG to outgoing message
3.1. 外向きメッセージにTSIGを追加する効果
Once the outgoing message has been constructed, the keyed message
digest operation can be performed. The resulting message digest will
then be stored in a TSIG which is appended to the additional data
section (the ARCOUNT is incremented to reflect this). If the TSIG
record cannot be added without causing the message to be truncated,
the server MUST alter the response so that a TSIG can be included.
This response consists of only the question and a TSIG record, and
has the TC bit set and RCODE 0 (NOERROR). The client SHOULD at this
point retry the request using TCP (per [RFC1035 4.2.2]).
外向きメッセージが組み立てられると、鍵付きメッセージ要約処理が行えま
す。出来上がった要約は追加データセクションにTSIGとして追加されます
（ARCOUNTがこれを反映するために増加する）。もしTSIGレコードを追加する
スペースがなければ、サーバーはTSIGを含められるように回答を変えなくて
はなりません(MUST)。この回答は質問とTSIGレコードだけから成り立ち、
TCビットが設定され応答コードは０（エラーなし）です。クライアントはこ
の時点でTCPを使って問合せをするべきです(SHOULD)([RFC1035 4.2.2]によっ
て)。
3.2. TSIG processing on incoming messages
3.2. 入力メッセージのTSIG処理
If an incoming message contains a TSIG record, it MUST be the last
record in the additional section. Multiple TSIG records are not
allowed. If a TSIG record is present in any other position, the
packet is dropped and a response with RCODE 1 (FORMERR) MUST be
returned. Upon receipt of a message with a correctly placed TSIG RR,
the TSIG RR is copied to a safe location, removed from the DNS
Message, and decremented out of the DNS message header's ARCOUNT. At
this point the keyed message digest operation is performed. If the
algorithm name or key name is unknown to the recipient, or if the
message digests do not match, the whole DNS message MUST be
discarded. If the message is a query, a response with RCODE 9
(NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17
(BADKEY) or TSIG ERROR 16 (BADSIG). If no key is available to sign
this message it MUST be sent unsigned (MAC size == 0 and empty MAC).
A message to the system operations log SHOULD be generated, to warn
the operations staff of a possible security incident in progress.
Care should be taken to ensure that logging of this type of event
does not open the system to a denial of service attack.
もし入力メッセージがTSIGレコードを含むなら、それは追加のセクションの
最後のレコードに違いありません(MUST)。複数のTSIGレコードは許されませ
ん。もしTSIGレコードが他場所にあるならパケットは捨てられ、応答コード
１（フォーマットエラー）の回答が返されなくてはなりません(MUST)。TSIG
資源レコードが正しく設定されたメッセージを受取ったら、TSIG資源レコー
ドをメッセージから切り離し別の安全な場所に置き、 ＤＮＳメッセージヘッ
ダーのARCOUNTを減少させます。この時点で鍵付きメッセージ要約処理を行い
ます。もしアルゴリズム名か鍵名が受信者の知らないものであるか、メッセー
ジ要約が一致しないなら、ＤＮＳメッセージ全体が捨てられます(MUST)。も
しメッセージが問合せなら、 TSIGエラー１７（誤った鍵）かTSIGエラー１６
（誤った署名）で応答コード９（否認証）の回答がメッセージ送信元に送ら
れます(MUST)。もしこのメッセージを署名できる鍵がなければ、無署名で送
らなければなりません（メッセージ認証コードサイズ＝０でメッセージ認証
コードは空）。セキュリティ事件の経過をオペレーションスタッフに警告す
るため、システムオペレーションログへのメッセージが生成されるべきです
(SHOULD)。サービス拒否攻撃によって、イベントのログがシステム破壊につ
ながらない様に注意すべきです。
3.3. Time values used in TSIG calculations
3.3. 時間値がTSIG計算で使われる
The data digested includes the two timer values in the TSIG header in
order to defend against replay attacks. If this were not done, an
attacker could replay old messages but update the "Time Signed" and
"Fudge" fields to make the message look new. This data is named
"TSIG Timers", and for the purpose of digest calculation they are
invoked in their "on the wire" format, in the following order: first
Time Signed, then Fudge. For example:
再生攻撃から守るため要約データのTSIGヘッダは２つのタイマー値を含みま
す。もしこれがなければ攻撃者が古いメッセージを再送できます、「署名時
刻」と「誤差」フィールドがメッセージを新しくします。このデータは
「TSIGタイマ」と命名され、要約計算のためこれはそしてダイジェスト計算
の目的で署名時間と誤差の順で「ワイヤフォーマット」で使われます。例えば：
Field Name Value Wire Format Meaning
フィールド名 値 ワイヤフォーマット 意味
----------------------------------------------------------------------
Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997
署名時刻 853804800 00 00 32 e4 07 00 １９９７年１月２１日火曜日０時０分０秒
Fudge 300 01 2C 5 minutes
誤差 300 01 2C ５分
3.4. TSIG Variables and Coverage
3.4. TSIG変数と適用範囲。
When generating or verifying the contents of a TSIG record, the
following data are digested, in network byte order or wire format, as
appropriate:
TSIGレコードの内容を生成する検証する時、次のデータが適切なネットワー
クバイト順かワイヤフォーマットで要約されます：
3.4.1. DNS Message
3.4.1. ＤＮＳメッセージ
A whole and complete DNS message in wire format, before the TSIG RR
has been added to the additional data section and before the DNS
Message Header's ARCOUNT field has been incremented to contain the
TSIG RR. If the message ID differs from the original message ID, the
original message ID is substituted for the message ID. This could
happen when forwarding a dynamic update request, for example.
ＴＳＩＧ資源レコードの追加データセクションへの追加とＤＮＳメッセージ
ヘッダのとARCOUNTフィールドの増加の前の、全体の完全なＤＮＳメッセージ
のワイヤフォーマット。もしメッセージＩＤが元のメッセージＩＤとは違う
なら、元のメッセージＩＤがメッセージＩＤの代わりに用いられます。これ
は、例えば、ダイナミック更新要求を転送する時に起きます。
3.4.2. TSIG Variables
3.4.2. TSIG変数
Source Field Name Notes
情報源 フィールド名 ノート
-----------------------------------------------------------------------
TSIG RR NAME Key name, in canonical wire format
TSIG RR 名前 鍵名、標準的ワイヤフォーマット
TSIG RR CLASS (Always ANY in the current specification)
TSIG RR クラス (現在の仕様では常にANY)
TSIG RR TTL (Always 0 in the current specification)
TSIG RR TTL (現在の仕様では常に０)
TSIG RDATA Algorithm Name in canonical wire format
TSIG RDATA アルゴリズム名 標準的ワイヤフォーマット
TSIG RDATA Time Signed in network byte order
TSIG RDATA 署名時刻 ネットワークバイト順
TSIG RDATA Fudge in network byte order
TSIG RDATA 誤差 ネットワークバイト順
TSIG RDATA Error in network byte order
TSIG RDATA エラー ネットワークバイト順
TSIG RDATA Other Len in network byte order
TSIG RDATA 他の長さ ネットワークバイト順
TSIG RDATA Other Data exactly as transmitted
TSIG RDATA 他のデータ 正確に伝送した通り
The RR RDLEN and RDATA MAC Length are not included in the hash since
they are not guaranteed to be knowable before the MAC is generated.
資源レコード資源データ長と資源データメッセージ認証コード長はメッセー
ジ認証コードを生成する前にわからないのでハッシュに含めません。
The Original ID field is not included in this section, as it has
already been substituted for the message ID in the DNS header and
hashed.
元の識別子フィールドは、すでにＤＮＳヘッダーでメッセージＩＤの代
わりに用いられるので、このセクションに含めません。
For each label type, there must be a defined "Canonical wire format"
that specifies how to express a label in an unambiguous way. For
label type 00, this is defined in [RFC2535], for label type 01, this
is defined in [RFC2673]. The use of label types other than 00 and 01
is not defined for this specification.
各ラベルタイプで、明確な方法でラベルを表現する方法を指定する「規準的
なワイヤフォーマット」が定義されるに違いありません。ラベルタイプ００
については、[RFC2535]で定義され、ラベルタイプ０１については、[RFC2673]
で定義されます。００と０１以外のラベルタイプの使用はこの仕様書で定義
されません。
3.4.3. Request MAC
3.4.3. 問合せメッセージ認証コード
When generating the MAC to be included in a response, the request MAC
must be included in the digest. The request's MAC is digested in
wire format, including the following fields:
回答に含めるMACを生成する時、問合せののMACは要約に含めなければなりま
せん。要求のMACはワイヤフォーマットで、次のフィールドを含みますます：
Field Type Description
フィールド タイプ 詳細
---------------------------------------------------
MAC Length u_int16_t in network byte order
MAC長 u_int16_t ネットワークバイト順
MAC Data octet stream exactly as transmitted
MACデータ オクテット列 正確に転送した通り
3.5. Padding
3.5. 詰め物
Digested components are fed into the hashing function as a continuous
octet stream with no interfield padding.
要約される要素はフィールド間に隙間を開けずに連続オクテット列としてハッ
シュ機能に入れられます。
4 - Protocol Details
4 - プロトコル詳細
4.1. TSIG generation on requests
4.1. 問合せでのTSIG生成
Client performs the message digest operation and appends a TSIG
record to the additional data section and transmits the request to
the server. The client MUST store the message digest from the
request while awaiting an answer. The digest components for a
request are:
クライアントがメッセージ要約処理を行い、追加データセクションにTSIGレコー
ドを添えて、サーバーに問合せを送ります。クライアントは答えを待つ間に、
問合せのメッセージ要約を覚えておかなければなりません(MUST)。問合せの要
約要素は以下です：
DNS Message (request) ＤＮＳメッセージ（問合せ）
TSIG Variables (request) TSIG変数（問合せ）
Note that some older name servers will not accept requests with a
nonempty additional data section. Clients SHOULD only attempt signed
transactions with servers who are known to support TSIG and share
some secret key with the client -- so, this is not a problem in
practice.
ある古いネームサーバーが追加データセクションが空でない問合せを受け入
れないであろうことに注意してください。クライアントはTSIGをサポートし、
クライアントと秘密鍵を共有すると知っているサーバーとだけ署名処理を試
みるべきです(SHOULD)−従って実際にはこれは問題になりません。
4.2. TSIG on Answers
4.2. 回答のTSIG
When a server has generated a response to a signed request, it signs
the response using the same algorithm and key. The server MUST not
generate a signed response to an unsigned request. The digest
components are:
サーバーが署名された問合せの回答を生成する時、同じアルゴリズムと鍵を
使って回答に署名します。サーバーは署名なしの問合せに対して署名された
反応を生成してはなりません(MUST not)。要約要素はは以下です：
Request MAC 問合せメッセージ認証コード
DNS Message (response) ＤＮＳメッセージ（回答）
TSIG Variables (response) TSIG変数（回答）
4.3. TSIG on TSIG Error returns
4.3. TSIGエラー応答のTSIG
When a server detects an error relating to the key or MAC, the server
SHOULD send back an unsigned error message (MAC size == 0 and empty
MAC). If an error is detected relating to the TSIG validity period,
the server SHOULD send back a signed error message. The digest
components are:
サーバーが鍵やMACに関連するエラーを検出した時、サーバーは無署名のエラー
メッセージ（MACサイズ==０でMACは空）を返送するべきです(SHOULD)。もし
エラーがTSIG有効期間に関連していて検出されるなら、サーバーは署名され
たエラーメッセージを返送するべきです(SHOULD)。要約要素は以下です：
Request MAC (if the request MAC validated) 問合せメッセージ認証コード（問合せMACが検証できたら）
DNS Message (response) ＤＮＳメッセージ（回答）
TSIG Variables (response) TSIG変数（回答）
The reason that the request is not included in this digest in some
cases is to make it possible for the client to verify the error. If
the error is not a TSIG error the response MUST be generated as
specified in [4.2].
問合せにこのダイジェストが含まれない理由は、クライアントがエラーの確
認を可能にするためです。もしエラーがTSIGエラーではないなら、回答は
[4.2]で指定されるように、生成されなくてはなりません(MUST)。
4.4. TSIG on TCP connection
4.4. ＴＣＰ接続でのTSIG
A DNS TCP session can include multiple DNS envelopes. This is, for
example, commonly used by zone transfer. Using TSIG on such a
connection can protect the connection from hijacking and provide data
integrity. The TSIG MUST be included on the first and last DNS
envelopes. It can be optionally placed on any intermediary
envelopes. It is expensive to include it on every envelopes, but it
MUST be placed on at least every 100'th envelope. The first envelope
is processed as a standard answer, and subsequent messages have the
following digest components:
ＤＮＳのＴＣＰ接続は多数のＤＮＳ封筒を含むことができます。これは、例
えば、普通にゾーン転送で使われます。このような接続上でTSIGを使うこと
は接続乗っ取りから守り、データ完全性を供給することができます。TSIGは
最初と最後のＤＮＳ封筒の上に含まれなくてはなりません(MUST)。そしてど
の中間封筒にもオプションで置くことができます。全ての封筒に含めるのは
高くつきますが、少なくとも１００枚の封筒ごとに含めなければなりません
(MUST)。最初の封筒は標準的な答えの処理をし、次のメッセージが以下の要
約要素で処理されます：
Prior Digest (running) 前の要約（動作中）
DNS Messages (any unsigned messages since the last TSIG)
ＤＮＳメッセージ（最後のTSIGからの無署名の全メッセージ）
TSIG Timers (current message) TSIGタイマー（現在のメッセージ）
This allows the client to rapidly detect when the session has been
altered; at which point it can close the connection and retry. If a
client TSIG verification fails, the client MUST close the connection.
If the client does not receive TSIG records frequently enough (as
specified above) it SHOULD assume the connection has been hijacked
and it SHOULD close the connection. The client SHOULD treat this the
same way as they would any other interrupted transfer (although the
exact behavior is not specified).
検出したら時点で接続を閉じてやり直しができます。もしクライアントの
TSIG検証がが失敗したら、クライアントは接続を閉じなくてはなりません
(MUST)。もしクライアントが十分な数のTSIGレコードを受け取らないなら
（上で指定されるように）、接続がジャックされたと想定すべきで(SHOULD)、
接続を閉じるべきです(SHOULD)。（正確な行動が指定されないけれども）ク
ライアントはこれらを他の転送の中断と同様に扱うべきです(SHOULD)。
4.5. Server TSIG checks
4.5. サーバーのTSIG検査
Upon receipt of a message, server will check if there is a TSIG RR.
If one exists, the server is REQUIRED to return a TSIG RR in the
response. The server MUST perform the following checks in the
following order, check KEY, check TIME values, check MAC.
メッセージの受領の上に、サーバーが TSIG 資源レコード (TSIG RR) がある
かどうか調べるでしょう。もし署名が存在するなら、サーバーは回答でTSIG
資源レコードを返すように要求されます(REQUIRED)。サーバーは以下の検査
を、鍵検査、時間変数検査、MAC検査の順で行わなければなりません(MUST)。
4.5.1. KEY check and error handling
4.5.1. 鍵検査とエラー処理
If a non-forwarding server does not recognize the key used by the
client, the server MUST generate an error response with RCODE 9
(NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be unsigned
as specified in [4.3]. The server SHOULD log the error.
もし非転送サーバーがクライアントの使った鍵を認識しないなら、サーバー
は応答コード９（非認証）とTSIGエラー１７（悪い鍵）のエラー回答を生み
出さなくてはなりません(MUST)。この回答は[4.3]で指定されるように署名
なしに違いありません。サーバーはエラーをログファイルに書くべきです
(SHOULD)。
4.5.2. TIME check and error handling
4.5.2. 時間検査とエラー処理
If the server time is outside the time interval specified by the
request (which is: Time Signed, plus/minus Fudge), the server MUST
generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18
(BADTIME). The server SHOULD also cache the most recent time signed
value in a message generated by a key, and SHOULD return BADTIME if a
message received later has an earlier time signed value. A response
indicating a BADTIME error MUST be signed by the same key as the
request. It MUST include the client's current time in the time
signed field, the server's current time (a u_int48_t) in the other
data field, and 6 in the other data length field. This is done so
that the client can verify a message with a BADTIME error without the
verification failing due to another BADTIME error. The data signed
is specified in [4.3]. The server SHOULD log the error.
もしサーバーの時間が問合せで指定された期間（署名時刻±誤差）の外なら、
サーバーは応答コード９９（非認証）とTSIGエラー１８（悪い時間）のエラー
回答を生成します(MUST)。サーバーは鍵によってメッセージを署名した最後の
時間を記憶すべきで(SHOULD)、最後の署名時間よりも前に署名されたメッセー
ジを受取るなら悪い時間を返すべきです(SHOULD)。悪い時間を示す回答が要求
と同じ鍵で署名されなくてはなりません(MUST)。これは署名時刻フィールドに
クライアントの現在時刻を、他のデータフィールドにサーバーの現在時刻
（u_int48_t）を含めなければならず(MUST)、他のデータ長は６です。これは、
新たな悪い時間エラーにならずに、クライアントが悪い時間エラーの検証を可
能にします。署名されたデータは[4.3]で指定されます。サーバーはエラーをロ
グファイルに書くべきです(SHOULD)。
4.5.3. MAC check and error handling
4.5.3. メッセージ認証コード検査とエラー処理
If a TSIG fails to verify, the server MUST generate an error response
as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16
(BADSIG). This response MUST be unsigned as specified in [4.3]. The
server SHOULD log the error.
TSIG検査に失敗するなら、サーバーは応答コード９（非認証）でTSIGエラー
１６（悪い署名）の[4.3]で示したエラー回答を生み出さなくてはなりません
(MUST)。この回答は[4.3]で指定されるように署名なしに違いありません。
サーバーはエラーをログファイルに書くべきです(SHOULD)。
4.6. Client processing of answer
4.6. クライアントの回答処理
When a client receives a response from a server and expects to see a
TSIG, it first checks if the TSIG RR is present in the response.
Otherwise, the response is treated as having a format error and
discarded. The client then extracts the TSIG, adjusts the ARCOUNT,
and calculates the keyed digest in the same way as the server. If
the TSIG does not validate, that response MUST be discarded, unless
the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to
verify the response as if it were a TSIG Error response, as specified
in [4.3]. A message containing an unsigned TSIG record or a TSIG
record which fails verification SHOULD not be considered an
acceptable response; the client SHOULD log an error and continue to
wait for a signed response until the request times out.
クライアントがサーバーから回答を受け取り、TSIGがあると予期する時、最
初にTSIG資源レコードが回答に存在しているか調べます。なければ、反応は
フォーマットエラーと見なされて、捨てられます。クライアントはそれから
TSIGを抜き出し、ARCOUNTを調整し、サーバーと同じように要約を計算します。
もしTSIGが検証されないなら、応答コードが９（非認証）でない限り回答は
捨てられます(MUST)、応答コードが９の場合クライアントは[4.3]で指定され
るようにTSIGエラー回答として回答の検証を試みるべきです(SHOULD)。無署
名のTSIGレコードや証明に失敗するTSIGレコードを含むメッセージが受理で
きる回答と思われるべきではありません(SHOULD)；クライアントはエラーを
ログファイルに書き、問合せがタイムアウトするまで署名された反応を待ち
続けるべきです(SHOULD)。
4.6.1. Key error handling
4.6.1. 鍵エラー処理
If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
validates, and the TSIG key is different from the key used on the
request, then this is a KEY error. The client MAY retry the request
using the key specified by the server. This should never occur, as a
server MUST NOT sign a response with a different key than signed the
request.
もし回答の応答コードが９（非認証）でTSIGが検証できた回答でTSIGの鍵が
問合せで使われた鍵と異なっるなら、これは鍵エラーです。クライアントは
サーバーの指定した鍵を使って問合せを再び行ってもよいです(MAY)。これは
起きるべきでなくて、サーバーが問合せの鍵と異なる鍵で回答にに署名して
はなりません(MUST NOT)。
4.6.2. Time error handling
4.6.2. 時間エラー処理
If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18
(BADTIME), or the current time does not fall in the range specified
in the TSIG record, then this is a TIME error. This is an indication
that the client and server clocks are not synchronized. In this case
the client SHOULD log the event. DNS resolvers MUST NOT adjust any
clocks in the client based on BADTIME errors, but the server's time
in the other data field SHOULD be logged.
もし回答の応答コードが９（非認証）で、そしてTSIGエラーが１８（悪い時
間）か現在の時刻がTSIGレコードで指定された期間に入らないなら、これは
時間エラーです。これはクライアントとサーバーの時計の時間が合っていな
いという表示です。この場合クライアントはイベントをログファイルに書く
べきです(SHOULD)。ＤＮＳリゾルバが悪い時間エラーに基づいてクライアン
トの時計を調節してはなりません、しかし他のデータフィールドのサーバー
時刻をログファイルに書くべきです。
4.6.3. MAC error handling
4.6.3. メッセージ認証コードエラー処理
If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG),
this is a MAC error, and client MAY retry the request with a new
request ID but it would be better to try a different shared key if
one is available. Client SHOULD keep track of how many MAC errors
are associated with each key. Clients SHOULD log this event.
もし回答の応答コードが９（非認証）で、TSIGエラーが１６（悪い時間）な
ら、これはメッセージ認証コードエラーです、そしてクライアントが新しい
リクエストＩＤで問合せを再び送ってもよいです(MAY)、しかし他の共有鍵が
使えるならそれを試みることはもっと良いでしょう。クライアントが各鍵毎
にいくつのMACエラーがおきたか記録・追跡するべきです(SHOULD)。クライア
ントがこのイベントをログファイルに書くべきです(SHOULD)。
4.7. Special considerations for forwarding servers
4.7. 転送サーバーにおける特別な考察
A server acting as a forwarding server of a DNS message SHOULD check
for the existence of a TSIG record. If the name on the TSIG is not
of a secret that the server shares with the originator the server
MUST forward the message unchanged including the TSIG. If the name
of the TSIG is of a key this server shares with the originator, it
MUST process the TSIG. If the TSIG passes all checks, the forwarding
server MUST, if possible, include a TSIG of his own, to the
destination or the next forwarder. If no transaction security is
available to the destination and the response has the AD flag (see
[RFC2535]), the forwarder MUST unset the AD flag before adding the
TSIG to the answer.
ＤＮＳメッセージの転送サーバーの役を務めるサーバーがTSIGレコードの存
在を調べるべきです。もしTSIGの名前が送信者とサーバーが共有する秘密鍵
の名前でないなら、サーバーはTSIGを含めて変更のないメッセージを転送し
なくてはなりません(MUST)。もしTSIGの名前が送信者とサーバーが共有する
秘密鍵の名前なら、TSIGを処理しなくてはなりません(MUST)。もしTSIG検査
のすべてに合格するなら、転送サーバーは可能なら自分自身のTSIGを含めて
転送先に転送しなければなりません(MUST)。もし宛先に対する処理セキュリ
ティが使えななく、回答にＡＤフラグが設定されるなら（[RFC2535]参照）、
転送者は回答にTSIGを設定する前にＡＤフラグをクリアしなければなりませ
ん(MUST)。
5 - Shared Secrets
5 - 共有秘密鍵
5.1. Secret keys are very sensitive information and all available
steps should be taken to protect them on every host on which they are
stored. Generally such hosts need to be physically protected. If
they are multi-user machines, great care should be taken that
unprivileged users have no access to keying material. Resolvers
often run unprivileged, which means all users of a host would be able
to see whatever configuration data is used by the resolver.
5.1. 秘密鍵は非常に機密性が高い情報です、秘密鍵のおかれるホストでは全
ての段階で秘密鍵を守るようにすべきです。一般にこのようなホストは物理
的に保護さる必要があります。もしこれらがマルチユーザのマシンであるな
ら、非特権ユーザーが鍵にアクセスできないように注意されるべきです。リ
ゾルバがしばしば非特権で動作し、これはホストの全てのユーザーがリゾル
バの使う設定データを見ることが可能な事を意味します。
5.2. A name server usually runs privileged, which means its
configuration data need not be visible to all users of the host. For
this reason, a host that implements transaction-based authentication
should probably be configured with a "stub resolver" and a local
caching and forwarding name server. This presents a special problem
for [RFC2136] which otherwise depends on clients to communicate only
with a zone's authoritative name servers.
5.2. 名前サーバーが通常特権を与えら、設定データがホストのすべてのユー
ザーに見える必要がないことを意味します。この理由のために、処理認証を
実行するホストが恐らく「スタブ（切り株）リゾルバ」とローカルキャッシュ
と転送ネームサーバに設定されるべきです。これはゾーンの正式なネームサー
バーとだけ通信するクライアントに依存する[RFC2136]の特別な問題を発生し
ます。
5.3. Use of strong random shared secrets is essential to the security
of TSIG. See [RFC1750] for a discussion of this issue. The secret
should be at least as long as the keyed message digest, i.e. 16 bytes
for HMAC-MD5 or 20 bytes for HMAC-SHA1.
5.3. 強くランダムな共有秘密鍵の使用はTSIGセキュリティ欠かせません。こ
の問題の論議のためには[RFC1750]を見てください。秘密鍵は少なくとも、署
名されたメッセージ要約と同じぐらい長くあるべきです、つまり、HMAC-MD5
では16バイト、HMAC-SHA1では２０バイト以上です。
6 - Security Considerations
6 - セキュリティの考察
6.1. The approach specified here is computationally much less
expensive than the signatures specified in [RFC2535]. As long as the
shared secret key is not compromised, strong authentication is
provided for the last hop from a local name server to the user
resolver.
6.1. ここで指定された方法は計算量的に[RFC2535]で指定した署名よりコス
トがかかりません。共有秘密鍵や危うくない限り、強い認証がローカルネー
ムサーバとユーザーリゾルバ間の最終ホップで提供されます。
6.2. Secret keys should be changed periodically. If the client host
has been compromised, the server should suspend the use of all
secrets known to that client. If possible, secrets should be stored
in encrypted form. Secrets should never be transmitted in the clear
over any network. This document does not address the issue on how to
distribute secrets. Secrets should never be shared by more than two
entities.
6.2. 秘密鍵が周期的に変えられるべきです。もしクライアントホストが危う
くなったら、サーバーはそのクライアントの知ってるすべての秘密鍵の使用
をしばらく見合わせるべきです。もし可能なら、秘密鍵が暗号化された形で
保存されるべきです。秘密鍵が決してネットワーク上にそのまま伝達される
べきでありません。この文書は、どのように秘密鍵を配るべきかの問題を扱
いません。秘密鍵が決して３者以上で共有されるべきではありません。
6.3. This mechanism does not authenticate source data, only its
transmission between two parties who share some secret. The original
source data can come from a compromised zone master or can be
corrupted during transit from an authentic zone master to some
"caching forwarder." However, if the server is faithfully performing
the full [RFC2535] security checks, then only security checked data
will be available to the client.
6.3. この機構は情報源データの認証をせず、ある秘密鍵を共有する２者間の
送信だけを認証します。オリジナルの情報源データは危険なゾーンマスター
から来ることもあるし、あるいは正しいゾーンマスターから「キャッシュ転
送」に送られる際にいる若干数まで通過の間に改悪されるかもしれません。
しかし、もしサーバーが誠実に完全な[RFC2535]検査を行うなら、安全に管理
されたデータだけがクライアントに入手可能であるでしょう。
6.4. A fudge value that is too large may leave the server open to
replay attacks. A fudge value that is too small may cause failures
if machines are not time synchronized or there are unexpected network
delays. The recommended value in most situation is 300 seconds.
6.4. あまりにも大きい誤差値がサーバーに対する再生攻撃の弱点になるかも
しれません。あまりにも小さい誤差値では、もしマシンが時刻同期をしてい
ないなかったり予想外のネットワーク遅延により、誤りを生じるかもしれま
せん。たいていの状態での推薦された値は３００秒です。
7 - IANA Considerations
7 - IANAの考慮
IANA is expected to create and maintain a registry of algorithm names
to be used as "Algorithm Names" as defined in Section 2.3. The
initial value should be "HMAC-MD5.SIG-ALG.REG.INT". Algorithm names
are text strings encoded using the syntax of a domain name. There is
no structure required other than names for different algorithms must
be unique when compared as DNS names, i.e., comparison is case
insensitive. Note that the initial value mentioned above is not a
domain name, and therefore need not be a registered name within the
DNS. New algorithms are assigned using the IETF Consensus policy
defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT
looks like a FQDN for historical reasons; future algorithm names are
expected to be simple (i.e., single-component) names.
IANA は２.３章で定義されるように「アルゴリズム名」として用いられるア
ルゴリズム名の登記所を作り維持することを期待されます。最初の値は
"HMAC-MD5.SIG-ALG.REG.INT"であるべきです。アルゴリズム名がドメイン名
の構文論を使いテキスト文字列でコード化されています。ＤＮＳとして名前
を比較する際に異なるアルゴリズムの名前が区別できる以外何の構造も要求
しません、ＤＮＳの名前比較は大文字と小文字の違いを無視します。上記の
最初の値はドメイン名ではなく、ＤＮＳで登録された名前である必要があり
ません。新しいアルゴリズムがRFC 2434で定義されたＩＥＴＦ合意ポリシー
を使って割り当てられます。アルゴリズム名前HMAC-MD5.SIG-ALG.REG.INTは
歴史の理由のためにFQDN（訳注："fully qualified domain names"=「完全
に指定したドメイン名」の意味だと思う）のように見えます；未来のアルゴ
リズム名が簡単な名前（つまり要素が１つだけ）であることを期待します。
IANA is expected to create and maintain a registry of "TSIG Error
values" to be used for "Error" values as defined in section 2.3.
Initial values should be those defined in section 1.7. New TSIG
error codes for the TSIG error field are assigned using the IETF
Consensus policy defined in RFC 2434.
IANAは２.３章で定義されるように「エラー」値に使う「TSIGエラー値」の登
記所を作り維持することを期待されます。最初の値が１.７章で定義されるも
のであるべきです。TSIGエラーフィールドの新しいTSIG エラーコードがRFC
2434で定義されたＩＥＴＦ合意ポリシーを使って割り当てられます。
8 - References
8 - 参考文献
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1034, November 1987.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1995.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5:
Keyed-MD5 for Message Authentication", RFC 2104, February
1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic
Updates in the Domain Name System", RFC 2136, April 1997.
[RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic
Update", RFC 2137, April 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
9 - Authors' Addresses
9 - 著者のアドレス
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
Phone: +1 650 779 7001
EMail: vixie@isc.org
Olafur Gudmundsson
NAI Labs
3060 Washington Road, Route 97
Glenwood, MD 21738
Phone: +1 443 259 2389
EMail: ogud@tislabs.com
Donald E. Eastlake 3rd
Motorola
140 Forest Avenue
Hudson, MA 01749 USA
Phone: +1 508 261 5434
EMail: dee3@torque.pothole.com
Brian Wellington
Nominum, Inc.
950 Charter Street
Redwood City, CA 94063
Phone: +1 650 779 6022
EMail: Brian.Wellington@nominum.com
10 Full Copyright Statement
10 著作権表示全文
Copyright (C) The Internet Society (2000). 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.
RFCエディタ機能のための資金供給が現在インターネット学会によって供
給されます。