この文書はRFC2136の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Status of this Memo この文書の状態 Abstract 概要 1 - Definitions 1 - 定義 1.1 - Comparison Rules 1.1 - 比較規則 1.2 - Glue RRs 1.2 - 接着剤資源レコード 1.3 - New Assigned Numbers 1.3 - 新規割当て番号 2 - Update Message Format 2 - 更新メッセージフォーマット 2.1 - Transport Issues 2.1 - 転送方法の問題 2.2 - Message Header 2.2 - メッセージヘッダー 2.3 - Zone Section 2.3 - ゾーンセクション 2.4 - Prerequisite Section 2.4 - 条件セクション 2.4.1 - RRset Exists (Value Independent) 2.4.1 - 資源レコードの存在（値はなんでもいい） 2.4.2 - RRset Exists (Value Dependent) 2.4.1 - 資源レコードの存在（値は指定したもの） 2.4.3 - RRset Does Not Exist 2.4.3 - 資源レコード集合は存在しません 2.4.4 - Name Is In Use 2.4.4 - 名前が使われています 2.4.5 - Name Is Not In Use 2.4.5 - 名前が使われてません 2.5 - Update Section 2.5 - 更新セクション 2.5.1 - Add To An RRset 2.5.1 - 資源レコードの追加 2.5.2 - Delete An RRset 2.5.2 - 資源レコード集合の削除 2.5.3 - Delete All RRsets From A Name 2.5.3 - 指定した名前の全ての資源レコードの削除 2.5.4 - Delete An RR From An RRset 2.5.4 - 資源レコード集合から資源レコードの削除 2.6 - Additional Data Section 2.6 - 追加データセクション 3 - Server Behavior 3 - サーバーの振る舞い 3.1 - Process Zone Section 3.1 - ゾーンセクション処理 3.2 - Process Prerequisite Section 3.2 - 条件セクション処理 3.3 - Check Requestor's Permissions 3.3 - 要求者の許可書を確認する 3.4 - Process Update Section 3.4 - 更新セクション処理 3.4.1 - Prescan 3.4.1 - 事前調査 3.4.2 - Update 3.4.2 - 更新 3.5 - Stability 3.5 - 安定性 3.6 - Zone Identity 3.6 - ゾーン識別 3.7 - Atomicity 3.7 - アトミック性 3.8 - Response 3.8 - 回答 4 - Requestor Behaviour 4 - 要求者行動 5 - Duplicate Detection, Ordering and Mutual Exclusion 5 - 重複検出と順序と排他 6 - Forwarding 6 - 転送 7 - Design, Implementation, Operation, and Protocol Notes 7 - デザインと実装と操作とプロトコルのメモ 8 - Security Considerations 8 - セキュリティの考慮 Acknowledgements 謝辞 References 参考文献 Authors' Addresses 著者のアドレス
Network Working Group P. Vixie, Editor
Request for Comments: 2136 ISC
Updates: 1035 S. Thomson
Category: Standards Track Bellcore
Y. Rekhter
Cisco
J. Bound
DEC
April 1997
Dynamic Updates in the Domain Name System (DNS 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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Abstract
概要
The Domain Name System was originally designed to support queries of
a statically configured database. While the data was expected to
change, the frequency of those changes was expected to be fairly low,
and all updates were made as external edits to a zone's Master File.
ドメインネームシステムは元来静的に構成を設定されたデータベースの問合
せを扱うよう意図されました。データが変化すると予想された時もその変化
の頻度はかなり低いことを期待され、そしてすべての変更はゾーンのマスター
ファイルを外部で編集するとされました。
Using this specification of the UPDATE opcode, it is possible to add
or delete RRs or RRsets from a specified zone. Prerequisites are
specified separately from update operations, and can specify a
dependency upon either the previous existence or nonexistence of an
RRset, or the existence of a single RR.
この更新オペレーションコードの仕様書を使い、ゾーンから指定した資源レ
コードを追加したり削除することが可能です。更新オペレーションの必要条
件は別に指定され、そして１つか複数の資源レコード集合の存在や非存在に
依存して指定することができます。
UPDATE is atomic, i.e., all prerequisites must be satisfied or else
no update operations will take place. There are no data dependent
error conditions defined after the prerequisites have been met.
更新はアトミックです、すなわち、すべての条件が満足してれば実施され、
そうでなければ更新オペレーションが起きないでしょう。条件が成立したら、
データに依存するエラー状態が定義されません。
1 - Definitions
1 - 定義
This document intentionally gives more definition to the roles of
"Master," "Slave," and "Primary Master" servers, and their
enumeration in NS RRs, and the SOA MNAME field. In that sense, the
following server type definitions can be considered an addendum to
[RFC1035], and are intended to be consistent with [RFC1996]:
この文書は意図的に「マスター」サーバと「スレーブ」サーバと「プライマ
リマスター」サーバの役割の定義し、ネームサーバ資源レコードの一覧とＳ
ＯＡMNAMEフィールドの定義を与えます。その意味で、次のサーバー型定義は
[RFC1035]の追加と考えることができ、[RFC1996]と一貫するように意図され
ます：
Slave an authoritative server that uses AXFR or IXFR to
retrieve the zone and is named in the zone's NS
RRset.
スレーブ ゾーンを得るためにAXFRかIXFRを使い、ゾーンのネーム
サーバ資源レコード集合で指名される正式なサーバー。
Master an authoritative server configured to be the
source of AXFR or IXFR data for one or more slave
servers.
マスター １つ以上のスレーブサーバのAXFRかIXFRの情報源に設定
された正式なサーバー。
Primary Master master server at the root of the AXFR/IXFR
dependency graph. The primary master is named in
the zone's SOA MNAME field and optionally by an NS
RR. There is by definition only one primary master
server per zone.
プライマリマスター AXFR/IXFR依存グラフのルートのマスターサーバー。プ
ライマリマスターはゾーンのSOA MNAMEフィールドで指
定され、オプションでネームサーバ資源レコードにも指
定されます。定義によりゾーン毎にただ１つのプライマ
リマスターサーバーがいます。
A domain name identifies a node within the domain name space tree
structure. Each node has a set (possibly empty) of Resource Records
(RRs). All RRs having the same NAME, CLASS and TYPE are called a
Resource Record Set (RRset).
ドメイン名がドメイン名空間木構造の中でノードを識別します。各ノードは
資源レコード(RR)の集合です（空かもしれない）。同じ名前とクラスとタイ
プを持つ資源レコードの集りは資源レコード集合(RRset)と呼ばれます。
The pseudocode used in this document is for example purposes only.
If it is found to disagree with the text, the text shall be
considered authoritative. If the text is found to be ambiguous, the
pseudocode can be used to help resolve the ambiguity.
この文書で使う擬似プログラムは例示目的のみです。もし擬似プログラムが
テキストと違うなら、テキストが正しいと思うべきです。もしテキストがあ
いまいな場合、擬似コードはあいまい性を解決するのを手伝うために使うこ
とができます。
1.1 - Comparison Rules
1.1 - 比較規則
1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
RDLENGTH and RDATA fields are equal. Note that the time-to-live
(TTL) field is explicitly excluded from the comparison.
1.1.1. ２つの資源レコードが、その名前とクラスとタイプと資源データ長
と資源データフィールドが平しければ、等しいと考えます。生存時間（TTL)
フィールドが明示的に比較から除外されることに注意してください。
1.1.2. The rules for comparison of character strings in names are
specified in [RFC1035 2.3.3].
1.1.2. 名前の文字列の比較の規則は[RFC1035 2.3.3]で指定されます。
1.1.3. Wildcarding is disabled. That is, a wildcard ("*") in an
update only matches a wildcard ("*") in the zone, and vice versa.
1.1.3. ワイルドカードは機能しません。つまり更新でのワイルドカード("*")
はゾーンのワイルドカード("*")にだけ一致し、逆も同様です。
1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
the update, and will not otherwise be followed. All UPDATE
operations are done on the basis of canonical names.
1.1.4. 別名は使用不可です：ゾーンのCNAMEは更新のCNAMEと一致し、そうで
なければ別名を展開しないでしょう。すべての更新オペレーションは標準名
で行われます。
1.1.5. The following RR types cannot be appended to an RRset. If the
following comparison rules are met, then an attempt to add the new RR
will result in the replacement of the previous RR:
1.1.5. 次の資源レコードタイプは資源レコード集合に追加できません。もし
次の比較規則が満たされるなら、新しい資源レコードを追加する試みが前の
資源レコードを置き換えるでしょう：
SOA compare only NAME, CLASS and TYPE -- it is not possible to
have more than one SOA per zone, even if any of the data
fields differ.
SOA 名前とクラスとタイプだけを比較してください−たとえデータ
フィールドのどれかが異なるとしてもゾーンに２つ以上のSOAを置
くことはできません。
WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
-- only one WKS RR is possible for this tuple, even if the
services masks differ.
WKS 名前とクラスとタイプとアドレスとプロトコルだけを比較してく
ださい−たとえサービスマスクが異なるとしても、この組み合わ
せに対して１つのWKS資源レコードだけが可能です。
CNAME compare only NAME, CLASS, and TYPE -- it is not possible
to have more than one CNAME RR, even if their data fields
differ.
CNAME ただ名前とクラスとタイプだけを比較してください−たとえデー
タフィールドが異なるとしても、２つ以上のCNAME資源レコードを
置くことは可能でありません。
1.2 - Glue RRs
1.2 - 接着剤資源レコード
For the purpose of determining whether a domain name used in the
UPDATE protocol is contained within a specified zone, a domain name
is "in" a zone if it is owned by that zone's domain name. See
section 7.18 for details.
あるゾーンの更新プロトコルでどのドメイン名を使うかを決定する目的で、
もしドメイン名がゾーンのドメイン名に所有されるならドメイン名はゾーン
の「中」にいます。詳細は７.１８章を見てください。
1.3 - New Assigned Numbers
1.3 - 新規割当て番号
CLASS = NONE (254)
RCODE = YXDOMAIN (6)
RCODE = YXRRSET (7)
RCODE = NXRRSET (8)
RCODE = NOTAUTH (9)
RCODE = NOTZONE (10)
Opcode = UPDATE (5)
2 - Update Message Format
2 - 更新メッセージフォーマット
The DNS Message Format is defined by [RFC1035 4.1]. Some extensions
are necessary (for example, more error codes are possible under
UPDATE than under QUERY) and some fields must be overloaded (see
description of CLASS fields below).
DNSメッセージフォーマットは[RFC1035 4.1]で定義されます。ある拡張子が
必要で（例えば、問合せより更新の方がエラーコードが多い）、あるフィー
ルドが多重定義されます（以下のクラスフィールドの記述を参照）。
The overall format of an UPDATE message is, following [ibid]:
更新メッセージ全体のフォーマットが以下です[ibid]：
+---------------------+
| Header |
+---------------------+
| Zone | specifies the zone to be updated
+---------------------+ 更新される地域を指定
| Prerequisite | RRs or RRsets which must (not) preexist
+---------------------+ 存在し（なく）てはならない資源レコードや資源レコード集合
| Update | RRs or RRsets to be added or deleted
+---------------------+ 追加か削除される資源レコードや資源レコード集合
| Additional Data | additional data
+---------------------+ 追加のデータ
The Header Section specifies that this message is an UPDATE, and
describes the size of the other sections. The Zone Section names the
zone that is to be updated by this message. The Prerequisite Section
specifies the starting invariants (in terms of zone content) required
for this update. The Update Section contains the edits to be made,
and the Additional Data Section contains data which may be necessary
to complete, but is not part of, this update.
ヘッダーセクションはこのメッセージが更新であることを明示して、そして
他のセクションの大きさを記述します。ゾーンセクションはこのメッセージ
によって最新のものにされるはずであるゾーンを名指します。不可欠セクショ
ンはこの更新に必要な（ゾーン内容に関する）初期値を指定します。更新セ
クションは修正内容を、追加データセクションは完成に必要かもしれないが
更新の一部ではない追加のデータを含みます。
2.1 - Transport Issues
2.1 - 転送方法の問題
An update transaction may be carried in a UDP datagram, if the
request fits, or in a TCP connection (at the discretion of the
requestor). When TCP is used, the message is in the format described
in [RFC1035 4.2.2].
更新処理は要求に足りればＵＤＰデータグラムを使うかもしれない、または
ＴＣＰ接続を使うかもしれない（要求者の裁量）。ＴＣＰが使われる時、メッ
セージは[RFC1035 4.2.2]で記述されたフォーマットです。
2.2 - Message Header
2.2 - メッセージヘッダー
The header of the DNS Message Format is defined by [RFC 1035 4.1].
Not all opcodes define the same set of flag bits, though as a
practical matter most of the bits defined for QUERY (in [ibid]) are
identically defined by the other opcodes. UPDATE uses only one flag
bit (QR).
ＤＮＳメッセージフォーマットのヘッダーは[RFC 1035 4.1]で定義されます。
実際上は([ibid]の)問い合わせで定義されたフラグが他のオペコードでも同
じく定義されるが、全てのオペコードで同じフラグビットを定義するのでは
ありません。更新がただ１フラグビットだけを使います（QR）。
The DNS Message Format specifies record counts for its four sections
(Question, Answer, Authority, and Additional). UPDATE uses the same
fields, and the same section formats, but the naming and use of these
sections differs as shown in the following modified header, after
[RFC1035 4.1.1]:
ＤＮＳメッセージフォーマットは４つのセクション（質問、解答、権威、追
加）のレコード数を指定します。更新が同じフィールドと同じセクション
フォーマットを使いますが、セクションの名前と使い方は次の修正された
ヘッダーで示すように[RFC1035 4.1.1]と異なります：。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode | Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
These fields are used as follows:
これらのフィールドは以下の様に使います
ID A 16-bit identifier assigned by the entity that generates any
kind of request. This identifier is copied in the
corresponding reply and can be used by the requestor to match
replies to outstanding requests, or by the server to detect
duplicated requests from some requestor.
識別子 全ての要求で要求を作る者が割り当てらる１６ビットの識別子。こ
の識別子は対応する応答にコピーされ、要求者が複数の要求のどれ
に対応するか判別するのに使え、サーバーで同じ問合せ者からの重
複要求を判別するのに使えます。
QR A one bit field that specifies whether this message is a
request (0), or a response (1).
QR メッセージが要求（０）か応答（１）かを示す１ビット
Opcode A four bit field that specifies the kind of request in this
message. This value is set by the originator of a request
and copied into the response. The Opcode value that
identifies an UPDATE message is five (5).
オペコード このメッセージの要求種別を指定する４ビットフィールド。こ
の値は要求の作成者が付け、回答にコピーされます。更新メッセー
ジを識別するオペコード値は５です。
Z Reserved for future use. Should be zero (0) in all requests
and responses. A non-zero Z field should be ignored by
implementations of this specification.
Z 将来の利用のために予約。全ての要求と応答で０が設定される。ゼ
ロでないＺフィールドはこの仕様書の実装では無視される。
RCODE Response code - this four bit field is undefined in requests
and set in responses. The values and meanings of this field
within responses are as follows:
RCODE 応答コードこの４ビットは要求では定義されず、応答で設定される。
応答でのこのフィールドの値と意味は以下のとおり：
Mneumonic Value Description
名称 値 意味
------------------------------------------------------------
NOERROR 0 No error condition.
エラーなし
FORMERR 1 The name server was unable to interpret
the request due to a format error.
ネームサーバーはフォーマットエラーのた
めにリクエストを翻訳することが不可能で
した。
SERVFAIL 2 The name server encountered an internal
failure while processing this request,
for example an operating system error
or a forwarding timeout.
ネームサーバはこのリクエストを処理中に
内部の故障、例えばオペレーティング・シ
ステムエラーや転送タイムアウト、に遭遇
しました。
NXDOMAIN 3 Some name that ought to exist,
does not exist.
存在するべき名前がみつからない。
NOTIMP 4 The name server does not support
the specified Opcode.
ネームサーバは指定されたオペコードをサ
ポートしません。
REFUSED 5 The name server refuses to perform the
specified operation for policy or
security reasons.
ネームサーバーはポリシーやセキュリティ
上の理由で指定されたオペレーションを行
うことを拒否します。
YXDOMAIN 6 Some name that ought not to exist,
does exist.
存在すべきでない名前が存在する。
YXRRSET 7 Some RRset that ought not to exist,
does exist.
存在すべきでない資源レコード集合が存在する。
NXRRSET 8 Some RRset that ought to exist,
does not exist.
存在するべき資源レコード集合がみつからない。
NOTAUTH 9 The server is not authoritative for
the zone named in the Zone Section.
サーバーはゾーンセクションで指定したゾー
ンの権威でありはしません。
NOTZONE 10 A name used in the Prerequisite or
Update Section is not within the
zone denoted by the Zone Section.
条件あるいは更新セクションで使われた名
前がゾーンセクションで示されるゾーン内
にありません。
ZOCOUNT The number of RRs in the Zone Section.
ゾーンセクションの資源レコードの数
PRCOUNT The number of RRs in the Prerequisite Section.
条件セクションの資源レコードの数
UPCOUNT The number of RRs in the Update Section.
更新セクションの資源レコードの数
ADCOUNT The number of RRs in the Additional Data Section.
追加セクションの資源レコードの数
2.3 - Zone Section
2.3 - ゾーンセクション
The Zone Section has the same format as that specified in [RFC1035
4.1.2], with the fields redefined as follows:
ゾーンセクションは[RFC1035 4.1.2]と同じフォーマットで、フィールドは次
のように再定義されます：。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ ZNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
UPDATE uses this section to denote the zone of the records being
updated. All records to be updated must be in the same zone, and
therefore the Zone Section is allowed to contain exactly one record.
The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
the zone's class.
更新するレコードのゾーンを意味するためにこのセクションを使います。更
新するすべてのレコードは同じゾーンになくてはならず、それ故にゾーンセ
クションは正確に１つのレコードを含むことを許されます。ZNAMEはゾーン名
です、ZTYPEはSOAに違いありません、そしてZCLASSはゾーンのクラスです。
2.4 - Prerequisite Section
2.4 - 条件セクション
This section contains a set of RRset prerequisites which must be
satisfied at the time the UPDATE packet is received by the primary
master server. The format of this section is as specified by
[RFC1035 4.1.3]. There are five possible sets of semantics that can
be expressed here, summarized as follows and then explained below.
このセクションは更新パケットをプライマリマスターサーバーが受け取る時
に満足しなければならない資源レコード集合の条件のセットを含んでいます。
このセクションのフォーマットは[RFC1035 4.1.3]によって指定されるのと
同じです。５種類の表記があり以下に概要を、後に解説をします。
(1) RRset exists (value independent). At least one RR with a
specified NAME and TYPE (in the zone and class specified by
the Zone Section) must exist.
(1) 資源レコード集合が存在します（値はなんでもいい）。指定された
名前とタイプ（ゾーンとクラスはゾーンセクションで指定されたも
の）を持つ１つ以上の資源レコードがが存在しなくてはなりません。
(2) RRset exists (value dependent). A set of RRs with a
specified NAME and TYPE exists and has the same members
with the same RDATAs as the RRset specified here in this
Section.
(2) 資源レコード集合が存在します（値は指定したもの）。指定された
名前とタイプの資源レコードの集合が存在し、資源レコード集合が
このセクションで指定したと同じ資源データの同じメンバーを持ち
ます。
(3) RRset does not exist. No RRs with a specified NAME and TYPE
(in the zone and class denoted by the Zone Section) can exist.
(3) 資源レコード集合は存在しません。指定された名前とタイプ（ゾー
ンとクラスはゾーンセクションで示されたもの）の資源レコードが
存在しません。
(4) Name is in use. At least one RR with a specified NAME (in
the zone and class specified by the Zone Section) must exist.
Note that this prerequisite is NOT satisfied by empty
nonterminals.
(4) 名前が使われています。指定された名前（ゾーンとクラスはゾーン
セクションの指定したもの）の１つ以上の資源レコードが存在しな
くてはなりません。空の非終端がこの条件を満さないことに注意し
てください。
(5) Name is not in use. No RR of any type is owned by a
specified NAME. Note that this prerequisite IS satisfied by
empty nonterminals.
(5) 名前が使われてません。指定された名前の資源レコードがどんなタ
イプにも存在しません。空の非終端がこの条件を満たすことに注意
してください。
The syntax of these is as follows:
これらの構文は次の通りです：
2.4.1 - RRset Exists (Value Independent)
2.4.1 - 資源レコードの存在（値値はなんでもいい）
At least one RR with a specified NAME and TYPE (in the zone and class
specified in the Zone Section) must exist.
指定された名前とタイプ（ゾーンとクラスはゾーンセクションで指定された
もの）を持つ１つ以上の資源レコードがが存在しなくてはなりません。
For this prerequisite, a requestor adds to the section a single RR
whose NAME and TYPE are equal to that of the zone RRset whose
existence is required. RDLENGTH is zero and RDATA is therefore
empty. CLASS must be specified as ANY to differentiate this
condition from that of an actual RR whose RDLENGTH is naturally zero
(0) (e.g., NULL). TTL is specified as zero (0).
この条件のために、要求者が条件セクションに、存在する必要があるゾーン
資源レコード集合と名前とタイプが等しいひとつの資源レコードを加えます。
資源データ長はゼロで、資源データは空です。クラスが資源データ長が元々
ゼロ（０）である実際の資源レコード（例えば、ヌル資源レコード）と区別
をするためにANYを指定します。ＴＴＬはゼロ（０）を指定します。
2.4.2 - RRset Exists (Value Dependent)
2.4.1 - 資源レコードの存在（値は指定したもの）
A set of RRs with a specified NAME and TYPE exists and has the same
members with the same RDATAs as the RRset specified here in this
section. While RRset ordering is undefined and therefore not
significant to this comparison, the sets be identical in their
extent.
指定された名前とタイプの資源レコードの集合が存在し、資源レコード集合
がこのセクションで指定したと同じ資源データの同じメンバーを持ちます。
資源レコード集合の順序は決まっていないので順序の比較は必要ないが、集
合の大きさは同じです。
For this prerequisite, a requestor adds to the section an entire
RRset whose preexistence is required. NAME and TYPE are that of the
RRset being denoted. CLASS is that of the zone. TTL must be
specified as zero (0) and is ignored when comparing RRsets for
identity.
この条件のために、要求者が条件セクションに既に存在していないといけな
い全部の資源レコード集合を加えます。名前とタイプは要求する資源レコー
ド集合と同じです。クラスはゾーンの値です。ＴＴＬはゼロ（０）が指定さ
れ、資源レコード集合を識別するためにを比較する際に無視されます。
2.4.3 - RRset Does Not Exist
2.4.3 - 資源レコード集合は存在しません
No RRs with a specified NAME and TYPE (in the zone and class denoted
by the Zone Section) can exist.
指定された名前とタイプ（ゾーンとクラスはゾーンセクションで示されたも
の）の資源レコードが存在しません。
For this prerequisite, a requestor adds to the section a single RR
whose NAME and TYPE are equal to that of the RRset whose nonexistence
is required. The RDLENGTH of this record is zero (0), and RDATA
field is therefore empty. CLASS must be specified as NONE in order
to distinguish this condition from a valid RR whose RDLENGTH is
naturally zero (0) (for example, the NULL RR). TTL must be specified
as zero (0).
この条件のために、要求者が条件セクションに、存在してはならない資源レ
コード集合と名前とタイプが等しい１つの資源レコードを加えます。資源デー
タ長はゼロで、資源データは空です。クラスが資源データ長が元々ゼロ（０）
である実際の資源レコード（例えば、ヌル資源レコード）と区別をするために
NONEを指定します。ＴＴＬはゼロ（０）を指定します。
2.4.4 - Name Is In Use
2.4.4 - 名前が使われています
Name is in use. At least one RR with a specified NAME (in the zone
and class specified by the Zone Section) must exist. Note that this
prerequisite is NOT satisfied by empty nonterminals.
名前が使われています。指定された名前（ゾーンとクラスはゾーンセクショ
ンの指定したもの）の１つ以上の資源レコードが存在しなくてはなりません。
この必要条件が空の非終端（（子供があるが自分の資源レコードを持たない
ノード）で満足しないことに注意してください。
For this prerequisite, a requestor adds to the section a single RR
whose NAME is equal to that of the name whose ownership of an RR is
required. RDLENGTH is zero and RDATA is therefore empty. CLASS must
be specified as ANY to differentiate this condition from that of an
actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TYPE
must be specified as ANY to differentiate this case from that of an
RRset existence test. TTL is specified as zero (0).
この条件のために、要求者が条件セクションに、存在が必要な名前の資源レ
コードひとつ加えます。資源データ長はゼロで、資源データは空です。クラ
スは資源データ長が元々ゼロ（０）である実際の資源レコード（例えば、ヌ
ル資源レコード）と区別をするためにANYを指定します。タイプは資源レコー
ド集合の存在チェックと区別するためANYを指定します。ＴＴＬはゼロ（０）
を指定します。
2.4.5 - Name Is Not In Use
2.4.5 - 名前が使われてません
Name is not in use. No RR of any type is owned by a specified NAME.
Note that this prerequisite IS satisfied by empty nonterminals.
名前が使われてません。指定された名前の資源レコードがどんなタイプにも
存在しません。この必要条件が空の非終端で満足することに注意してくださ
い。
For this prerequisite, a requestor adds to the section a single RR
whose NAME is equal to that of the name whose nonownership of any RRs
is required. RDLENGTH is zero and RDATA is therefore empty. CLASS
must be specified as NONE. TYPE must be specified as ANY. TTL must
be specified as zero (0).
この条件のために、要求者が条件セクションに、存在してはならない名前の
資源レコードひとつ加えます。資源データ長はゼロで、資源データは空です。
クラスはNONEを指定します。タイプはANYを指定します。ＴＴＬはゼロ（０）
を指定します。
2.5 - Update Section
2.5 - 更新セクション
This section contains RRs to be added to or deleted from the zone.
The format of this section is as specified by [RFC1035 4.1.3]. There
are four possible sets of semantics, summarized below and with
details to follow.
更新セクションはゾーンに追加か削除される資源レコードを含みます。更新
セクションのフォーマットは[RFC1035 4.1.3]で指定されるのと同じです。
４種類の表記があり以下に概要を、後に解説をします。
(1) Add RRs to an RRset.
資源レコード集合に資源レコードを追加する
(2) Delete an RRset.
資源レコード集合を削除する
(3) Delete all RRsets from a name.
ある名前の資源レコード集合を全て削除する
(4) Delete an RR from an RRset.
資源レコード集合からある資源レコードを削除する
The syntax of these is as follows:
文法は以下に示すとおりです：
2.5.1 - Add To An RRset
2.5.1 - 資源レコードの追加
RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
and RDATA are those being added, and CLASS is the same as the zone
class. Any duplicate RRs will be silently ignored by the primary
master.
更新セクションに、名前とタイプとTTLと資源レコード長と資源データが示さ
れた資源レコードがあり、これが追加されます、クラスはゾーンクラスと同
じです。重複資源レコードはプライマリマスターが黙って無視するでしょう。
2.5.2 - Delete An RRset
2.5.2 - 資源レコード集合の削除
One RR is added to the Update Section whose NAME and TYPE are those
of the RRset to be deleted. TTL must be specified as zero (0) and is
otherwise not used by the primary master. CLASS must be specified as
ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty.
If no such RRset exists, then this Update RR will be silently ignored
by the primary master.
更新セクションに、名前とタイプが示された資源レコードがあり、これが示
す資源レコード集合が削除されます。ＴＴＬにはゼロ（０）が指定されなけ
ればならなく、そうでなければプライマリマスターに無視されます。クラス
はANYが指定されます。資源データ長はゼロ（０）を指定し、資源データは空
です。もしこのような資源レコード集合が存在しないなら、この更新資源レ
コードは黙ってプライマリマスターに無視されるでしょう。
2.5.3 - Delete All RRsets From A Name
2.5.3 - 指定した名前の全ての資源レコードの削除
One RR is added to the Update Section whose NAME is that of the name
to be cleansed of RRsets. TYPE must be specified as ANY. TTL must
be specified as zero (0) and is otherwise not used by the primary
master. CLASS must be specified as ANY. RDLENGTH must be zero (0)
and RDATA must therefore be empty. If no such RRsets exist, then
this Update RR will be silently ignored by the primary master.
更新セクションに、名前が示された資源レコードがあり、これが示す資源レ
コードが全て削除されます。タイプはANYを設定します。ＴＴＬはゼロ（０）
が指定されなければならなくて、そうでなければプライマリマスターに無視
されます。クラスはANYを設定します。資源データ長はゼロ（０）を指定し、
資源データは空です。もしこのような資源レコード集合が存在しないなら、
この更新資源レコードは黙ってプライマリマスターに無視されるでしょう。
2.5.4 - Delete An RR From An RRset
2.5.4 - 資源レコード集合から資源レコードの削除
RRs to be deleted are added to the Update Section. The NAME, TYPE,
RDLENGTH and RDATA must match the RR being deleted. TTL must be
specified as zero (0) and will otherwise be ignored by the primary
master. CLASS must be specified as NONE to distinguish this from an
RR addition. If no such RRs exist, then this Update RR will be
silently ignored by the primary master.
更新セクションに削除されるＲＲが示されます。名前とタイプと資源データ
長と資源データは削除する資源データと一致しなければなりません。TTLはゼ
ロ（０）が指定され、そうでなければプライマリマスターに無視されるでしょ
う。クラスは追加する資源レコードと区別するためNONEを指定します。もし
このような資源レコードが存在しないなら、黙ってプライマリマスターに無
視されるでしょう。
2.6 - Additional Data Section
2.6 - 追加データセクション
This section contains RRs which are related to the update itself, or
to new RRs being added by the update. For example, out of zone glue
(A RRs referred to by new NS RRs) should be presented here. The
server can use or ignore out of zone glue, at the discretion of the
server implementor. The format of this section is as specified by
[RFC1035 4.1.3].
このセクションは更新か新しい資源レコードに関連する資源レコードを含み
ます。例えば、ゾーンの接着剤（新しいネームサーバを参照するアドレス資
源レコード）がここにあるべきです。サーバーの実装者の裁量で、接着剤資
源レコードを使うことも無視することもできます。このセクションのフォー
マットは[RFC1035 4.1.3]に指定される通りです。
3 - Server Behavior
3 - サーバーの振る舞い
A server, upon receiving an UPDATE request, will signal NOTIMP to the
requestor if the UPDATE opcode is not recognized or if it is
recognized but has not been implemented. Otherwise, processing
continues as follows.
更新要求を受け取ったサーバーが、もし更新オペコードが認識できないか、
認識できても実装されていなければ、要求者に未実装信号を送るでしょう。
そうでなければ次の処理が行われます。
3.1 - Process Zone Section
3.1 - ゾーンセクション処理
3.1.1. The Zone Section is checked to see that there is exactly one
RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
requestor. Next, the ZNAME and ZCLASS are checked to see if the zone
so named is one of this server's authority zones, else signal NOTAUTH
to the requestor. If the server is a zone slave, the request will be
forwarded toward the primary master.
3.1.1. ゾーンセクションの中には正確に１つの資源レコードがあり資源レコー
ドのタイプはＳＯＡです、そうでなければフォーマットエラーが要求者に送
られます。次に、名前とクラスで指定されたゾーンがこのサーバの権威ゾー
ンか確認され、そうでなければ権威でないとの信号が要求者に送られます。
もしサーバーがゾーンのスレーブなら要求はプライマリマスターに転送され
ます。
3.1.2 - Pseudocode For Zone Section Processing
3.1.2 - ゾーンセクション処理の疑似コード
if (zcount != 1 || ztype != SOA)
return (FORMERR)
if (zone_type(zname, zclass) == SLAVE)
return forward()
if (zone_type(zname, zclass) == MASTER)
return update()
return (NOTAUTH)
Sections 3.2 through 3.8 describe the primary master's behaviour,
whereas Section 6 describes a forwarder's behaviour.
セクション３．２から３．８がプライマリマスターの行動を記述し、セクショ
ン６が転送者の行動を記述します。
3.2 - Process Prerequisite Section
3.2 - 条件セクション処理
Next, the Prerequisite Section is checked to see that all
prerequisites are satisfied by the current state of the zone. Using
the definitions expressed in Section 1.2, if any RR's NAME is not
within the zone specified in the Zone Section, signal NOTZONE to the
requestor.
次に、現在のゾーン状態が条件セクションのすべての条件を満たすか検査し
ます。１．２章の定義を使い、もしある資源レコードの名前がゾーンセクショ
ンの示すゾーンになければ、ゾーンにないとの信号が要求者に送ります。
3.2.1. For RRs in this section whose CLASS is ANY, test to see that
TTL and RDLENGTH are both zero (0), else signal FORMERR to the
requestor. If TYPE is ANY, test to see that there is at least one RR
in the zone whose NAME is the same as that of the Prerequisite RR,
else signal NXDOMAIN to the requestor. If TYPE is not ANY, test to
see that there is at least one RR in the zone whose NAME and TYPE are
the same as that of the Prerequisite RR, else signal NXRRSET to the
requestor.
3.2.1. クラスがANYの資源レコードいついて、ＴＴＬと資源レコード長がど
ちらもゼロか調べます、そうでなければフォーマットエラーを要求者に送り
ます。もしタイプがANYなら、ゾーンにその名前の資源レコードが少なくとも
１つあるか確認します、そうでなければNXDOMAINを要求者に送ります。もし
タイプがANYでなければ、ゾーンにその名前とタイプの資源レコードが少なく
とも１つあるか確認します、そうでなければNXRRSETを要求者に送ります。
3.2.2. For RRs in this section whose CLASS is NONE, test to see that
the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
requestor. If the TYPE is ANY, test to see that there are no RRs in
the zone whose NAME is the same as that of the Prerequisite RR, else
signal YXDOMAIN to the requestor. If the TYPE is not ANY, test to
see that there are no RRs in the zone whose NAME and TYPE are the
same as that of the Prerequisite RR, else signal YXRRSET to the
requestor.
3.2.2. クラスがNONEの資源レコードについて、ＴＴＬと資源レコード長が両
方ゼロか確認します、そうでなければ フォーマットエラーを要求者に送りま
す。もしタイプがANYなら、ゾーンにその名前の資源レコードがないことを確
認します、あった場合は要求者にYXDOMAINを送ります。もしタイプがANYでな
いなら、その名前とタイプの資源レコードがないことを確認します、もしあ
るなら要求者にYXRRSETを送ります。
3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
test to see that the TTL is zero (0), else signal FORMERR to the
requestor. Then, build an RRset for each unique <NAME,TYPE> and
compare each resulting RRset for set equality (same members, no more,
no less) with RRsets in the zone. If any Prerequisite RRset is not
entirely and exactly matched by a zone RRset, signal NXRRSET to the
requestor. If any RR in this section has a CLASS other than ZCLASS
or NONE or ANY, signal FORMERR to the requestor.
3.2.3. クラスがZCLASSと同じ資源レコードについて、ＴＴＬがゼロか確認し
ます、 そうでなければ フォーマットエラーを要求者に送ります。それから、
名前とタイプの対毎に資源レコードを集めて資源レコード集合を生成し、ゾー
ンの資源レコードと比較します（集合に過不足なく同じメンバーがある事）。
もし正確に一致しない資源レコード集合があるなら要求者にNXRRSETを送りま
す。もし条件セクション内にクラスをZCLASSかNONEかANY以外のクラスの資源
レコードがあるなら要求者にフォーマットエラーを送ります。
3.2.4 - Table Of Metavalues Used In Prerequisite Section
3.2.4 - 条件セクション内で使うメタ値の表
CLASS TYPE RDATA Meaning
クラス タイプ 資源データ 意味
------------------------------------------------------------
ANY ANY empty Name is in use
名前が使われています。
ANY rrset empty RRset exists (value independent)
資源レコード集合が存在します（値はなんでもいい）。
NONE ANY empty Name is not in use
名前が使われてません。
NONE rrset empty RRset does not exist
資源レコード集合は存在しません。
zone rrset rr RRset exists (value dependent)
資源レコード集合が存在します（値は指定したもの）。
3.2.5 - Pseudocode for Prerequisite Section Processing
3.2.5 - 条件セクション処理の擬似コード
for rr in prerequisites
if (rr.ttl != 0)
return (FORMERR)
if (zone_of(rr.name) != ZNAME)
return (NOTZONE);
if (rr.class == ANY)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (!zone_name<rr.name>)
return (NXDOMAIN)
else
if (!zone_rrset<rr.name, rr.type>)
return (NXRRSET)
if (rr.class == NONE)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (zone_name<rr.name>)
return (YXDOMAIN)
else
if (zone_rrset<rr.name, rr.type>)
return (YXRRSET)
if (rr.class == zclass)
temp<rr.name, rr.type> += rr
else
return (FORMERR)
for rrset in temp
if (zone_rrset<rrset.name, rrset.type> != rrset)
return (NXRRSET)
3.3 - Check Requestor's Permissions
3.3 - 要求者の許可書を確認する
3.3.1. Next, the requestor's permission to update the RRs named in
the Update Section may be tested in an implementation dependent
fashion or using mechanisms specified in a subsequent Secure DNS
Update protocol. If the requestor does not have permission to
perform these updates, the server may write a warning message in its
operations log, and may either signal REFUSED to the requestor, or
ignore the permission problem and proceed with the update.
3.3.1. 次に、要求者が更新セクションで示された資源レコードを更新する許
可があるかを実装に依存する方法、または次の安全なＤＮＳ更新プロトコル
メカニズムで検査するかもしれません。もし要求者が更新を行う許可を持た
ないなら、サーバーはそのオペレーションログに警告メッセージを書いても
よくて、要求者に断わる合図をするか、許可問題を無視して更新を続けても
よいです。
3.3.2. While the exact processing is implementation defined, if these
verification activities are to be performed, this is the point in the
server's processing where such performance should take place, since
if a REFUSED condition is encountered after an update has been
partially applied, it will be necessary to undo the partial update
and restore the zone to its original state before answering the
requestor.
3.3.2. 正確な処理は実装毎に定義されますが、もし検証を行うのなら、更新
作業の途中で拒否条件に遭遇したら、拒否の答えを返す前にゾーンを更新作
業の前の状態に戻すのが、このような処理をするサーバーのポイントです。
3.3.3 - Pseudocode for Permission Checking
3.3.3 - 許可書を確認の擬似コード
if (security policy exists)
if (this update is not permitted)
if (local option)
log a message about permission problem
if (local option)
return (REFUSED)
3.4 - Process Update Section
3.4 - 更新セクション処理
Next, the Update Section is processed as follows.
次に更新セクションは以下の様に処理します
3.4.1 - Prescan
3.4.1 - 事前調査
The Update Section is parsed into RRs and each RR's CLASS is checked
to see if it is ANY, NONE, or the same as the Zone Class, else signal
a FORMERR to the requestor. Using the definitions in Section 1.2,
each RR's NAME must be in the zone specified by the Zone Section,
else signal NOTZONE to the requestor.
更新セクションの資源レコードはそれぞれの資源レコードに分解され、各資
源レコードのクラスが、ANYかNONEかゾーンクラスと同じか確認され、そうで
なければフォーマットエラーを要求者に送信します。１．２章の定義を使い
各資源レコードの名前がゾーンセクションの指定したゾーンにあるか確認し
ます、そうでなければ要求者にNOTZONEを送ります。
3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
unrecognized type, then signal FORMERR to the requestor. For RRs
whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
else signal a FORMERR to the requestor. For any RR whose CLASS is
ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
MAILB, or any other QUERY metatype besides ANY, or any unrecognized
type, else signal FORMERR to the requestor.
3.4.1.2. ANYでないクラスの資源レコードについて、タイプがANYかAXFRか
MAILAかMAILBか他のメタ問合せタイプかを確認し、認識できないタイプに対
してはフォーマットエラーを要求者に送信します。ANYやNONEのクラスの資源
レコードに対してＴＴＬがゼロか確認します、そうでなければフォーマット
エラーを要求者に送ります。クラスがANYの資源レコードについて資源レコー
ド長がゼロ（つまり資源データフィールドは空）か確認し、タイプがAXFRか
MAILAかMALIBか他のANY以外のメタ問合せタイプか認識できないタイプである
事を確認し、そうでなければフォーマットエラーを要求者に送ります。
3.4.1.3 - Pseudocode For Update Section Prescan
3.4.1.3 - 更新セクション事前調査の擬似コード
[rr] for rr in updates
if (zone_of(rr.name) != ZNAME)
return (NOTZONE);
if (rr.class == zclass)
if (rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == ANY)
if (rr.ttl != 0 || rr.rdlength != 0
|| rr.type & AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == NONE)
if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
else
return (FORMERR)
3.4.2 - Update
3.4.2 - 更新
The Update Section is parsed into RRs and these RRs are processed in
order.
更新セクションは資源レコードに分解され、これらの資源レコードは順番に
処理されます。
3.4.2.1. If any system failure (such as an out of memory condition,
or a hardware error in persistent storage) occurs during the
processing of this section, signal SERVFAIL to the requestor and undo
all updates applied to the zone during this transaction.
このセクションの処理の間にもしシステム障害がおきたら（メモリ状態や長
期記憶装置のハードウェアエラーなど）、要求者にSERVFAILを送信し、この
処理の間にゾーンに適用された更新を元どおりにしてください。
3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
the zone. In case of duplicate RDATAs (which for SOA RRs is always
the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
fields both match), the Zone RR is replaced by Update RR. If the
TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
lower (according to [RFC1982]) than or equal to the current Zone SOA
RR's SOA.SERIAL, the Update RR is ignored. In the case of a CNAME
Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
RR.
3.4.2.2. ZCLASSと同じクラスの更新資源レコードはゾーンに追加されます。
重複したが禁止される資源データについて（SOA資源レコードと、WKS資源レ
コードのADDRESSとPROTOCOLフィールドに適用）、ゾーン資源レコードは更新
資源レコードと置き換えられます。もし更新する資源レコードのタイプがSOA
でゾーンにSOA資源レコードがないか、新しいSOAシリアル番号が現在のSOA資
源レコードより小さいか等しければ（[RFC1982]による）、新しい資源レコー
ドは無視されます。新しいCNAME資源レコードと既存の非CNAME資源レコード
の組合せやその逆の場合、新しいCNAME資源レコードは無視され、そうでなけ
れば既存のCNAME資源レコードは新しいCNAME資源レコードに置き換えられま
す。
3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
all Zone RRs with the same NAME are deleted, unless the NAME is the
same as ZNAME in which case only those RRs whose TYPE is other than
SOA or NS are deleted. For any Update RR whose CLASS is ANY and
whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
deleted, unless the NAME is the same as ZNAME in which case neither
SOA or NS RRs will be deleted.
3.4.2.3. クラスとタイプがANYの更新資源レコードに対して、更新資源レコー
ドと同じ名前の既存の資源レコードは全て削除します、但しZNAMEと同じ名前
を指定した場合は、SOAとNS以外が削除します。クラスがANYでタイプがANYで
ない更新資源レコードについて、名前とタイプが一致する既存の資源レコー
ドを削除します、但し、ZNAMEと同じ名前を指定したSOAとNS資源レコードは
削除されないでしょう。
3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
unless the NAME is the same as ZNAME and either the TYPE is SOA or
the TYPE is NS and the matching Zone RR is the only NS remaining in
the RRset, in which case this Update RR is ignored.
3.4.2.4. クラスがNONEの更新資源レコードについて、名前路タイプと資源
データと資源データ長の一致する既存の資源データを削除します、但し、名
前がゾーン名でタイプがSOAか、唯一のNSの場合、この資源でコードは無視
されます。
3.4.2.5. Signal NOERROR to the requestor.
3.4.2.5. 要求者へNOERRORの送信
3.4.2.6 - Table Of Metavalues Used In Update Section
3.4.2.6 - 更新セクションで使われるメタ値のテーブル
CLASS TYPE RDATA Meaning
クラス タイプ 資源データ 意味
---------------------------------------------------------
ANY ANY empty Delete all RRsets from a name
ある名前の資源レコード集合を全て削除する
ANY rrset empty Delete an RRset
資源レコード集合を削除する
NONE rrset rr Delete an RR from an RRset
資源レコード集合からある資源レコードを削除する
zone rrset rr Add to an RRset
資源レコード集合に資源レコードを追加する
3.4.2.7 - Pseudocode For Update Section Processing
3.4.2.7 - 更新セクション処理の擬似コード
[rr] for rr in updates
if (rr.class == zclass)
if (rr.type == CNAME)
if (zone_rrset<rr.name, ~CNAME>)
next [rr]
elsif (zone_rrset<rr.name, CNAME>)
next [rr]
if (rr.type == SOA)
if (!zone_rrset<rr.name, SOA> ||
zone_rr<rr.name, SOA>.serial > rr.soa.serial)
next [rr]
for zrr in zone_rrset<rr.name, rr.type>
if (rr.type == CNAME || rr.type == SOA ||
(rr.type == WKS && rr.proto == zrr.proto &&
rr.address == zrr.address) ||
rr.rdata == zrr.rdata)
zrr = rr
next [rr]
zone_rrset<rr.name, rr.type> += rr
elsif (rr.class == ANY)
if (rr.type == ANY)
if (rr.name == zname)
zone_rrset<rr.name, ~(SOA|NS)> = Nil
else
zone_rrset<rr.name, *> = Nil
elsif (rr.name == zname &&
(rr.type == SOA || rr.type == NS))
next [rr]
else
zone_rrset<rr.name, rr.type> = Nil
elsif (rr.class == NONE)
if (rr.type == SOA)
next [rr]
if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
next [rr]
zone_rr<rr.name, rr.type, rr.data> = Nil
return (NOERROR)
3.5 - Stability
3.5 - 安定性
When a zone is modified by an UPDATE operation, the server must
commit the change to nonvolatile storage before sending a response to
the requestor or answering any queries or transfers for the modified
zone. It is reasonable for a server to store only the update records
as long as a system reboot or power failure will cause these update
records to be incorporated into the zone the next time the server is
started. It is also reasonable for the server to copy the entire
modified zone to nonvolatile storage after each update operation,
though this would have suboptimal performance for large zones.
ゾーンが更新操作で変更される時、サーバーは要求者に回答を送るか、問合
せに答えるか、変更したゾーンを転送する前に不揮発性記憶装置に変更を登
録しなければなりません。システム再開や停電でサーバーが再起動する際に
更新したレコードだけをゾーンに読み込むのが合理的です。大きいゾーンで
処理能力を下げますが、各更新処理後に不揮発性記憶装置に全変更を記憶す
るのが合理的です。
3.6 - Zone Identity
3.6 - ゾーン識別
If the zone's SOA SERIAL is changed by an update operation, that
change must be in a positive direction (using modulo 2**32 arithmetic
as specified by [RFC1982]). Attempts to replace an SOA with one
whose SERIAL is less than the current one will be silently ignored by
the primary master server.
もしゾーンのSOAシリアル番号が更新処理で変更になるなら、この変更は積極
的な指示です（[RFC1982]の規定する２の３２乗で割った余りの算術を使って
）。現在のSOAのシリアル番号を小さくする試みはプライマリマスターサーバ
に無視されます。
If the zone's SOA's SERIAL is not changed as a result of an update
operation, then the server shall increment it automatically before
the SOA or any changed name or RR or RRset is included in any
response or transfer. The primary master server's implementor might
choose to autoincrement the SOA SERIAL if any of the following events
occurs:
もしゾーンのSOAシリアルが更新処理で変更にならないなら、SOAか変更した
名前か資源レコードか資源レコード集合が応答されるか転送される前、に自
動的にシリアル番号を増加させるべきです。プライマリマスターサーバーの
実装者は、もし次のイベントのそれかが起こるなら、SOAシリアル番号を自
動増加するようにするかもしれません：
(1) Each update operation.
(1) 各更新処理
(2) A name, RR or RRset in the zone has changed and has subsequently
been visible to a DNS client since the unincremented SOA was
visible to a DNS client, and the SOA is about to become visible
to a DNS client.
(2) ゾーンの名前か資源レコードか資源レコード集合が変更された後で、ク
ライアントから新しいSOAが見える時。
(3) A configurable period of time has elapsed since the last update
operation. This period shall be less than or equal to one third
of the zone refresh time, and the default shall be the lesser of
that maximum and 300 seconds.
(3) 最後の更新処理後に再構成期間が経過した後。この期間はゾーンリフ
レッシュ時間の３分の１以下であるべきで、デフォルトはゾーンリフ
レッシュ時間の３分の１か３００秒のどちらか小さい方であるべきです。
(4) A configurable number of updates has been applied since the last
SOA change. The default value for this configuration parameter
shall be one hundred (100).
(4) 最後のSOA変更後の指定した数の更新がされた後。この構成パラメータ
のデフォルト値は１００であるべきです。
It is imperative that the zone's contents and the SOA's SERIAL be
tightly synchronized. If the zone appears to change, the SOA must
appear to change as well.
ゾーン内容とSOAシリアル番号がきちんと同期してることは重要です。もしゾー
ンを変更したら、 SOAも変更しなければなりません。
3.7 - Atomicity
3.7 - アトミック性
During the processing of an UPDATE transaction, the server must
ensure atomicity with respect to other (concurrent) UPDATE or QUERY
transactions. No two transactions can be processed concurrently if
either depends on the final results of the other; in particular, a
QUERY should not be able to retrieve RRsets which have been partially
modified by a concurrent UPDATE, and an UPDATE should not be able to
start from prerequisites that might not still hold at the completion
of some other concurrent UPDATE. Finally, if two UPDATE transactions
would modify the same names, RRs or RRsets, then such UPDATE
transactions must be serialized.
更新処理の再に、サーバーは他の（同時の）更新や問合せ処理に関して、更
新のアトミック性（更新処理の途中で他の処理が割り込まれたりしないこと
）を保証しなくてはなりません。ある処理が他の処理の結果に依存するなら
同時に処理ができません；特に、問合せで部分的に変更された資源レコード
集合を読み出せるべきでなく、他の更新によって変更される条件が確定する
前に更新を開始すべきではありません。最終的に、２つの更新処理が同じ名
前や同じ資源レコードや同じ資源レコード集合を変更するなら、このような
更新処理は順序付けられなくてはなりません。
3.8 - Response
3.8 - 回答
At the end of UPDATE processing, a response code will be known. A
response message is generated by copying the ID and Opcode fields
from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
and ADCOUNT fields and associated sections, or placing zeros (0) in
the these "count" fields and not including any part of the original
update. The QR bit is set to one (1), and the response is sent back
to the requestor. If the requestor used UDP, then the response will
be sent to the requestor's source UDP port. If the requestor used
TCP, then the response will be sent back on the requestor's open TCP
connection.
更新処理最後に回答コードを処理します。回答メッセージが問合せのＩＤと
オペコードフィールドをコピーすることで生成され、ZOCOUNTとPRCOUNTと
UPCOUNTとADCOUNT関連するセクションは問合せの値をコピーするかゼロを設
定します。QRビットは１を設定し解答は要求者に返送されます。もし要求者
がUDPを使ったなら、回答は要求者のソースUDPポートに送られるでしょう。
もし要求者がTCPを使ったなら、回答は要求者の作ったTCP接続の上で返送さ
れるでしょう。
4 - Requestor Behaviour
4 - 要求者行動
4.1. From a requestor's point of view, any authoritative server for
the zone can appear to be able to process update requests, even
though only the primary master server is actually able to modify the
zone's master file. Requestors are expected to know the name of the
zone they intend to update and to know or be able to determine the
name servers for that zone.
4.1. 実際はプライマリマスターサーバーだけがマスターファーいるを更新で
きるのですが、要求者からはゾーンのその権威サーバーも更新要求を処理可
能に思われます。要求者がゾーンの更新するゾーンの名前を知っていてゾー
ンのネームサーバーの決定が可能なことを期待されます。
4.2. If update ordering is desired, the requestor will need to know
the value of the existing SOA RR. Requestors who update the SOA RR
must update the SOA SERIAL field in a positive direction (as defined
by [RFC1982]) and also preserve the other SOA fields unless the
requestor's explicit intent is to change them. The SOA SERIAL field
must never be set to zero (0).
4.2. もし更新を望むなら、要求者は既存のSOA資源レコードの値を知る必要
があるでしょう。SOA資源レコードの更新を望む要求者はSOAシリアル番号
フィールドを積極的な指示で更新しなければなりません（[RFC1982]に示さ
れるように）、そして他にSOAフィールドは要求者が変更を望まない限り維
持されなくてはなりません。SOAシリアルフィールドにゼロを設定してはな
りません。
4.3. If the requestor has reasonable cause to believe that all of a
zone's servers will be equally reachable, then it should arrange to
try the primary master server (as given by the SOA MNAME field if
matched by some NS NSDNAME) first to avoid unnecessary forwarding
inside the slave servers. (Note that the primary master will in some
cases not be reachable by all requestors, due to firewalls or network
partitioning.)
4.3. もし要求者がゾーンのサーバすべてにアクセス可能と信じる理由を持つ
なら、スレーブサーバへの余計な負荷を避けるためプライマリマスターサー
バ（もしSOAのMNAMEフィールドの値とNSのNSDNAMEに一致するのもしがあれば、
それがプライマリマスターサーバ）に要求を試みるべきです。（ファイア
ウォールやネットワーク分割などでプライマリマスターが要求者からアクセ
スできない場合かあることに注意して下さい）。
4.4. Once the zone's name servers been found and possibly sorted so
that the ones more likely to be reachable and/or support the UPDATE
opcode are listed first, the requestor composes an UPDATE message of
the following form and sends it to the first name server on its list:
4.4. ゾーンのネームサーバが見つかって、ネームサーバをアクセス可能性や
更新処理のサポートの有無で大体の並べ替えが出来れば、要求者は更新メッ
セージを作りリストの最初のサーバーにメッセージを送ります：
ID: (new)
Opcode: UPDATE
Zone zcount: 1
Zone zname: (zone name)
Zone zclass: (zone class)
Zone ztype: T_SOA
Prerequisite Section: (see previous text)
Update Section: (see previous text)
Additional Data Section: (empty)
4.5. If the requestor receives a response, and the response has an
RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
appropriate response to its caller.
4.5. もし要求者が回答を受け取り、そして回答がSERVFAILかNOTIMP以外の応
答コードを持つなら、要求者は呼び出し者に適切な回答を返します。
4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
if no response is received within an implementation dependent timeout
period, or if an ICMP error is received indicating that the server's
port is unreachable, then the requestor will delete the unusable
server from its internal name server list and try the next one,
repeating until the name server list is empty. If the requestor runs
out of servers to try, an appropriate error will be returned to the
requestor's caller.
4.6. もし応答コードがSERVFAILかNOTIMPの回答を受け取るか、回答が実装に
依存するタイムアウト期間内に受け取れないかサーバポートへの到達不能の
ICMPエラーを受け取るなら、要求者が内部のネームサーバリストから使用で
きないサーバーを削除して、サーバーリストが空にならない限り次のサーバ
へ要求を試みます。もし要求者全てのサーバへ要求してもだめであれば、適
切なエラーが要求者の呼び出し人に返されるでしょう。
5 - Duplicate Detection, Ordering and Mutual Exclusion
5 - 重複検出と順序と排他
5.1. For correct operation, mechanisms may be needed to ensure
idempotence, order UPDATE requests and provide mutual exclusion. An
UPDATE message or response might be delivered zero times, one time,
or multiple times. Datagram duplication is of particular interest
since it covers the case of the so-called "replay attack" where a
correct request is duplicated maliciously by an intruder.
5.1. 正しい操作のため、更新の同一性と順序を保障し、排他を提供する機構
が必要かもしれません。更新メッセージや応答は０回か１回か複数回送られ
るかもしれません。データグラム重複は、正しい要求を悪意をもつ侵入者が
繰り返し行う「再生攻撃」の場合があるので、重複検出は重要です。
5.2. Multiple UPDATE requests or responses in transit might be
delivered in any order, due to network topology changes or load
balancing, or to multipath forwarding graphs wherein several slave
servers all forward to the primary master. In some cases, it might
be required that the earlier update not be applied after the later
update, where "earlier" and "later" are defined by an external time
base visible to some set of requestors, rather than by the order of
request receipt at the primary master.
5.2. ネットワークの形状や負荷や多数の転送経路やスレーブサーバーからプ
ライマリマスターサーバーへの転送によって多数の更新の要求と応答がどの
ような順序で届くかわかりません。ある場合は、前の更新が後の更新の後に
適用されることがないようにしたいかもしれません、ここで「前の」と「後
の」は要求者から見たもので、プライマリマスターへ到着する順序ではあり
ません。
5.3. A requestor can ensure transaction idempotence by explicitly
deleting some "marker RR" (rather than deleting the RRset of which it
is a part) and then adding a new "marker RR" with a different RDATA
field. The Prerequisite Section should specify that the original
"marker RR" must be present in order for this UPDATE message to be
accepted by the server.
5.3. 要求者が明示的にある「目印資源レコード」を削除して（資源レコード
集合の一部を削除するよりこの方がよい）、次に資源データフィールドが異
なる新しい「目印資源レコード」を加えることで処理の同一性を保証できま
す。条件セクションにはこのメッセージをサーバが受け入れるために元の
「目印資源レコード」を明示するべきです。
5.4. If the request is duplicated by a network error, all duplicate
requests will fail since only the first will find the original
"marker RR" present and having its known previous value. The
decisions of whether to use such a "marker RR" and what RR to use are
left up to the application programmer, though one obvious choice is
the zone's SOA RR as described below.
5.4. もしネットワークエラーで要求が繰り返されるなら、最初のだけが以前
の値の元の「目印資源レコード」を見つけ、残りは失敗するでしょう。何を
「目印資源レコード」に使うかはアプリケーションプログラマーに任されま
すが、１つの方法は下記のようにゾーンのSOA資源レコードを使うことです。
5.5. Requestors can ensure update ordering by externally
synchronizing their use of successive values of the "marker RR."
Mutual exclusion can be addressed as a degenerate case, in that a
single succession of the "marker RR" is all that is needed.
5.5. 要求者が「目印資源レコード」の値を外部と同期させることで更新順序
を保証できます。排他制御が、一連の「目印資源レコード」を使う点で、そ
の特別な場合と扱えます。
5.6. A special case where update ordering and datagram duplication
intersect is when an RR validly changes to some new value and then
back to its previous value. Without a "marker RR" as described
above, this sequence of updates can leave the zone in an undefined
state if datagrams are duplicated.
5.6. 更新順序とデータグラム重複が入り乱れる特別な場合が、資源レコード
が正しく変更され、その後もとの値に戻る場合です。上記の「目印資源レコー
ド」なしでこの連続更新をしてデータグラムが重複すると不安定な状態が残
ることがあります。
5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
a requestor could first retrieve the SOA RR, and build an UPDATE
message one of whose prerequisites was the old SOA RR. It would then
specify updates that would delete this SOA RR and add a new one with
an incremented SOA SERIAL, along with whatever actual prerequisites
and updates were the object of the transaction. If the transaction
succeeds, the requestor knows that the RRs being changed were not
otherwise altered by any other requestor.
5.7. 複数の処理「読出−変更−書込」サイクルをアトミック行うには、要求
者は最初にSOA資源レコードを読出し、次に古いSOAを条件とした更新メッセー
ジを作ります。更新には実際に行うべき処理に加えて古い資源レコードを削
除しSOAシリアル値を増やした新しいSOAを追加する更新を指定しするでしょ
う。もし処理が成功すれば、要求者は資源レコードが他の要求者によって変
更されなかったことを認識できます。
6 - Forwarding
6 - 転送
When a zone slave forwards an UPDATE message upward toward the zone's
primary master server, it must allocate a new ID and prepare to enter
the role of "forwarding server," which is a requestor with respect to
the forward server.
ゾーンスレーブサーバがゾーンのプライマリマスターサーバーに更新メッセー
ジを転送する時、更新に新しいＩＤを割り当てて「転送サーバー」の要求者と
しての役割をする準備をします。
6.1. The set of forward servers will be same as the set of servers
this zone slave would use as the source of AXFR or IXFR data. So,
while the original requestor might have used the zone's NS RRset to
locate its update server, a forwarder always forwards toward its
designated zone master servers.
6.1. 転送サーバーはゾーンのスレーブでAXFRやIXFRの発信源と同じであるで
しょう。それで本来の要求者がゾーンのNS資源レコード集合の指定するサー
バに要求を送るのに対して、転送者は常に指定されたゾーンマスターサー
バーに送ります。
6.2. If the original requestor used TCP, then the TCP connection from
the requestor is still open and the forwarder must use TCP to forward
the message. If the original requestor used UDP, the forwarder may
use either UDP or TCP to forward the message, at the whim of the
implementor.
6.2. もし本来の要求者がＴＣＰを使うなら、要求者からのＴＣＰ接続はつな
いだままで、転送者はメッセージを転送にＴＣＰを使います。もし本来の要
求者がＵＤＰを使うなら、転送者は実装者の選択でメッセージを転送にＵＤ
Ｐを使ってもＴＣＰを使ってもかまいません。
6.3. It is reasonable for forward servers to be forwarders
themselves, if the AXFR dependency graph being followed is a deep one
involving firewalls and multiple connectivity realms. In most cases
the AXFR dependency graph will be shallow and the forward server will
be the primary master server.
6.3. もしAXFR依存グラフがファイアウォールや多数の接続領域を巻き込む深
いものなら、サーバの指定された転送先に転送するのが合理的です。たいて
いの場合AXFR依存グラフは浅く、次の転送先はプライマリマスターサーバー
であるでしょう。
6.4. The forwarder will not respond to its requestor until it
receives a response from its forward server. UPDATE transactions
involving forwarders are therefore time synchronized with respect to
the original requestor and the primary master server.
6.4. 転送者は次の転送先のサーバーから回答を受け取るまで、要求者に反応
しないでしょう。転送者を含む更新処理での時間の同期は本来の要求者とプ
ライマリマスターサーバー間で行われます。
6.5. When there are multiple possible sources of AXFR data and
therefore multiple possible forward servers, a forwarder will use the
same fallback strategy with respect to connectivity or timeout errors
that it would use when performing an AXFR. This is implementation
dependent.
6.5. 複数のAXFR要求先があり、従って多数の転送先があるサーバは、接続と
タイムアウト後の候補の選択にAXFRの場合と同じ戦略を使うでしょう。これ
は実装に依存します。
6.6. When a forwarder receives a response from a forward server, it
copies this response into a new response message, assigns its
requestor's ID to that message, and sends the response back to the
requestor.
6.6. 転送者が転送先のサーバーから回答を受け取たったら、この回答を新し
い回答メッセージにコピーして、メッセージの要求者の指定したＩＤを割り
当て、要求者に回答を返送します。
7 - Design, Implementation, Operation, and Protocol Notes
7 - デザインと実装と操作とプロトコルのメモ
Some of the principles which guided the design of this UPDATE
specification are as follows. Note that these are not part of the
formal specification and any disagreement between this section and
any other section of this document should be resolved in favour of
the other section.
この更新仕様書のデザインを導いた原則のいくつかが次の通りです。これら
が正式の仕様の一部ではなく、この章とこの文書の他の章の間に相違がある
場合、他の章が正しいことに注意してください。
7.1. Using metavalues for CLASS is possible only because all RRs in
the packet are assumed to be in the same zone, and CLASS is an
attribute of a zone rather than of an RRset. (It is for this reason
that the Zone Section is not optional.)
7.1. クラスに複数の値を使うのは、すべてのパケットの資源レコードが同じ
ゾーンにあると考えられるから、可能で、クラスは資源レコード集合よりむ
しろゾーンの属性です（ゾーンセクションがオプションではないのはこの理
由のためです）。
7.2. Since there are no data-present or data-absent errors possible
from processing the Update Section, any necessary data-present and
data- absent dependencies should be specified in the Prerequisite
Section.
7.2. 更新セクション処理でデータの存在や非存在のエラーが不可能なので、
データの存在や非存在が必要な場合は条件セクションで指定されるべきです。
7.3. The Additional Data Section can be used to supply a server with
out of zone glue that will be needed in referrals. For example, if
adding a new NS RR to HOME.VIX.COM specifying a nameserver called
NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional
Data Section. Servers can use this information or ignore it, at the
discretion of the implementor. We discourage caching this
information for use in subsequent DNS responses.
7.3. 追加データセクションが参照に必要なゾーンの接着剤がないサーバのた
めに供給されます。例えば、もしHOME.VIX.COMにNS.AU.OZと呼ばれるネーム
サーバを指定した新しいネームサーバ資源レコードを加えるなら、 NS.AU.OZ
のアドレス資源レコードを追加のデータセクションに含めることができます。
サーバーがこの情報を使うか無視するかは実装者の裁量です。我々は次のＤ
ＮＳ回答で使うためにこの情報をキャッシュするのに賛成しません。
7.4. The Additional Data Section might be used if some of the RRs
later needed for Secure DNS Update are not actually zone updates, but
rather ancillary keys or signatures not intended to be stored in the
zone (as an update would be), yet necessary for validating the update
operation.
7.4. 追加データセクションはゾーン更新で登録されるためではなく、後の安
全なＤＮＳ更新に必要な補助鍵や署名に使われるかもしれません。
7.5. It is expected that in the absence of Secure DNS Update, a
server will only accept updates if they come from a source address
that has been statically configured in the server's description of a
primary master zone. DHCP servers would be likely candidates for
inclusion in this statically configured list.
7.5. 安全なＤＮＳ更新がなくプライマリマスターゾーンで静的に設定された
ソースアドレスから要求が来たら、単純に更新を受け入れると思われます。
ＤＨＣＰサーバーがこの静的に設定されたリストの有力候補でしょう。
7.6. It is not possible to create a zone using this protocol, since
there is no provision for a slave server to be told who its master
servers are. It is expected that this protocol will be extended in
the future to cover this case. Therefore, at this time, the addition
of SOA RRs is unsupported. For similar reasons, deletion of SOA RRs
is also unsupported.
7.6. スレーブサーバーは知らないゾーンのマスターサーバーが誰かわからな
いので、このプロトコルでゾーンを作ることは出来ません。この場合のため
のプロトコル拡張が将来行われると思われます。それ故、現在は、SOA資源レ
コードの追加はサポートされません。同様な理由でSOA資源レコードの削除は
サポートされません。
7.7. The prerequisite for specifying that a name own at least one RR
differs semantically from QUERY, in that QUERY would return
<NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at
this name, while UPDATE's prerequisite condition [Section 2.4.4]
would NOT be satisfied.
7.7. ある名前の存在を要求する条件は問合せ処理と異なります、もし更新の
条件セクションである名前の資源レコード集合が要求され条件を満たさなけ
れば[２．４．４参照]、問い合わせでは<エラーなし、答えなし>を返します
が更新ではNXDOMAINを返します。
7.8. It is possible for a UDP response to be lost in transit and for
a request to be retried due to a timeout condition. In this case an
UPDATE that was successful the first time it was received by the
primary master might ultimately appear to have failed when the
response to a duplicate request is finally received by the requestor.
(This is because the original prerequisites may no longer be
satisfied after the update has been applied.) For this reason,
requestors who require an accurate response code must use TCP.
7.8. ＵＤＰ応答が転送中に失われタイムアウト条件により再送する事は可能
です。この場合、プライマリマスターが最初に受取った更新が成功していて
も、重複要請に対する回答で最終的に要求者には失敗してるように見えるか
もしれません（これは元の条件が更新後には満足されないからです）。この
理由のために、正確な回答コードが必要な要求者はＴＣＰを使わなければな
りません。
7.9. Because a requestor who requires an accurate response code will
initiate their UPDATE transaction using TCP, a forwarder who receives
a request via TCP must forward it using TCP.
7.9. 正確な回答コードを必要とする要求者がＴＣＰで更新処理をするので、
ＴＣＰで要求を受取る転送者がＴＣＰでそれを転送しなければなりません。
7.10. Deferral of SOA SERIAL autoincrements is made possible so that
serial numbers can be conserved and wraparound at 2**32 can be made
an infrequent occurance. Visible (to DNS clients) SOA SERIALs need
to differ if the zone differs. Note that the Authority Section SOA
in a QUERY response is a form of visibility, for the purposes of this
prerequisite.
7.10. SOAシリアル番号の自動変更の延期がシリアル番号を節約し２の３２乗
で元に戻るのをまれな事象にすることができます。（ＤＮＳクライアントか
ら）見て、SOAシリアルはゾーンが変わる毎に変わる必要があります。問合せ
の応答での権威セクションのSOAが、この条件の目的のために見える形式であ
ることを注意を払ってください。
7.11. A zone's SOA SERIAL should never be set to zero (0) due to
interoperability problems with some older but widely installed
implementations of DNS. When incrementing an SOA SERIAL, if the
result of the increment is zero (0) (as will be true when wrapping
around 2**32), it is necessary to increment it again or set it to one
(1). See [RFC1982] for more detail on this subject.
7.11. 古いが広く普及しているＤＮＳ実装との互換性の問題のためゾーンの
SOAシリアル番号はゼロを設定してはなりません。SOAシリアル番号を増やす
際に増やした結果がゼロだったら（２の３２乗はゼロになる）、さらに増加
させるか１を設定する必要があります。この問題の詳細は[RFC1982]を見て
ください。
7.12. Due to the TTL minimalization necessary when caching an RRset,
it is recommended that all TTLs in an RRset be set to the same value.
While the DNS Message Format permits variant TTLs to exist in the
same RRset, and this variance can exist inside a zone, such variance
will have counterintuitive results and its use is discouraged.
7.12. 資源レコード集合をキャッシュする場合のＴＴＬを最小化するために、
資源レコード集合のＴＴＬ値を同じ値にする事が勧められます。ＤＮＳメッ
セージフォーマットが同じ資源レコード集合に異なるＴＴＬの資源レコード
があるのを許しゾーン内でも可能ですが、この結果は期待できない結果を生
じ、異なるＴＴＬの使用を賛成しません。
7.13. Zone cut management presents some obscure corner cases to the
add and delete operations in the Update Section. It is possible to
delete an NS RR as long as it is not the last NS RR at the root of a
zone. If deleting all RRs from a name, SOA and NS RRs at the root of
a zone are unaffected. If deleting RRsets, it is not possible to
delete either SOA or NS RRsets at the top of a zone. An attempt to
add an SOA will be treated as a replace operation if an SOA already
exists, or as a no-op if the SOA would be new.
7.13. ゾーン分割管理は更新セクションでの追加削除操作に不明瞭な点を生
じます。ゾーンのルートの最後のネームサーバ資源レコードでない限り、
ネームサーバ資源レコードを削除できます。もしある名前の全ての資源レ
コードを削除するなら、ルートのSOAとネームサーバ資源レコードは影響が
ありません。もし資源レコード集合を削除するなら、地域の最上位でSOAや
ネームサーバ資源レコード集合を削除できません。SOAを追加する試みは、
SOAがあればそれを置換えSOAが既に新らしければ無視する、操作に置き換え
られます。
7.14. No semantic checking is required in the primary master server
when adding new RRs. Therefore a requestor can cause CNAME or NS or
any other kind of RR to be added even if their target name does not
exist or does not have the proper RRsets to make the original RR
useful. Primary master servers that DO implement this kind of
checking should take great care to avoid out-of-zone dependencies
(whose veracity cannot be authoritatively checked) and should
implement all such checking during the prescan phase.
7.14. 資源レコードを追加する際にプライマリマスターサーバーで意味を確
認する必要はありません。それ故、要求者はターゲットが存在しなかったり
元の資源レコードを利用可能にする適切な資源レコード集合がなくても、
CNAMEやNSや他の資源レコードを追加できます。この種類の調べることをプラ
イマリマスターサーバーの実装はゾーン外の依存（正しい真実か確認できな
い）を避けるため大きな注意をすべきで、事前検査段階で確認を実行するべ
きです。
7.15. Nonterminal or wildcard CNAMEs are not well specified by
[RFC1035] and their use will probably lead to unpredictable results.
Their use is discouraged.
7.15. 非終端やワイルドカードのCNAMEはうまく指定できず[RFC1035]、その
使用は恐らく予想できない結果を生むでしょう。その使用を賛成しません。
7.16. Empty nonterminals (nodes with children but no RRs of their
own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response
to a query of any type for that name. There is no provision for
empty terminal nodes -- so if all RRs of a terminal node are deleted,
the name is no longer in use, and queries of any type for that name
will result in an NXDOMAIN response.
7.16. 空の非終端（子供があるがそれ自身資源レコードを持たないノード）
は<エラーなし、解答なし>の回答を返送することになります。空の終端ノー
ドはないので、もしすべての終端ノードの資源レコードが削除されれば、名
前は使用中でなく、その名前の問合せの結果はNXDOMAINでしょう。
7.17. In a deep AXFR dependency graph, it has not historically been
an error for slaves to depend mutually upon each other. This
configuration has been used to enable a zone to flow from the primary
master to all slaves even though not all slaves have continuous
connectivity to the primary master. UPDATE's use of the AXFR
dependency graph for forwarding prohibits this kind of dependency
loop, since UPDATE forwarding has no loop detection analagous to the
SOA SERIAL pretest used by AXFR.
7.17. 深いAXFR依存グラフで、歴史的にスレーブが相互にお依存するのは誤
りでありませんでした。この設定はゾーンの全てのスレーブがプライマリマ
スターと常に接続しているのではないが、プライマリマスターから全てのス
レーブにデータが流れるようするために使われました。更新転送はAXFRのSOA
シリアルの事前テストの様なループ検出がないので、更新の転送でのAXFR依
存グラフの利用はこの様な依存ループを禁止します。
7.18. Previously existing names which are occluded by a new zone cut
are still considered part of the parent zone, for the purposes of
zone transfers, even though queries for such names will be referred
to the new subzone's servers. If a zone cut is removed, all parent
zone names that were occluded by it will again become visible to
queries. (This is a clarification of [RFC1034].)
7.18. 前にあったが新しい地域分割でゾーンが変わった名前は、この名前を
問合せると新しいサブゾーンのサーバーを返しますが、地域転送の目的では
まだ親ゾーンの一部と思われます。もしゾーン分割がなくなると、見えなく
なった親ゾーンの名前が再び見えるようになります。（これは[RFC1034]の解
説です）。
7.19. If a server is authoritative for both a zone and its child,
then queries for names at the zone cut between them will be answered
authoritatively using only data from the child zone. (This is a
clarification of [RFC1034].)
7.19. もしサーバーが親ゾーンと子ゾーン両方の権威なら、ゾーン分割され
た名前の問合せに対して子ゾーンのデータだけを使って権威をもって答える
でしょう（これは[RFC1034]の解説です）。
7.20. Update ordering using the SOA RR is problematic since there is
no way to know which of a zone's NS RRs represents the primary
master, and the zone slaves can be out of date if their SOA.REFRESH
timers have not elapsed since the last time the zone was changed on
the primary master. We recommend that a zone needing ordered updates
use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see
[RFC1995]), and that a client receiving a prerequisite error while
attempting an ordered update simply retry after a random delay period
to allow the zone to settle.
7.20. SOA資源レコードを使用して更新を順序付けるのは、ゾーンのネームサー
バ資源レコードのいずれがプライマリマスターの代理を務めるか知る方法が
ないので、問題が多いです、そしてゾーンスレーブは、もしプライマリマス
ターのゾーンが最後に変更になってからSOAリフレッシュタイマーがタイムア
ウトしていなければ、時代遅れです。我々は順序づけられた更新を必要とし
するゾーンがNOTIFY（[RFC1996]参照）とIXFR（[RFC1995]参照）を実装し、
条件えらを生じたクライアントがランダムな遅延の後にゾーン解決をするこ
とを勧めます。
8 - Security Considerations
8 - セキュリティの考慮
8.1. In the absence of [RFC2137] or equivilent technology, the
protocol described by this document makes it possible for anyone who
can reach an authoritative name server to alter the contents of any
zones on that server. This is a serious increase in vulnerability
from the current technology. Therefore it is very strongly
recommended that the protocols described in this document not be used
without [RFC2137] or other equivalently strong security measures,
e.g. IPsec.
8.1. [RFC2137]の欠如かあいまいな技術のため、この文書で記述されたプロ
トコルは正式なネームサーバのゾーンの中身を誰でも変更できるようにしま
す。これは新たな問題です。それ故にこの文書で記述されたプロトコルが
[RFC2137]か他の同等のセキュリティ手段、例えばIPsec、と共に使うことを
非常に強く推薦します。
8.2. A denial of service attack can be launched by flooding an update
forwarder with TCP sessions containing updates that the primary
master server will ultimately refuse due to permission problems.
This arises due to the requirement that an update forwarder receiving
a request via TCP use a synchronous TCP session for its forwarding
operation. The connection management mechanisms of [RFC1035 4.2.2]
are sufficient to prevent large scale damage from such an attack, but
not to prevent some queries from going unanswered during the attack.
8.2. 更新転送者にTCP接続でプライマリマスターサーバーが拒否するような
更新を送りサービス拒否攻撃をする事ができます。これはＴＣＰで要求を受
取る更新転送者が転送処理に同期したＴＣＰが必要との条件により発生しま
す。[RFC1035 4.2.2]接続管理機構はこのような攻撃から大規模な損害を妨ぎ、
しかし攻撃の間もいくつかの質問に答えれるようにするのに十分です。
Acknowledgements
謝辞
We would like to thank the IETF DNSIND working group for their input
and assistance, in particular, Rob Austein, Randy Bush, Donald
Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz. Special
thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this
document.
我々はIETFのDNSINDワークグループの、特にRob AusteinとRandy Bushと
Donald EastlakeとMasataka OhtaとMark AndrewsとRobert Elzのインプット
と援助に感謝します。Bill SimpsonとKen WallichとBob Halleyこの文書の
レビューに特別に感謝します。
References
参考文献
[RFC1035]
Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[RFC1982]
Elz, R., "Serial Number Arithmetic", RFC 1982, University of
Melbourne, August 1996.
[RFC1995]
Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute
of Technology, August 1996.
[RFC1996]
Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
RFC 1996, Internet Software Consortium, August 1996.
[RFC2065]
Eastlake, D., and C. Kaufman, "Domain Name System Protocol
Security Extensions", RFC 2065, January 1997.
[RFC2137]
Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
2137, April 1997.
Authors' Addresses
著者のアドレス
Yakov Rekhter
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: +1 914 528 0090
EMail: yakov@cisco.com
Susan Thomson
Bellcore
445 South Street
Morristown, NJ 07960
Phone: +1 201 829 4514
EMail: set@thumper.bellcore.com
Jim Bound
Digital Equipment Corp.
110 Spitbrook Rd ZK3-3/U14
Nashua, NH 03062-2698
Phone: +1 603 881 0400
EMail: bound@zk3.dec.com
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
Phone: +1 415 747 0204
EMail: paul@vix.com