この文書はRFC3007の日本語訳です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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
安全なドメインネームシステム（ＤＮＳ）ダイナミック更新
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 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.
この文書は安全なドメインネームシステム（ＤＮＳ）ダイナミック更新の方
法を提案します。ここで記述された方法は最小限のプロトコル変更で、柔軟
かつ有用になるように意図されます。ダイナミック更新メッセージの認証は、
その後のデータのＤＮＳＳＥＣ検証とは独立しています。要求と処理の認証
による安全な通信が認証を行うために使われます。
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.
この文書は認定された情報源のみにゾーンの中身の更新を許すドメインネー
ムシステム（ＤＮＳ）のダイナミックな更新手段を定義します。既存の保証
がないダイナミックな更新処理はこの仕事の基礎になります。
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.
ＤＮＳシステム[RFC1034, RFC1035]とダイナミック更新[RFC2136]に精通する
事は助けになり、この文書の仮定です。さらにＤＮＳセキュリティ拡張
[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の特に３.１.２章と、RFC 2136を更新します。この文書
はRFC 2137を時代遅れにし、実装経験のため代わりの提案をします。
1.1 - Overview of DNS Dynamic Update
1.1 - ＤＮＳダイナミックな更新の概要
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.
ＤＮＳダイナミックな更新が新しいオペコードと、そのオペコードを使う場
合のＤＮＳメッセージの新しい解釈を定義します。更新は、更新をするのに
必要な条件と、追加か削除するデータを指定できます。ＤＮＳ更新のすべて
のテストと変更の要求はひとつのゾーンに制限され、ゾーンのプライマリサー
バーで行われます。ダイナミックゾーンのプライマリサーバーは更新をする
時は次のSOAの検索の前にゾーンのSOAシリアル番号を増加させなくてはなり
ません。
1.2 - Overview of DNS Transaction Security
1.2 - ＤＮＳ処理セキュリティの概要
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 メッセージの交換が２つのＤＮＳ処
理者間で交換するＤＮＳ問合せと解答の認証を可能にします。TSIG MAC（メッ
セージ認証コード）が共有する秘密から得られます、そしてSIG(0)はプライ
ベートキーから生成され対応する公開部はＤＮＳに登録されます。両方の場
合、メッセージ署名/MACを含むレコードが最後の資源レコードとしてＤＮＳ
メッセージに含められます。TSIGで使う鍵付きハッシュは、計算と検証が簡
単です。SIG(0)で使われるように、公開鍵暗号は公開鍵がＤＮＳに登録され
る時よりスケーラブルです。
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)を使ったメッセージ毎の認証は、１つの署名と１つの検証でメッ
セージ全体を保護します、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.
ＤＮＳＳＥＣ署名レコードがゾーン所有者の署名でＤＮＳメッセージの個々
の資源レコードや資源レコード集合の完全性を守るのに使うことができます。
しかしこれは十分にダイナミックな更新要求を守ることができません。
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]で指定されるように、リゾルバの行うＤＮＳＳＥＣ検証処理は、
ローカルポリシーで決められてなければ、非ゾーン鍵を処理してはなりませ
ん(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.
ＤＮＳＳＥＣに関するホストとユーザーの鍵が有効であれば、ダイナミック
更新メッセージを含めて、メッセージを本物と証明するはずです。それで、
ホストとユーザの鍵は更新の認証のためSIG(0)レコードを生成し(MAY)、
TKEY[RFC2930]処理がTSIG共有秘密鍵生成に使われるかもしれません(MAY)。
両方の場合、非ゾーン鍵によって生成された署名レコードが、ローカルポリ
シーで規定されなければ、ＤＮＳＳＥＣ検証処理で使われないでしょう。
Authentication of data, once it is present in DNS, only involves
DNSSEC zone keys and signatures generated by them.
データ認証がＤＮＳに存在している場合、ただＤＮＳＳＥＣゾーン鍵を伴う
だけで、ゾーン鍵で署名が生成されます。
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]が、フラグフィールドの最後の４ビットを鍵の署
名者フィールドと定義しますが、値を定義しません。この提案はこのフィー
ルドを不確定なままにしておきます。[RFC2535]を更新し、このフィールドは
鍵レコードで０を設定するべきで(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(０)。
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.
ポリシーはいくつかの理由のために完全プライマリゾーンサーバーに実装さ
れます。これによりポリシーが（鍵資源レコードの署名者フィールドのよう
な）固定ビット数内といった限界を課されません。ポリシーはそれを運用す
るサーバーにだけ関係があり、それをさらす理由がありません。最後に、ポ
リシー変更や新しいタイプのポリシーがＤＮＳプロトコルやデータフォーマッ
トに影響を与えるべきでなくて、互換性誤りを起こすべきではありません。
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)、すべてのタイプとすべての「ユーザー」タイプの簡潔な表現を供
給すべきです、ここでユーザータイプとはＤＮＳオペレーション自身に影響
を与えないものの事です。
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 - ＤＮＳＳＥＣとの相互作用
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パラメータのメンテナンスがＤＮＳプロトコルの範囲の外
にあるので許されます。
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.
この文書はゾーン鍵や他の暗号の秘密材料をオンラインか、ネットワークで
繋がったホストか、よりありそうなネームサーバに保つことを要求します。
この材料の秘密保持はホストのセキュリティ次第です。この秘密があばかれ
ると見せかけ攻撃の危険な状態にＤＮＳデータを置く事になります。このマ
シンの提供するゾーンと、このマシンから委任されるゾーンの両方が危険な
状態のデータということです。
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.
著作権（Ｃ）インターネット学会（２０００）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。