この文書はRFC3007の日本語訳です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                      B. Wellington
Request for Comments: 3007                                       Nominum
Updates: 2535, 2136                                        November 2000
Obsoletes: 2137
Category: Standards Track


             Secure Domain Name System (DNS) Dynamic Update
         安全なドメインネームシステム(DNS)ダイナミック更新

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.

Abstract
概要

   This document proposes a method for performing secure Domain Name
   System (DNS) dynamic updates.  The method described here is intended
   to be flexible and useful while requiring as few changes to the
   protocol as possible.  The authentication of the dynamic update
   message is separate from later DNSSEC validation of the data.  Secure
   communication based on authenticated requests and transactions is
   used to provide authorization.
   この文書は安全なドメインネームシステム(DNS)ダイナミック更新の方
   法を提案します。ここで記述された方法は最小限のプロトコル変更で、柔軟
   かつ有用になるように意図されます。ダイナミック更新メッセージの認証は、
   その後のデータのDNSSEC検証とは独立しています。要求と処理の認証
   による安全な通信が認証を行うために使われます。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
   この文書におけるキーワード "MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と
   "SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"
   は、RFC 2119に記述されるように解釈されるはずです。

1 - Introduction
1 - はじめに

   This document defines a means to secure dynamic updates of the Domain
   Name System (DNS), allowing only authorized sources to make changes
   to a zone's contents.  The existing unsecured dynamic update
   operations form the basis for this work.
   この文書は認定された情報源のみにゾーンの中身の更新を許すドメインネー
   ムシステム(DNS)のダイナミックな更新手段を定義します。既存の保証
   がないダイナミックな更新処理はこの仕事の基礎になります。

   Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
   [RFC2136] is helpful and is assumed by this document.  In addition,
   knowledge of DNS security extensions [RFC2535], SIG(0) transaction
   security [RFC2535, RFC2931], and TSIG transaction security [RFC2845]
   is recommended.
   DNSシステム[RFC1034, RFC1035]とダイナミック更新[RFC2136]に精通する
   事は助けになり、この文書の仮定です。さらにDNSセキュリティ拡張
   [RFC2535]とSIG(0)処理セキュリティ[RFC2535, RFC2931]とTSIG処理セ
   キュリティ[RFC2845]の知識が推薦されます。

   This document updates portions of RFC 2535, in particular section
   3.1.2, and RFC 2136.  This document obsoletes RFC 2137, an alternate
   proposal for secure dynamic update, due to implementation experience.
   この文書はRFC 2535の特に3.1.2章と、RFC 2136を更新します。この文書
   はRFC 2137を時代遅れにし、実装経験のため代わりの提案をします。

1.1 - Overview of DNS Dynamic Update
1.1 - DNSダイナミックな更新の概要

   DNS dynamic update defines a new DNS opcode and a new interpretation
   of the DNS message if that opcode is used.  An update can specify
   insertions or deletions of data, along with prerequisites necessary
   for the updates to occur.  All tests and changes for a DNS update
   request are restricted to a single zone, and are performed at the
   primary server for the zone.  The primary server for a dynamic zone
   must increment the zone SOA serial number when an update occurs or
   before the next retrieval of the SOA.
   DNSダイナミックな更新が新しいオペコードと、そのオペコードを使う場
   合のDNSメッセージの新しい解釈を定義します。更新は、更新をするのに
   必要な条件と、追加か削除するデータを指定できます。DNS更新のすべて
   のテストと変更の要求はひとつのゾーンに制限され、ゾーンのプライマリサー
   バーで行われます。ダイナミックゾーンのプライマリサーバーは更新をする
   時は次のSOAの検索の前にゾーンのSOAシリアル番号を増加させなくてはなり
   ません。

