この文書はRFC1996の日本語訳です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group P. Vixie
Request for Comments: 1996 ISC
Updates: 1035 August 1996
Category: Standards Track
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
ゾーン変更の即時通知機構のメカニズム(DNS NOTIFY)
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
概要
This memo describes the NOTIFY opcode for DNS, by which a master
server advises a set of slave servers that the master's data has been
changed and that a query should be initiated to discover the new
data.
この文書はＤＮＳの通知オペコードを記述します、通知オペコードマスター
サーバがスレーブサーバにマスターデータが変更され、新しいデータを得る
問合せを行うべきである事を知らせます。
1. Rationale and Scope
1. 原理と範囲
1.1. Slow propagation of new and changed data in a DNS zone can be
due to a zone's relatively long refresh times. Longer refresh times
are beneficial in that they reduce load on the master servers, but
that benefit comes at the cost of long intervals of incoherence among
authority servers whenever the zone is updated.
1.1. ＤＮＳゾーンの新しく変更になったデータの普及が遅いのは、ゾーンの
比較的長いリフレッシュ時間のためです。長いリフレッシュ時間はマスター
サーバーの負荷を減らす点で有益ですが、その代わりゾーンを更新した際に
プライマリサーバとスレーブサーバ間で長い間ゾーンデータが一致しません。
1.2. The DNS NOTIFY transaction allows master servers to inform slave
servers when the zone has changed -- an interrupt as opposed to poll
model -- which it is hoped will reduce propagation delay while not
unduly increasing the masters' load. This specification only allows
slaves to be notified of SOA RR changes, but the architechture of
NOTIFY is intended to be extensible to other RR types.
1.2. ＤＮＳ通知処理はマスターサーバがスレーブサーバにゾーンが変化した
事を通知するのを許します−プルモデルに反する割り込み−これはマスター
の負荷を増やさずにゾーンの普及の遅延を減らすのが希望です。この仕様書
はただスレーブにSOA資源レコードの変更の通知を許すだけですが、通知は他
の資源レコードタイプでも利用可能になるように意図されます。
1.3. This document intentionally gives more definition to the roles
of "Master," "Slave" and "Stealth" servers, their enumeration in NS
RRs, and the SOA MNAME field. In that sense, this document can be
considered an addendum to [RFC1035].
1.3. このドキュメントは意図的にネームサーバ資源レコードとＳＯＡのＭＮ
ＡＭＥフィールドに列挙される「マスター」と「スレーブ（奴隷）」と「ス
テルス（内密）」サーバーの役割により多くの定義を与えます。この意味で、
この文書は[RFC1035]の補遺と思うことができます。
2. Definitions and Invariants
2. 定義と定数
2.1. The following definitions are used in this document:
2.1. 次の定義がこの文書で使われます：
Slave an authoritative server which uses zone transfer to
retrieve the zone. All slave servers are named in
the NS RRs for the zone.
スレーブ ゾーンデータを得るためにゾーン転送を使う正式なサーバ。
すべてのスレーブサーバはゾーンのネームサーバ資源レコー
ドで示します。
Master any authoritative server configured to be the source
of zone transfer for one or more slave servers.
マスター スレーブサーバにゾーン転送の情報源と設定された正式な
サーバ
Primary Master master server at the root of the zone transfer
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.
プライマリマスター ゾーン転送依存グラフのルートになるマスターサーバ。
プライマリマスターはゾーンのSOAのMNAMEフィールドに設
定し、任意でネームサーバ資源レコードに設定します。定
義によりゾーン毎にただ１つのプライマリマスターサーバー
がいます。
Stealth like a slave server except not listed in an NS RR for
the zone. A stealth server, unless explicitly
configured to do otherwise, will set the AA bit in
responses and be capable of acting as a master. A
stealth server will only be known by other servers if
they are given static configuration data indicating
its existence.
ステルス スレーブサーバとして動作するが、ゾーンのネームサーバ
資源レコードに設定されていないもの。明示的に設定され
ていなければ、ステルスサーバは回答のＡＡビットを設定
し、マスターの役を務めることができるでしょう。ステル
スサーバは静的に存在を設定されたサーバにのみ知られて
いるだけでしょう。
Notify Set set of servers to be notified of changes to some
zone. Default is all servers named in the NS RRset,
except for any server also named in the SOA MNAME.
Some implementations will permit the name server
administrator to override this set or add elements to
it (such as, for example, stealth servers).
通知セット あるゾーンの変更を通知されるサーバーの集合。デフォル
トは、ＳＯＡのＭＮＡＭＥに設定されたサーバを除く、ネー
ムサーバ資源レコード集合で指定されたサーバ全てです。
実装によってはネームサーバ管理者が手動で設定したり、
（ステルスサーバなどの）サーバを追加したりできるで
しょう。
2.2. The zone's servers must be organized into a dependency graph
such that there is a primary master, and all other servers must use
AXFR or IXFR either from the primary master or from some slave which
is also a master. No loops are permitted in the AXFR dependency
graph.
2.2. ゾーンのサーバは依存グラフによって組織化されなければならず、そこ
にはプライマリマスタサーバが存在し、他のゾーンのサーバはプライマリマ
スターかマスターでもあるスレーブサーバに対してAXFRかIXFRを使います。
AXFR依存グラフでループは許されません。
3. NOTIFY Message
3. 通知メッセージ
3.1. When a master has updated one or more RRs in which slave servers
may be interested, the master may send the changed RR's name, class,
type, and optionally, new RDATA(s), to each known slave server using
a best efforts protocol based on the NOTIFY opcode.
3.1. マスターサーバがスレーブサーバの興味を持つ資源レコードを更新した
際に、マスターはスレーブサーバへ、ベストエフォー（最善の努力）プロト
コルと通知オペコードを使って、変更した資源レコードの名前とクラスとタ
イプと、オプションで、新しい資源データを送ります。
3.2. NOTIFY uses the DNS Message Format, although it uses only a
subset of the available fields. Fields not otherwise described
herein are to be filled with binary zero (0), and implementations
must ignore all messages for which this is not the case.
3.2. 通知はＤＮＳメッセージフォーマットを使いますが、一部のフィールド
しか使いません。この文書で記述されないフィールドはバイナリのゼロ（０）
を設定され、これらの意味のないビットは無視されなければなりません。
3.3. NOTIFY is similar to QUERY in that it has a request message with
the header QR flag "clear" and a response message with QR "set". The
response message contains no useful information, but its reception by
the master is an indication that the slave has received the NOTIFY
and that the master can remove the slave from any retry queue for
this NOTIFY event.
3.3. 通知は、ＱＲビットを要求ではクリアし、応答では設定する点で、要求
に類似します。回答メッセージは有意な情報を持ちませんが、スレーブがメッ
セージを受信したことをマスターに知らせ、マスターは通知イベントの再送
キューからそのスレーブを取り除くことができます。
3.4. The transport protocol used for a NOTIFY transaction will be UDP
unless the master has reason to believe that TCP is necessary; for
example, if a firewall has been installed between master and slave,
and only TCP has been allowed; or, if the changed RR is too large to
fit in a UDP/DNS datagram.
3.4. 通知処理で使う転送プロトコルは、ＴＣＰを使う理由が見当たらなけれ
ば、ＵＤＰです；ＴＣＰを使うのは、例えばマスターとスレーブの間にファ
イアウォールがありＴＣＰしか使えない場合とか、変更する資源レコードが
とても大きくてＵＤＰ／ＤＮＳデータグラムに収まらない場合などです。
3.5. If TCP is used, both master and slave must continue to offer
name service during the transaction, even when the TCP transaction is
not making progress. The NOTIFY request is sent once, and a
"timeout" is said to have occurred if no NOTIFY response is received
within a reasonable interval.
3.5. もしＴＣＰを使うなら、ＴＣＰ処理が滞っている時でも、マスターとス
レーブはネームサービスは継続しなければなりません。通知要求が送られ合
理的な期間内に通知応答を得られなければ、「タイムアウト」が起きたと言
います。
3.6. If UDP is used, a master periodically sends a NOTIFY request to
a slave until either too many copies have been sent (a "timeout"), an
ICMP message indicating that the port is unreachable, or until a
NOTIFY response is received from the slave with a matching query ID,
QNAME, IP source address, and UDP source port number.
3.6. ＵＤＰを使う場合マスターは周期的に通知をスレーブに送ります、多数
の通知を送った場合（「タイムアウト」）や、ポートが利用できないとのＩ
ＣＭＰメッセージを受取った場合や、スレーブから問合せＩＤと問合せ名と
ＩＰソースアドレスとＵＤＰソースポートの正しい通知応答を受取った場合
に送信を止めます。
Note:
The interval between transmissions, and the total number of
retransmissions, should be operational parameters specifiable by
the name server administrator, perhaps on a per-zone basis.
Reasonable defaults are a 60 second interval (or timeout if
using TCP), and a maximum of 5 retransmissions (for UDP). It is
considered reasonable to use additive or exponential backoff for
the retry interval.
注：
送信間隔と再送回数はネームサーバ管理者の設定する運用パラメータであ
るべきで、多分ゾーン毎に設定できます。合理的なデフォルトは６０秒間
隔（もしくはＴＣＰを使う場合はタイムアウト）で、最大５回の再送です
（ＵＤＰの場合）。加算的あるいは指数関数的に再送間隔を増やすのが合
理的と思われます。
3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
ADCOUNT>=0. If ANCOUNT>0, then the answer section represents an
unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>. A
slave receiving such a hint is free to treat equivilence of this
answer section with its local data as a "no further work needs to be
done" indication. If ANCOUNT=0, or ANCOUNT>0 and the answer section
differs from the slave's local data, then the slave should query its
known masters to retrieve the new data.
3.7. 通知要求はQDCOUNT>0, ANCOUNT≧0, AUCOUNT≧0, ADCOUNT≧0です。も
しANCOUNT>0なら、解答セクションで＜質問名、質問クラス、質問タイプ＞の
新しい資源レコード集合の無保証のヒントを表します。このようなヒントを
受け取ったスレーブが解答セクションとローカルデータを比較し「これ以上
仕事は必要ない」と示すのは自由です。もしANCOUNT=0かANCOUNT>0で解答セ
クションとスレーブのローカルデータが違うなら、スレーブは新しいデータ
を得るためにその既知のマスターに問合せるべきです。
3.8. In no case shall the answer section of a NOTIFY request be used
to update a slave's local data, or to indicate that a zone transfer
needs to be undertaken, or to change the slave's zone refresh timers.
Only a "data present; data same" condition can lead a slave to act
differently if ANCOUNT>0 than it would if ANCOUNT=0.
3.8. 通知要求の解答セクションのデータでスレーブのローカルデータを修正
したり、直ちにゾーン転送を開始したり、スレーブのソーンリフレッシュタ
イマーを変えたりすべきではありません。ANCOUNT>0で「データあり；データ
一致」の場合にのみスレーブはANCOUNT=0の場合を行動を変更できます。
3.9. This version of the NOTIFY specification makes no use of the
authority or additional data sections, and so conforming
implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting
requests. Since a future revision of this specification may define a
backwards compatible use for either or both of these sections,
current implementations must ignore these sections, but not the
entire message, if AUCOUNT>0 and/or ADCOUNT>0.
3.9. 通知仕様のこの版は権威セクションと追加データセクションを使用しま
せん、従順な実装は要求を伝送する際にAUCOUNT=0とADCOUNT=0を設定するべ
きです。この仕様書の未来版が現在の版と共存した形でどちらかのセクショ
ンを使うかもしれません、現在の版はAUCOUNT>0かADCOUNT>0の場合両セク
ションを無視すべきです。
3.10. If a slave receives a NOTIFY request from a host that is not a
known master for the zone containing the QNAME, it should ignore the
request and produce an error message in its operations log.
3.10. もしスレーブが質問名を含むゾーンの既知の周知のマスター以外から
通知要求を受取るなら、要求を無視しオペレーションログにエラーメッセー
ジを作るべきです。
Note:
This implies that slaves of a multihomed master must either know
their master by the "closest" of the master's interface
addresses, or must know all of the master's interface addresses.
Otherwise, a valid NOTIFY request might come from an address
that is not on the slave's state list of masters for the zone,
which would be an error.
注意：
これはマルチホームのマスターのスレーブがマスターの「最も近い」イン
タフェースアドレスか、マスターの全てのインタフェースアドレス知らな
ければならないことを意味します。そうでなければ正当な通知要求が、ス
レーブのリストに載っていないアドレスから来るので、これはエラーで
しょう。
3.11. The only defined NOTIFY event at this time is that the SOA RR
has changed. Upon completion of a NOTIFY transaction for QTYPE=SOA,
the slave should behave as though the zone given in the QNAME had
reached its REFRESH interval (see [RFC1035]), i.e., it should query
its masters for the SOA of the zone given in the NOTIFY QNAME, and
check the answer to see if the SOA SERIAL has been incremented since
the last time the zone was fetched. If so, a zone transfer (either
AXFR or IXFR) should be initiated.
3.11. 現在唯一の定義された通知イベントはSOA資源レコードの変化です。質
問タイプ＝SOAの通知処理が完了すると、スレーブは質問名で与えられたゾー
ンのリフレッシュ時間に達したと考えるべきです（[RFC1035]参照）、すなわ
ち、通知の質問名で与えられたゾーンのSOAについてマスターに質問し、SOA
シリアル番号が増加してるか確認するべきです。もし増加してればゾーン転
送（AXFRかIXFR）が始められるべきです。
Note:
Because a deep server dependency graph may have multiple paths
from the primary master to any given slave, it is possible that
a slave will receive a NOTIFY from one of its known masters even
though the rest of its known masters have not yet updated their
copies of the zone. Therefore, when issuing a QUERY for the
zone's SOA, the query should be directed at the known master who
was the source of the NOTIFY event, and not at any of the other
known masters. This represents a departure from [RFC1035],
which specifies that upon expiry of the SOA REFRESH interval,
all known masters should be queried in turn.
注意：
深いサーバー依存グラフではプライマリマスターからあるスレーブまで複
数のパスがあるかもしれないため、スレーブがあるマスターから通知を受
取ったが、他のマスターはまだゾーンデータを更新していないかもしれま
せん。それ故、ゾーンのSOAの質問は通知イベントを行ったマスターすべ
きで、他のマスターにすべきではありません。これは[RFC1035]からの変
更で、[RFC1035]はSOAリフレッシュ間隔の終了後、すべての周知のマスター
に順に質問をすべきことを明示します。
3.12. If a NOTIFY request is received by a slave who does not
implement the NOTIFY opcode, it will respond with a NOTIMP
(unimplemented feature error) message. A master server who receives
such a NOTIMP should consider the NOTIFY transaction complete for
that slave.
3.12. もし通知オペコードを実装しないスレーブが通知要求を受取ったら、
未実装（実装していない機能エラー）を返すでしょう。未実装を受取るマス
ターはスレーブに対する通知処理が完了したと思うべきです。
4. Details and Examples
4. 詳細と例
4.1. Retaining query state information across host reboots is
optional, but it is reasonable to simply execute an SOA NOTIFY
transaction on each authority zone when a server first starts.
4.1. ホスト再起動時に問合せ状態情報を維持するのは任意ですが、サーバ
が起動時に各正式なゾーンに対してSOA通知処理を実行するのが合理的です。
4.2. Each slave is likely to receive several copies of the same
NOTIFY request: One from the primary master, and one from each other
slave as that slave transfers the new zone and notifies its potential
peers. The NOTIFY protocol supports this multiplicity by requiring
that NOTIFY be sent by a slave/master only AFTER it has updated the
SOA RR or has determined that no update is necessary, which in
practice means after a successful zone transfer. Thus, barring
delivery reordering, the last NOTIFY any slave receives will be the
one indicating the latest change. Since a slave always requests SOAs
and AXFR/IXFRs only from its known masters, it will have an
opportunity to retry its QUERY for the SOA after each of its masters
have completed each zone update.
4.2. 各スレーブが同じ要求のいくつかのコピーを受け取る可能性が高いで
す：１つがプライマリマスターからで、他が新しいゾーンを受取ったスレー
ブからの自分の相手になる可能性のある者に対する通知です。通知プロトコ
ルは、SOA資源レコードを更新したか、更新が必要ではないと決定した後にだ
け、スレーブ／マスターから送らることを要求するので、この多数のメッ
セージを許します、これは実際はゾーン転送の成功を意味します。それで、
最小を要求する場合を除き、スレーブの受け取る最後の通知は最近の変更を
示すものでしょう。スレーブが常に既知のマスターからだけSOAとAXFR/IXFR
を求めるので、マスターがゾーン更新を完了した後に再びSOAを問合せる機会
になるでしょう。
4.3. If a master server seeks to avoid causing a large number of
simultaneous outbound zone transfers, it may delay for an arbitrary
length of time before sending a NOTIFY message to any given slave.
It is expected that the time will be chosen at random, so that each
slave will begin its transfer at a unique time. The delay shall not
in any case be longer than the SOA REFRESH time.
4.3. もしマスターサーバーが多数の同時のゾーン転送の発生を避けたければ、
スレーブに通知メッセージを送るのを任意の時間遅らせるかもしれません。
時間はランダムに選択されると思われます、それで各スレーブが異なる時間
にゾーン転送を始めるでしょう。通知の遅れはSOAリフレッシュ時間より長く
なるべきではありません。
Note:
This delay should be a parameter that each primary master name
server can specify, perhaps on a per-zone basis. Random delays
of between 30 and 60 seconds would seem adequate if the servers
share a LAN and the zones are of moderate size.
注意：
この遅延は各プライマリマスターネームサーバーで、多分ゾーン毎に、設
定できるパラメータであるべきです。サーバがＬＡＮを共有し、ゾーンが
中ぐらいの大きさの場合、３０秒から６０秒の間が適切でしょう。
4.4. A slave which receives a valid NOTIFY should defer action on any
subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
completed the transaction begun by the first NOTIFY. This duplicate
rejection is necessary to avoid having multiple notifications lead to
pummeling the master server.
4.4. 正当な通知を受け取るスレーブが、最初の通知で始まった処理を完了す
るまで、同じ＜質問名、質問クラス、質問タイプ＞を持つ次の通知の処理を
延期すべきです。この重複拒絶は多数の通知がマスターサーバに負荷がかか
るのを避けるために必要です。
4.5 Zone has Updated on Primary Master
4.5 プライマリマスターでのゾーンの更新
Primary master sends a NOTIFY request to all servers named in Notify
Set. The NOTIFY request has the following characteristics:
プライマリマスターが通知セットの示す全てのサーバに通知要求を送ります。
通知要求は次の特徴を持ちます：。
query ID: (new)
op: NOTIFY (4)
resp: NOERROR
flags: AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
4.6 Zone has Updated on a Slave that is also a Master
4.6 マスターでもあるスレーブのゾーンの更新
As above in 4.5, except that this server's Notify Set may be
different from the Primary Master's due to optional static
specification of local stealth servers.
サーバの通知セットがオプションの静的に設定したローカルステルスサーバ
分だけ異なるのを除き、上記４.５と同じです。
4.7 Slave Receives a NOTIFY Request from a Master
4.7 マスターから通知を受取ったスレーブ
When a slave server receives a NOTIFY request from one of its locally
designated masters for the zone enclosing the given QNAME, with
QTYPE=SOA and QR=0, it should enter the state it would if the zone's
refresh timer had expired. It will also send a NOTIFY response back
to the NOTIFY request's source, with the following characteristics:
スレーブサーバーが、ローカルに決めたゾーンのサーバから規定された質問
名で質問タイプがSOAでQR=0の通知メッセージを受信したら、ソーンリフレッ
シュ状態に入るべきです。そして通知生成源に次の様な通知応答を送るで
しょう：
query ID: (same)
op: NOTIFY (4)
resp: NOERROR
flags: QR AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
This is intended to be identical to the NOTIFY request, except that
the QR bit is also set. The query ID of the response must be the
same as was received in the request.
これはQRビットが設定されている以外、通知要求と同じであるように意図さ
れます。応答の質問ＩＤは要求で受け取ったのと同じに違いありません。
4.8 Master Receives a NOTIFY Response from Slave
4.8 スレーブから通知応答を受取ったマスター
When a master server receives a NOTIFY response, it deletes this
query from the retry queue, thus completing the "notification
process" of "this" RRset change to "that" server.
マスターサーバが通知応答を受取ったら、再送キューから要求を取り除き、
「この」資源レコードの変更に関する「この」サーバに対する「通知処理」
を終えます。
5. Security Considerations
5. セキュリティの考察
We believe that the NOTIFY operation's only security considerations
are:
我々は通知オペレーションのセキュリティ考慮が以下だけと信じます：
1. That a NOTIFY request with a forged IP/UDP source address can
cause a slave to send spurious SOA queries to its masters,
leading to a benign denial of service attack if the forged
requests are sent very often.
1. 偽造されたIP/UDPソースアドレスの通知要求はスレーブからマスターへの
SOAの問合せを生成するので、もし偽造要求が非常に多いとサービス否認
攻撃を導きます。
2. That TCP spoofing could be used against a slave server given
NOTIFY as a means of synchronizing an SOA query and UDP/DNS
spoofing as a means of forcing a zone transfer.
2. 通知を与えられたスレーブに対し、SOA同期の問合せに対してTCPスプーフ
（だまし）が使え、UDP/DNSスプーフ（だまし）がゾーン転送を強制する
ことに使えます。
6. References
6. 参考文献
[RFC1035]
Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[IXFR]
Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
7. Author's Address
7. 著者のアドレス
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
Phone: +1 415 747 0204
EMail: paul@vix.com