[要約] RFC 2845は、DNSの秘密鍵トランザクション認証（TSIG）に関する規格であり、DNSトランザクションの認証とデータの完全性を確保するために使用されます。目的は、DNSセキュリティの向上と、不正なデータの送信や改ざんを防ぐことです。
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)
DNSの秘密鍵トランザクション認証（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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（C）The Internet Society（2000）。全著作権所有。
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. ドメインネームシステム（DNS）[RFC1034、RFC1035]は、名前<=>アドレス変換やメール処理情報など、インターネット操作の基本的な情報を提供する複製された階層分散データベースシステムです。最近DNSが拡張されて[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]スキームの1つの問題は、一般的なDNS実装に、キャッシュを持たない単純な「スタブ」リゾルバーが含まれていることです。このようなリゾルバーは、通常、別のホスト上のキャッシングDNSサーバーに依存しています。これらのスタブリゾルバが一般的な[RFC2535]認証を実行することは非現実的であり、キャッシュDNSサーバーに依存してそのようなサービスを実行するのは当然です。これを安全に行うには、クエリと応答の安全な通信が必要です。 [RFC2535]はこれをサポートする公開鍵トランザクション署名を提供していますが、そのような署名は生成するのに非常にコストがかかります。一般に、これらには、スタブには非現実的な同じ複雑な公開鍵ロジックが必要です。このドキュメントでは、メッセージ認証コード（MAC）、具体的には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]公開鍵ベースのメカニズムの使用が非現実的である可能性がある2つ目の領域は、動的更新[RFC2136]リクエストの認証です。 [RFC2535]はリクエスト署名を提供しますが、[RFC2535]を使用すると、トランザクション署名と同様に、計算コストの高い公開鍵暗号と複雑な認証ロジックが必要になります。 Secure Domain Name System Dynamic Update（[RFC2137]）は、動的に更新されるゾーンでさまざまなキーがどのように使用されるかを説明しています。このドキュメントの秘密鍵ベースのMACは、DNS更新要求とトランザクション応答を認証するために使用でき、[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. このドキュメントで提案されている認証メカニズムは、共有秘密鍵を使用して、2つのエンティティ間の信頼関係を確立します。このような鍵は、秘密鍵と同様の方法で保護する必要があります。第三者が意図された当事者（偽造MAC）の1つになりすますことを防ぐためです。クライアントとローカルサーバー間で簡単で効率的な認証を提供することが急務であり、この提案はそのニーズに対応しています。この提案は、他の多くのサーバーと通信するサーバーの一般的なサーバー間認証には適していません。これは、キーの管理が二次的に増加する共有キーの数によって扱いにくくなるためです。ただし、少数の再帰サーバーとのみ通信するホスト上の多くのリゾルバーに適しています。
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. 間接キャッシングリゾルバーとして機能するサーバー（一般的な使用法では「フォワーダー」）は、少数の事前設定された「上流」サーバーと通信するときに、トランザクションベースの認証を使用する場合があります。 DNS秘密鍵認証の他の使用法と自動秘密鍵配布のための可能なシステムは、別の将来の文書で提案されるかもしれません。
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)
RRTYPE = TSIG（250）エラー= 0..15（DNS RCODE）エラー= 16（BADSIG）エラー= 17（BADKEY）エラー= 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 RR形式
2.1 TSIG RR Type
2.1 TSIG RRタイプ
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であり、タイプコードが250である新しいRRタイプを使用します。TSIGはメタRRであり、キャッシュしてはなりません（MUST）。 TSIG RRは、共有秘密鍵を確立したDNSエンティティ間の認証に使用されます。 TSIG RRは、特定のDNSトランザクションをカバーするように動的に計算され、通常の意味ではDNS RRではありません。
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 RRは1つのDNS要求/応答に関連しているため、それらを格納または再送信しても意味がありません。したがって、DNSメッセージの認証に使用されたTSIG RRは破棄されます。このドキュメントで指定されている唯一のメッセージダイジェストアルゴリズムは「HMAC-MD5」です（[RFC1321]、[RFC2104]を参照）。 「HMAC-MD5」アルゴリズムは、相互運用性を実現するために必須です。他のアルゴリズムは後日指定できます。新しいアルゴリズムの名前と定義は、IANAに登録する必要があります。 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.
NAMEドメイン名構文で使用されるキーの名前。名前はホストの名前を反映し、これらの2つのホストがいつでも共有できるキーのセットの中でキーを一意に識別する必要があります。ホスト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.
この名前は、関連するキーへのローカルインデックスとして使用でき、グローバルに一意にすることをお勧めします。キーが2つのホスト間で共有されるだけの場合、その名前は実際にはホストにとって意味があれば十分ですが、キー名はニーモニックであり、リゾルバーとサーバーのホスト名をこの順序で組み込むことをお勧めします。
TYPE TSIG (250: Transaction SIGnature)
タイプTSIG（250：トランザクションSIGnature）
CLASS ANY
クラスANY
TTL 0
TTL 0
RdLen (variable)
RdLen（変数）
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.
Fudge u_int16_t seconds of error permitted
in Time Signed.
MAC Size u_int16_t number of octets in MAC.
MAC octet stream defined by Algorithm Name.
Original ID u_int16_t original message ID
Error u_int16_t expanded RCODE covering
TSIG processing.
Other Len u_int16_t length, in octets, of
Other Data.
Other Data octet stream empty unless Error == BADTIME
2.4. Example
2.4. 例
NAME HOST.EXAMPLE.
名前HOST.EXAMPLE。
TYPE TSIG
タイプTSIG
CLASS ANY
クラスANY
TTL 0
TTL 0
RdLen as appropriate
必要に応じてRdLen
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を含めることができるように応答を変更する必要があります。この応答は、質問とTSIGレコードのみで構成され、TCビットが設定され、RCODE 0（NOERROR）が含まれています。この時点で、クライアントはTCPを使用して要求を再試行する必要があります（[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レコードが含まれている場合、それは追加セクションの最後のレコードでなければなりません。複数のTSIGレコードは許可されていません。 TSIGレコードが他の位置に存在する場合、パケットはドロップされ、RCODE 1（FORMERR）の応答が返されなければなりません（MUST）。 TSIG RRが正しく配置されたメッセージを受信すると、TSIG RRは安全な場所にコピーされ、DNSメッセージから削除され、DNSメッセージヘッダーのARCOUNTからデクリメントされます。この時点で、キー付きメッセージダイジェスト操作が実行されます。アルゴリズム名またはキー名が受信者にとって不明な場合、またはメッセージダイジェストが一致しない場合、DNSメッセージ全体を破棄する必要があります。メッセージがクエリの場合、RCODE 9（NOTAUTH）を含む応答は、TSIG ERROR 17（BADKEY）またはTSIG ERROR 16（BADSIG）を使用して発信者に送り返されなければなりません（MUST）。このメッセージに署名するために使用できる鍵がない場合は、署名なしで送信する必要があります（MACサイズ== 0および空のMAC）。システム運用ログへのメッセージを生成して、進行中のセキュリティインシデントの可能性を運用スタッフに警告する必要があります。このタイプのイベントのロギングによってシステムがサービス拒否攻撃を受けないように注意する必要があります。
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ヘッダーに2つのタイマー値が含まれています。これを行わなかった場合、攻撃者は古いメッセージを再生できますが、「Time Signed」および「Fudge」フィールドを更新して、メッセージを新しく見せることができます。このデータは「TSIGタイマー」と呼ばれ、ダイジェスト計算の目的で、「オンザワイヤー」形式で、最初に時間署名され、次にファッジの順に呼び出されます。例えば：
Field Name Value Wire Format Meaning
----------------------------------------------------------------------
Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997
Fudge 300 01 2C 5 minutes
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. DNSメッセージ
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.
TSIG RRが追加データセクションに追加される前、およびDNSメッセージヘッダーのARCOUNTフィールドがTSIG RRを含むようにインクリメントされる前の、ワイヤー形式の完全で完全なDNSメッセージ。メッセージIDが元のメッセージIDと異なる場合、元のメッセージIDがメッセージIDに置き換えられます。これは、たとえば、動的更新要求を転送するときに発生する可能性があります。
3.4.2. TSIG Variables
3.4.2. TSIG変数
Source Field Name Notes
-----------------------------------------------------------------------
TSIG RR NAME Key name, in canonical wire format
TSIG RR CLASS (Always ANY in the current specification)
TSIG RR TTL (Always 0 in the current specification)
TSIG RDATA Algorithm Name in canonical wire format
TSIG RDATA Time Signed in network byte order
TSIG RDATA Fudge in network byte order
TSIG RDATA Error in network byte order
TSIG RDATA Other Len in network byte order
TSIG RDATA Other Data exactly as transmitted
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.
RR RDLENおよびRDATA MAC長は、MACが生成される前に認識できることが保証されていないため、ハッシュに含まれていません。
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.
元のIDフィールドは、DNSヘッダーのメッセージIDの代わりに既に使用され、ハッシュされているため、このセクションには含まれていません。
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.
ラベルタイプごとに、明確な方法でラベルを表現する方法を指定する定義された「正規ワイヤフォーマット」が必要です。ラベルタイプ00の場合、これは[RFC2535]で定義され、ラベルタイプ01の場合、これは[RFC2673]で定義されます。 00と01以外のラベルタイプの使用は、この仕様では定義されていません。
3.4.3. Request MAC
3.4.3. MACをリクエスト
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 Data octet stream exactly as transmitted
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レコードを追加のデータセクションに追加して、リクエストをサーバーに送信します。クライアントは、応答を待つ間、要求からのメッセージダイジェストを保存する必要があります。リクエストのダイジェストコンポーネントは次のとおりです。
DNS Message (request) TSIG Variables (request)
DNSメッセージ（リクエスト）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をサポートし、クライアントと秘密鍵を共有していることがわかっているサーバーでのみ、署名されたトランザクションを試行する必要があります。したがって、これは実際には問題ありません。
4.2. TSIG on Answers
4.2. TSIG on Answers
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)
MAC DNSメッセージの要求（応答）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サイズ== 0および空のMAC）を送信する必要があります（SHOULD）。 TSIGの有効期間に関連するエラーが検出された場合、サーバーは署名されたエラーメッセージを返信する必要があります（SHOULD）。ダイジェストコンポーネントは次のとおりです。
Request MAC (if the request MAC validated) DNS Message (response) TSIG Variables (response)
リクエストMAC（リクエストMACが検証された場合）DNSメッセージ（応答）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]で指定されているように応答を生成する必要があります。
4.4. TSIG on TCP connection
4.4. TCP接続の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:
DNS TCPセッションには、複数のDNSエンベロープを含めることができます。これは、たとえば、ゾーン転送で一般的に使用されます。そのような接続でTSIGを使用すると、接続をハイジャックから保護し、データの整合性を提供できます。 TSIGは最初と最後のDNSエンベロープに含める必要があります。オプションで、任意の中間エンベロープに配置できます。すべての封筒に含めるにはコストがかかりますが、少なくとも100ごとに封筒に配置する必要があります。最初のエンベロープは標準回答として処理され、後続のメッセージには次のダイジェストコンポーネントがあります。
Prior Digest (running) DNS Messages (any unsigned messages since the last TSIG) TSIG Timers (current message)
以前のダイジェスト（実行中）DNSメッセージ（最後のTSIG以降の署名されていないメッセージ）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検証が失敗した場合、クライアントは接続を閉じる必要があります。クライアントがTSIGレコードを十分に頻繁に受信しない場合（上記で指定）、接続がハイジャックされたと想定して（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 RRがあるかどうかを確認します。存在する場合、サーバーは応答でTSIG RRを返す必要があります。サーバーは次のチェックを次の順序で実行しなければならず、KEYをチェックし、TIME値をチェックし、MACをチェックします。
4.5.1. KEY check and error handling
4.5.1. KEYチェックとエラー処理
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.
非転送サーバーがクライアントが使用するキーを認識しない場合、サーバーはRCODE 9（NOTAUTH）およびTSIG ERROR 17（BADKEY）を含むエラー応答を生成する必要があります。この応答は、[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.
サーバーの時間がリクエストで指定された時間間隔（つまり、Time Signed、plus / minus Fudge）の外にある場合、サーバーはRCODE 9（NOTAUTH）およびTSIG ERROR 18（BADTIME）でエラー応答を生成する必要があります。サーバーは、キーによって生成されたメッセージの最新の時間署名付き値もキャッシュする必要があり（SHOULD）、後で受信したメッセージに以前の時間署名付き値がある場合はBADTIMEを返す必要があります（SHOULD）。 BADTIMEエラーを示す応答は、要求と同じキーで署名する必要があります。時刻署名フィールドにはクライアントの現在時刻、その他のデータフィールドにはサーバーの現在時刻（u_int48_t）、その他のデータ長フィールドには6を含める必要があります。これは、クライアントが別のBADTIMEエラーが原因で検証が失敗することなく、BADTIMEエラーのあるメッセージを検証できるようにするためです。署名されたデータは[4.3]で指定されています。サーバーはエラーをログに記録する必要があります（SHOULD）。
4.5.3. MAC check and error handling
4.5.3. MACチェックとエラー処理
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が検証に失敗した場合、サーバーは、RCODE 9（NOTAUTH）およびTSIG ERROR 16（BADSIG）を使用して、[4.3]で指定されているエラー応答を生成する必要があります。この応答は、[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 RRが応答に存在するかどうかを確認します。それ以外の場合、応答はフォーマットエラーがあるものとして扱われ、破棄されます。次に、クライアントはTSIGを抽出し、ARCOUNTを調整して、サーバーと同じ方法でキー付きダイジェストを計算します。 TSIGが検証しない場合、RCODEが9（NOTAUTH）でない限り、その応答を破棄する必要があります。その場合、クライアントは、[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.
応答のRCODEが9（NOTAUTH）で、応答TSIGが検証され、TSIGキーが要求で使用されているキーと異なる場合、これはKEYエラーです。クライアントは、サーバーによって指定されたキーを使用してリクエストを再試行してもよい（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.
応答RCODEが9（NOTAUTH）で、TSIG ERRORが18（BADTIME）である場合、または現在の時刻がTSIGレコードで指定された範囲内にない場合、これはTIMEエラーです。これは、クライアントとサーバーのクロックが同期していないことを示しています。この場合、クライアントはイベントをログに記録する必要があります（SHOULD）。 DNSリゾルバーは、BADTIMEエラーに基づいてクライアントのクロックを調整してはなりません（MUST NOT）が、他のデータフィールドのサーバーの時刻はログに記録する必要があります（SHOULD）。
4.6.3. MAC error handling
4.6.3. MACエラー処理
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.
応答RCODEが9（NOTAUTH）でTSIG ERRORが16（BADSIG）の場合、これはMACエラーであり、クライアントは新しいリクエストIDを使用してリクエストを再試行できますが、利用可能な場合は別の共有キーを試すことをお勧めします。クライアントは、各キーに関連付けられている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.
DNSメッセージの転送サーバーとして機能するサーバーは、TSIGレコードの存在を確認する必要があります。 TSIGの名前がサーバーが発信者と共有する秘密のものではない場合、サーバーはTSIGを含めてメッセージを変更せずに転送する必要があります。 TSIGの名前がこのサーバーが発信者と共有するキーのものである場合、TSIGを処理する必要があります。 TSIGがすべてのチェックに合格した場合、転送サーバーは、可能であれば、宛先または次のフォワーダーに独自のTSIGを含める必要があります。宛先で利用できるトランザクションセキュリティがなく、応答にADフラグ（[RFC2535]を参照）がある場合、フォワーダーはTSIGを回答に追加する前にADフラグの設定を解除する必要があります。
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の場合は20バイトです。
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. 秘密鍵は定期的に変更する必要があります。クライアントホストが危険にさらされている場合、サーバーはそのクライアントに既知のすべてのシークレットの使用を一時停止する必要があります。可能な場合、シークレットは暗号化された形式で保存する必要があります。シークレットは、ネットワークを介して平文で送信してはなりません。このドキュメントでは、シークレットの配布方法に関する問題は扱いません。秘密は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. このメカニズムはソースデータを認証せず、何らかの秘密を共有する2つのパーティ間の送信のみを認証します。元のソースデータは、侵害されたゾーンマスターからのものである場合や、正規のゾーンマスターから「キャッシングフォワーダー」への転送中に破損する場合があります。ただし、サーバーが完全な[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. ファッジ値が大きすぎると、サーバーが攻撃をリプレイできるようになります。ファッジ値が小さすぎると、マシンが時間同期されていない場合、または予期しないネットワーク遅延が発生した場合に障害が発生する可能性があります。ほとんどの場合の推奨値は300秒です。
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は、セクション2.3で定義されている「アルゴリズム名」として使用されるアルゴリズム名のレジストリを作成および維持することが期待されています。初期値は「HMAC-MD5.SIG-ALG.REG.INT」です。アルゴリズム名は、ドメイン名の構文を使用してエンコードされたテキスト文字列です。 DNS名として比較する場合、異なるアルゴリズムの名前が一意でなければならないことを除いて、必要な構造はありません。つまり、比較では大文字と小文字が区別されません。上記の初期値はドメイン名ではないため、DNS内の登録名である必要はありません。新しいアルゴリズムは、RFC 2434で定義されているIETFコンセンサスポリシーを使用して割り当てられます。アルゴリズム名HMAC-MD5.SIG-ALG.REG.INTは、歴史的な理由からFQDNのように見えます。将来のアルゴリズム名は、単純な（つまり、単一コンポーネントの）名前であると予想されます。
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は、セクション2.3で定義されている「エラー」値に使用される「TSIGエラー値」のレジストリを作成および維持することが期待されています。初期値はセクション1.7で定義されたものでなければなりません。 TSIGエラーフィールドの新しいTSIGエラーコードは、RFC 2434で定義されているIETFコンセンサスポリシーを使用して割り当てられます。
8 - References
8-リファレンス
[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 Specification", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1034、1987年11月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1995.
[RFC1750] Eastlake、D.、Crocker、S。およびJ. Schiller、「Randomness Recommendations for Security」、RFC 1750、1995年12月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5: Keyed-MD5 for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC-MD5：Keyed-MD5 for Message Authentication」、RFC 2104、1997年2月。
[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月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic Updates in the Domain Name System", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound「ドメインネームシステムの動的更新」、RFC 2136、1997年4月。
[RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[RFC2137] Eastlake 3rd、D。、「Secure Domain Name System Dynamic Update」、RFC 2137、1997年4月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、D。、「ドメインネームシステムのセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC2673]クロフォード、M。、「ドメインネームシステムのバイナリラベル」、RFC 2673、1999年8月。
9 - Authors' Addresses
9-著者のアドレス
Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063
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
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
ドナルドE.イーストレイク第3モトローラ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
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.
Copyright（C）The Internet Society（2000）。全著作権所有。
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 Editor機能への資金提供は、現在Internet Societyから提供されています。