1.2 - Overview of DNS Transaction Security
1.2 - DNS処理セキュリティの概要

   Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0)
   [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS
   requests and responses sent between them.  A TSIG MAC (message
   authentication code) is derived from a shared secret, and a SIG(0) is
   generated from a private key whose public counterpart is stored in
   DNS.  In both cases, a record containing the message signature/MAC is
   included as the final resource record in a DNS message.  Keyed
   hashes, used in TSIG, are inexpensive to calculate and verify.
   Public key encryption, as used in SIG(0), is more scalable as the
   public keys are stored in DNS.
   TSIG[RFC2845]やSIG(0)[RFC2535, RFC2931]レコードを含むDNSメッセージ
   の交換は2つのDNSがが記録する DNS メッセージの交換が2つのDNS処
   理者間で交換するDNS問合せと解答の認証を可能にします。TSIG MAC(メッ
   セージ認証コード)が共有する秘密から得られます、そしてSIG(0)はプライ
   ベートキーから生成され対応する公開部はDNSに登録されます。両方の場
   合、メッセージ署名/MACを含むレコードが最後の資源レコードとしてDNS
   メッセージに含められます。TSIGで使う鍵付きハッシュは、計算と検証が簡
   単です。SIG(0)で使われるように、公開鍵暗号は公開鍵がDNSに登録され
   る時よりスケーラブルです。

1.3 - Comparison of data authentication and message authentication
1.3 - データ認証とメッセージ認証の比較

   Message based authentication, using TSIG or SIG(0), provides
   protection for the entire message with a single signing and single
   verification which, in the case of TSIG, is a relatively inexpensive
   MAC creation and check.  For update requests, this signature can
   establish, based on policy or key negotiation, the authority to make
   the request.
   TSIGかSIG(0)を使ったメッセージ毎の認証は、1つの署名と1つの検証でメッ
   セージ全体を保護します、TSIGの場合検証は簡単なMACから生成する検査です。
   更新要求で、ポリシーや鍵交渉でこの署名が行われ、要求を認証します。

   DNSSEC SIG records can be used to protect the integrity of individual
   RRs or RRsets in a DNS message with the authority of the zone owner.
   However, this cannot sufficiently protect the dynamic update request.
   DNSSEC署名レコードがゾーン所有者の署名でDNSメッセージの個々
   の資源レコードや資源レコード集合の完全性を守るのに使うことができます。
   しかしこれは十分にダイナミックな更新要求を守ることができません。

   Using SIG records to secure RRsets in an update request is
   incompatible with the design of update, as described below, and would
   in any case require multiple expensive public key signatures and
   verifications.
   安全な資源レコード集合の更新要求で署名を使うのは、更新のデザイン上、
   不適当で、どのような場合でも複数の高価な公開鍵署名と検証を必要とする
   でしょう。

   SIG records do not cover the message header, which includes record
   counts.  Therefore, it is possible to maliciously insert or remove
   RRsets in an update request without causing a verification failure.
   署名レコードが、レコードの数が書いてある、メッセージヘッダーをカバー
   しません。そのため、検証の失敗なしに更新要求に悪意をもって資源レコー
   ド集合を追加したり削除したりすることは可能です。

   If SIG records were used to protect the prerequisite section, it
   would be impossible to determine whether the SIGs themselves were a
   prerequisite or simply used for validation.
   もし署名レコードが条件セクションを守るために使われたなら、署名自身が
   条件なのか検証のためなのか決定することは不可能でしょう。

   In the update section of an update request, signing requests to add
   an RRset is straightforward, and this signature could be permanently
   used to protect the data, as specified in [RFC2535].  However, if an
   RRset is deleted, there is no data for a SIG to cover.
   更新要求の更新セクションで資源レコード集合に署名要求をを加えるのは簡
   単で、この署名は[RFC2535]で指定されるように、データを永久に保護する
   のに使うことができます。しかしもし資源レコード集合が削除されたら署名
   がカバーするべきデータがなくなります。

1.4 - Data and message signatures
1.4 - データとメッセージの署名

   As specified in [RFC3008], the DNSSEC validation process performed by
   a resolver MUST NOT process any non-zone keys unless local policy
   dictates otherwise.  When performing secure dynamic update, all zone
   data modified in a signed zone MUST be signed by a relevant zone key.
   This completely disassociates authentication of an update request
   from authentication of the data itself.
   [RFC3008]で指定されるように、リゾルバの行うDNSSEC検証処理は、
   ローカルポリシーで決められてなければ、非ゾーン鍵を処理してはなりませ
   ん(MUST NOT)。安全なダイナミック更新を行う時、署名された全てのゾーン
   データは関連するゾーン鍵で署名されなくてはなりません(MUST)。これは
   データ自身の検証と、更新要求の検証を切り離します。

   The primary usefulness of host and user keys, with respect to DNSSEC,
   is to authenticate messages, including dynamic updates.  Thus, host
   and user keys MAY be used to generate SIG(0) records to authenticate
   updates and MAY be used in the TKEY [RFC2930] process to generate
   TSIG shared secrets.  In both cases, no SIG records generated by
   non-zone keys will be used in a DNSSEC validation process unless
   local policy dictates.
   DNSSECに関するホストとユーザーの鍵が有効であれば、ダイナミック
   更新メッセージを含めて、メッセージを本物と証明するはずです。それで、
   ホストとユーザの鍵は更新の認証のためSIG(0)レコードを生成し(MAY)、
   TKEY[RFC2930]処理がTSIG共有秘密鍵生成に使われるかもしれません(MAY)。
   両方の場合、非ゾーン鍵によって生成された署名レコードが、ローカルポリ
   シーで規定されなければ、DNSSEC検証処理で使われないでしょう。

   Authentication of data, once it is present in DNS, only involves
   DNSSEC zone keys and signatures generated by them.
   データ認証がDNSに存在している場合、ただDNSSECゾーン鍵を伴う
   だけで、ゾーン鍵で署名が生成されます。

1.5 - Signatory strength
1.5 - 署名強度

   [RFC2535, section 3.1.2] defines the signatory field of a key as the
   final 4 bits of the flags field, but does not define its value.  This
   proposal leaves this field undefined.  Updating [RFC2535], this field
   SHOULD be set to 0 in KEY records, and MUST be ignored.
   [RFC2535, section 3.1.2]が、フラグフィールドの最後の4ビットを鍵の署
   名者フィールドと定義しますが、値を定義しません。この提案はこのフィー
   ルドを不確定なままにしておきます。[RFC2535]を更新し、このフィールドは
   鍵レコードで0を設定するべきで(SHOULD)、無視されなくてはなりません(MUST)。

2 - Authentication
2 - 認証

   TSIG or SIG(0) records MUST be included in all secure dynamic update
   messages.  This allows the server to verifiably determine the
   originator of a message.  If the message contains authentication in
   the form of a SIG(0), the identity of the sender (that is, the
   principal) is the owner of the KEY RR that generated the SIG(0).  If
   the message contains a TSIG generated by a statically configured
   shared secret, the principal is the same as or derived from the
   shared secret name.  If the message contains a TSIG generated by a
   dynamically configured shared secret, the principal is the same as
   the one that authenticated the TKEY process; if the TKEY process was
   unauthenticated, no information is known about the principal, and the
   associated TSIG shared secret MUST NOT be used for secure dynamic
   update.
   TSIGかSIG(0)レコードをすべての安全なダイナミック更新メッセージに含め
   なければなりません(MUST)。これはサーバーにメッセージ生成者の検証を可
   能にします。もしメッセージがSIG(0)形式の認証を含むなら、送り主(すな
   わち本人)はSIG(0)を作った鍵資源レコードの所有者です。もしメッセージ
   が静的に設定された共有秘密鍵で生成したTSIGを含むなら、本人は共有秘密
   鍵を持つ者です。もしメッセージが動的に配置された共有秘密鍵によって生
   成されたTSIGを含むなら、本人はTKEY処理を認証した者です;もしTKEY処理
   が本物と証明されなかったなら、本人の情報がわからず、関連した共有秘密
   鍵は安全なダイナミック更新で使ってはなりません(MUST NOT)。

   SIG(0) signatures SHOULD NOT be generated by zone keys, since
   transactions are initiated by a host or user, not a zone.
   処理はホストかユーザが生み出すもので、ゾーンが生み出すものでないので、
   SIG(0)署名はゾーン鍵から生成すべきではありません(SHOULD NOT)SIG(0)。

   DNSSEC SIG records (other than SIG(0)) MAY be included in an update
   message, but MUST NOT be used to authenticate the update request.
   (SIG(0)以外の)DNSSEC署名レコードが更新メッセージに含められるかもし
   れません、しかし更新の要求の認証に使ってはなりません。

   If an update fails because it is signed with an unauthorized key, the
   server MUST indicate failure by returning a message with RCODE
   REFUSED.  Other TSIG, SIG(0), or dynamic update errors are returned
   as specified in the appropriate protocol description.
   もし認証されていない鍵の署名により更新が失敗するなら、サーバーは拒否
   応答コードでメッセージを返すことにより失敗を示さなくてはなりません
   (MUST)。他のTSIGとSIG(0)とダイナミック更新エラーは適切なプロトコル記
   述で指定したものを返します。

3 - Policy
3 - ポリシー

   All policy is configured by the zone administrator and enforced by
   the zone's primary name server.  Policy dictates the authorized
   actions that an authenticated principal can take.  Policy checks are
   based on the principal and the desired action, where the principal is
   derived from the message signing key and applied to dynamic update
   messages signed with that key.
   すべてのポリシーがゾーン管理者によって設定されて、ゾーンのプライマリ
   ネームサーバーによって実施されます。ポリシーが認証された者がとれる公
   認の行動を規定します。ポリシーチェックは認証された者毎に望ましい行動
   を示します、認証された者はメッセージに署名した鍵から得られて、その鍵
   で署名されたダイナミック更新メッセージに適用されます。

   The server's policy defines criteria which determine if the key used
   to sign the update is permitted to perform the requested updates.  By
   default, a principal MUST NOT be permitted to make any changes to
   zone data; any permissions MUST be enabled though configuration.
   サーバーポリシーは更新に署名した鍵がその更新をするのを認めるか決定す
   る基準を定義します。デフォルトで、認証された者はゾーンデータに対する
   変更をするのを許されません(MUST NOT);どのような変更許可も設定して初
   めて可能になります(MUST)。

   The policy is fully implemented in the primary zone server's
   configuration for several reasons.  This removes limitations imposed
   by encoding policy into a fixed number of bits (such as the KEY RR's
   signatory field).  Policy is only relevant in the server applying it,
   so there is no reason to expose it.  Finally, a change in policy or a
   new type of policy should not affect the DNS protocol or data format,
   and should not cause interoperability failures.
   ポリシーはいくつかの理由のために完全プライマリゾーンサーバーに実装さ
   れます。これによりポリシーが(鍵資源レコードの署名者フィールドのよう
   な)固定ビット数内といった限界を課されません。ポリシーはそれを運用す
   るサーバーにだけ関係があり、それをさらす理由がありません。最後に、ポ
   リシー変更や新しいタイプのポリシーがDNSプロトコルやデータフォーマッ
   トに影響を与えるべきでなくて、互換性誤りを起こすべきではありません。

3.1 - Standard policies
3.1 - 標準ポリシー

   Implementations SHOULD allow access control policies to use the
   principal as an authorization token, and MAY also allow policies to
   grant permission to a signed message regardless of principal.
   実装プログラムは、更新者毎のアクセス制御ポリシーを許すべきであり
   (SHOULD)、更新者にかかわらず署名されたメッセージに修正を許可するポリ
   シーを許してもよいです。

   A common practice would be to restrict the permissions of a principal
   by domain name.  That is, a principal could be permitted to add,
   delete, or modify entries corresponding to one or more domain names.
   普通はドメイン名毎に修正者の権限を限定するしょう。つまり修正者はある
   ドメイン名の項目の追加・修正・削除をを許されるでしょう。

   Implementations SHOULD allow per-name access control, and SHOULD
   provide a concise representation of the principal's own name, its
   subdomains, and all names in the zone.
   実装プログラムがドメイン名毎のアクセス制御を許すべきで(SHOULD)、ゾー
   ンの修正者自身の名前とそのサブドメインとすべての名前の簡潔な表現を提
   供するべきです(SHOULD)。

   Additionally, a server SHOULD allow restricting updates by RR type,
   so that a principal could add, delete, or modify specific record
   types at certain names.  Implementations SHOULD allow per-type access
   control, and SHOULD provide concise representations of all types and
   all "user" types, where a user type is defined as one that does not
   affect the operation of DNS itself.
   さらに、サーバーが資源レコードタイプ毎に更新を限定することを許すべき
   で(SHOULD)、修正者がある名前のあるレコードタイプを追加・変更・削除で
   きるでしょう。実装プログラムがタイプ毎のアクセス制御を許すべきで
   (SHOULD)、すべてのタイプとすべての「ユーザー」タイプの簡潔な表現を供
   給すべきです、ここでユーザータイプとはDNSオペレーション自身に影響
   を与えないものの事です。

3.1.1 - User types
3.1.1 - ユーザタイプ

   User types include all data types except SOA, NS, SIG, and NXT.  SOA
   and NS records SHOULD NOT be modified by normal users, since these
   types create or modify delegation points.  The addition of SIG
   records can lead to attacks resulting in additional workload for
   resolvers, and the deletion of SIG records could lead to extra work
   for the server if the zone SIG was deleted.  Note that these records
   are not forbidden, but not recommended for normal users.
   ユーザータイプがSOAレコードとネームサーバレコードと署名レコードとNXT
   レコード以外のすべてのデータタイプを含みます。SOAレコードとネームサー
   バレコードは、これらが委任ポイントを作ったり修正したりするので、標準
   ユーザーが修正できるべきではありません(SHOULD NOT)。署名レコードの追
   加はリゾルバの追加作業負荷をもたらす攻撃を導き、署名レコードの削除は
   ゾーン署名が削除された時にサーバーに余分な仕事を発生させます。これら
   のレコードの修正が禁じられているのではなく標準ユーザに勧められないと
   いうことに注意してください。

   NXT records MUST NOT be created, modified, or deleted by dynamic
   update, as their update may cause instability in the protocol.  This
   is an update to RFC 2136.
   NXTレコードは、ダイナミック更新プロトコルの不安定性を発生するかもしれ
   ないので、生成・修正・削除してはなりません(MUST NOT)。これはRFC 2136
   の修正です。

   Issues concerning updates of KEY records are discussed in the
   Security Considerations section.
   鍵レコードの更新に関しての問題がセキュリティ考察の章で論じられます。

3.2 - Additional policies
3.2 - 追加ポリシー

   Users are free to implement any policies.  Policies may be as
   specific or general as desired, and as complex as desired.  They may
   depend on the principal or any other characteristics of the signed
   message.
   ユーザーはどんなポリシーの実装も自由です。ポリシーは希望すればいくら
   特殊でもいくら複雑でもかまいません。それらは修正者に依存しても、署名
   されたメッセージの他の特徴に依存してもよいです。

4 - Interaction with DNSSEC
4 - DNSSECとの相互作用

   Although this protocol does not change the way updates to secure
   zones are processed, there are a number of issues that should be
   clarified.
   このプロトコルは安全なゾーンの更新処理を変えないが、明確にすべき多く
   の問題があります。

4.1 - Adding SIGs
4.1 - 署名の追加

   An authorized update request MAY include SIG records with each RRset.
   Since SIG records (except SIG(0) records) MUST NOT be used for
   authentication of the update message, they are not required.
   承認された更新要求の各資源レコード集合に対して署名資源レコードが含ま
   れるかもしれません(MAY)。(SIG(0)レコードを除く)SIGレコードが更新メッ
   セージの認証に使われてはならないので(MUST NOT)、それらは必要でありま
   せん。

   If a principal is authorized to update SIG records and there are SIG
   records in the update, the SIG records are added without
   verification.  The server MAY examine SIG records and drop SIGs with
   a temporal validity period in the past.
   もし修正者に署名レコードを更新する権限を与えられ、更新メッセージに署
   名レコードがあるなら、署名レコードは検証なしで追加されます。サーバー
   は署名レコードを調べて、時間的な有効期間が過去のものであれば捨てても
   よいです(MAY)。

4.2 - Deleting SIGs
4.2 - 署名削除

   If a principal is authorized to update SIG records and the update
   specifies the deletion of SIG records, the server MAY choose to
   override the authority and refuse the update.  For example, the
   server may allow all SIG records not generated by a zone key to be
   deleted.
   もし修正者が署名レコードを更新する権限を与えられ、更新メッセージが署
   名レコードの削除を指定するなら、サーバーは権限に優先して更新を断るこ
   とに決めるかもしれません(MAY)。例えば、サーバーはゾーン鍵により生成さ
   れたのではないすべての署名レコードのみの削除を許すかもしれません。

4.3 - Non-explicit updates to SIGs
4.3 - 署名の明示的でない更新

   If the updated zone is secured, the RRset affected by an update
   operation MUST, at the completion of the update, be signed in
   accordance with the zone's signing policy.  This will usually require
   one or more SIG records to be generated by one or more zone keys
   whose private components MUST be online [RFC3008].
   もし最新されたゾーンが安全に保たれるなら、資源レコード集合が更新によっ
   て変更され更新が完了したら、ゾーンの署名ポリシーに従って署名されなく
   てはなりません(MUST)。これは通常1つ以上のゾーン鍵から1つ以上の署名レ
   コードを生成し、ゾーン鍵の秘密要素はオンラインでなければなりません
   (MUST)[RFC3008]。

   When the contents of an RRset are updated, the server MAY delete all
   associated SIG records, since they will no longer be valid.
   資源レコード集合の内容が更新される時、サーバーはもう正当ではないであ
   ろうと考える、すべての関連した署名レコードを削除してもよいです(MAY)。

4.4 - Effects on the zone
4.4 - ゾーンに対する効果

   If any changes are made, the server MUST, if necessary, generate a
   new SOA record and new NXT records, and sign these with the
   appropriate zone keys.  Changes to NXT records by secure dynamic
   update are explicitly forbidden.  SOA updates are allowed, since the
   maintenance of SOA parameters is outside of the scope of the DNS
   protocol.
   もし変更が行われたら、もし必要なら、サーバーは新しいSOAレコードと新し
   いNXTレコードを生成し、適切なゾーン鍵でこれらに署名しなくてはなりませ
   ん。安全なダイナミック更新でのNXTレコードの明示的な変更は禁じられてい
   ます。SOA更新はSOAパラメータのメンテナンスがDNSプロトコルの範囲の外
   にあるので許されます。

5 - Security Considerations
5 - セキュリティの考察

   This document requires that a zone key and possibly other
   cryptographic secret material be held in an on-line, network-
   connected host, most likely a name server.  This material is at the
   mercy of host security to remain a secret.  Exposing this secret puts
   DNS data at risk of masquerade attacks.  The data at risk is that in
   both zones served by the machine and delegated from this machine.
   この文書はゾーン鍵や他の暗号の秘密材料をオンラインか、ネットワークで
   繋がったホストか、よりありそうなネームサーバに保つことを要求します。
   この材料の秘密保持はホストのセキュリティ次第です。この秘密があばかれ
   ると見せかけ攻撃の危険な状態にDNSデータを置く事になります。このマ
   シンの提供するゾーンと、このマシンから委任されるゾーンの両方が危険な
   状態のデータということです。

   Allowing updates of KEY records may lead to undesirable results,
   since a principal may be allowed to insert a public key without
   holding the private key, and possibly masquerade as the key owner.
   鍵レコードの更新を許すことは、修正者がプライベート鍵を持たずに公開鍵
   を挿入し、できる限り鍵所有者のふりをすることを許すかもしれず、望まし
   くない結果に導くかもしれません。

6 - Acknowledgements
6 - 謝辞

   The author would like to thank the following people for review and
   informative comments (in alphabetical order):
   著者はレビューと教育的なコメントに対して次の人々(アルファベット順)
   に感謝したいです:

   Harald Alvestrand
   Donald Eastlake
   Olafur Gudmundsson
   Andreas Gustafsson
   Bob Halley
   Stuart Kwan
   Ed Lewis

7 - References
7 - 参考文献

   [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 1035, November 1987.

   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
              "Dynamic Updates in the Domain Name System", RFC 2136,
              April 1997.

   [RFC2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
              RFC 2137, April 1997.

   [RFC2535]  Eastlake, G., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
              Wellington, "Secret Key Transaction Signatures for DNS
              (TSIG)", RFC 2845, May 2000.

   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
              RR)", RFC 2930, September 2000.

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
              (SIG(0)s)", RFC 2931, September 2000.

   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
              Signing Authority", RFC 3008, November 2000.

8 - Author's Address
8 - 著者のアドレス

   Brian Wellington
   Nominum, Inc.
   950 Charter Street
   Redwood City, CA 94063

   Phone: +1 650 381 6022
   EMail: Brian.Wellington@nominum.com

9.  Full Copyright Statement
9.  著作権表示全文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.
   著作権(C)インターネット学会(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エディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So