ＤＮＳ逐次的ゾーン転送

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

Network Working Group M. Ohta
Request for Comments: 1995 Tokyo Institute of Technology
Updates: 1035 August 1996
Category: Standards Track

Incremental Zone Transfer in DNS
ＤＮＳ逐次的ゾーン転送

Status of this Memo
この文書の状態

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。

Abstract
概要

This document proposes extensions to the DNS protocols to provide an
incremental zone transfer (IXFR) mechanism.
このドキュメントは逐次的ゾーン転送（IXFR）機構を供給するためにＤＮＳ
プロトコルへの拡張を提案します。

1. Introduction
1. はじめに

For rapid propagation of changes to a DNS database [STD13], it is
necessary to reduce latency by actively notifying servers of the
change. This is accomplished by the NOTIFY extension of the DNS
[NOTIFY].
ＤＮＳデータベース[STD13]に対する変更の速い普及のために、サーバーに能
動的に変更を通知し遅れを減らすことが必要です。これはＤＮＳのNOTIFY拡
張［NOTIFY］で達成できます。

The current full zone transfer mechanism (AXFR) is not an efficient
means to propagate changes to a small part of a zone, as it transfers
the entire zone file.
現在の完全ゾーン転送メカニズム（AXFR）は、全部のゾーンファイルを転送
するので、ゾーンの小さな部分に対する変更を伝える効率的な手段ではあり
ません。

Incremental transfer (IXFR) as proposed is a more efficient
mechanism, as it transfers only the changed portion(s) of a zone.
提案された逐次的転送（IXFR）が、ゾーンの変更部分だけを移すのでより効
率的なメカニズムです。

In this document, a secondary name server which requests IXFR is
called an IXFR client and a primary or secondary name server which
responds to the request is called an IXFR server.
この文書でＩＸＦＲを要求するセカンダリネームサーバをＩＸＦＲクライア
ントと呼び、要求にこたえるプライマリかセカンダリネームサーバをＩＸＦ
Ｒサーバを呼びます。

2. Brief Description of the Protocol
2. プロトコルの短い記述

If an IXFR client, which likely has an older version of a zone,
thinks it needs new information about the zone (typically through SOA
refresh timeout or the NOTIFY mechanism), it sends an IXFR message
containing the SOA serial number of its, presumably outdated, copy of
the zone.
もし古い版のゾーンをもつＩＸＦＲクライアントがゾーンの新しい版を得よ
うとしたとき（多分SOA更新タイムアウトかNOTIFYメカニズムで）、クライア
ントは多分ソーンの古いコピーの、SOAシリアル番号を含むＩＸＦＲメッセー
ジを送ります。

An IXFR server should keep record of the newest version of the zone
and the differences between that copy and several older versions.
When an IXFR request with an older version number is received, the

IXFR server needs to send only the differences required to make that
version current. Alternatively, the server may choose to transfer
the entire zone just as in a normal full zone transfer.
ＩＸＦＲサーバーがゾーンの最新版といくつかの古い版からの差分レコード
を保持するべきです。古い版数のＩＸＦＲ要求を受けたときにＩＸＦＲサー
バーはその版と現在の版の差分だけを送る必要があります。代わりにサーバ
は標準完全ゾーン転送のように全部のゾーンを移すことに決めてもよいです。

When a zone has been updated, it should be saved in stable storage
before the new version is used to respond to IXFR (or AXFR) queries.
Otherwise, if the server crashes, data which is no longer available
may have been distributed to secondary servers, which can cause
persistent database inconsistencies.
ゾーンが最新にされた時、サーバは新しい版をＩＸＦＲ（あるいはＡＸＦＲ）
で使う前に安定した記憶装置に保存すべきです。さもなければ、もしサーバー
がクラッシュした時、もう使えないデータがセカンダリサーバーに配られて
しまったかもしれなく、これは持続的なデータベース矛盾を起こすことがあ
ります。

If an IXFR query with the same or newer version number than that of
the server is received, it is replied to with a single SOA record of
the server's current version, just as in AXFR.
もしサーバと同じか新しい版のＩＸＦＲ要求が来たら、ＡＸＦＲ同様に、サー
バーの現在のSOAレコードだけを返します。

Transport of a query may be by either UDP or TCP. If an IXFR query
is via UDP, the IXFR server may attempt to reply using UDP if the
entire response can be contained in a single DNS packet. If the UDP
reply does not fit, the query is responded to with a single SOA
record of the server's current version to inform the client that a
TCP query should be initiated.
要求はＵＤＰを使うかもＴＣＰを使うかもしれません。もしＩＸＦＲ要求が
ＵＤＰで行われるなら、ＩＸＦＲサーバは全部の回答がひとつのＤＮＳパケッ
トに載るならばＵＤＰで返事を試みてもよいです。もしＵＤＰに答えが載ら
ないならクライアントにＴＣＰを使うべきことを知らせるた現在の版のＳＯ
Ａレコードだけが返されます。

Thus, a client should first make an IXFR query using UDP. If the
query type is not recognized by the server, an AXFR (preceded by a
UDP SOA query) should be tried, ensuring backward compatibility. If
the query response is a single packet with the entire new zone, or if
the server does not have a newer version than the client, everything
is done. Otherwise, a TCP IXFR query should be tried.
このためクライアントは最初ＩＸＦＲの問合せにＵＤＰを使うようにするべ
きです。もし問合せタイプがサーバーで認識されないなら、ＡＸＦＲ（ＵＤ
ＰのＳＯＡ問合せより優先）が逆方向互換性を保証するため試みられるべき
です。もし問合せ回答が全部の新しいゾーンを持つひとつのパケットか、も
しサーバーがクライアントより新しい版を持っていないなら、すべてが終わ
ります。そうでなければＴＣＰでＩＸＦＲ問合せがされるべきです。

To ensure integrity, servers should use UDP checksums for all UDP
responses. A cautious client which receives a UDP packet with a
checksum value of zero should ignore the result and try a TCP IXFR
instead.
完全性を保証するために、サーバーがすべてのＵＤＰ回答にＵＤＰチェック
サムを使うべきです。チェックサムがゼロのＵＤＰパケットを受け取る用心
深いクライアントが結果を無視し、代わりにＴＣＰのＩＸＦＲを試みるべき
です。

The query type value of IXFR assigned by IANA is 251.
ＩＡＮＡの割り当てたＩＸＦＲ質問タイプ値は２５１です。

3. Query Format
3. 問い合わせフォーマット

The IXFR query packet format is the same as that of a normal DNS
query, but with the query type being IXFR and the authority section
containing the SOA record of client's version of the zone.
ＩＸＦＲ問合せパケットフォーマットは標準ＤＮＳ問合せと同じだが、問合
せタイプがＩＸＦＲで権威セクションのクライアントの持つゾーンの版のＳ
ＯＡレコードを含みます。

4. Response Format
4. 応答フォーマット

If incremental zone transfer is not available, the entire zone is
returned. The first and the last RR of the response is the SOA
record of the zone. I.e. the behavior is the same as an AXFR
response except the query type is IXFR.
もし逐次的ゾーン転送が利用可能ではないなら全部のゾーンが返されます。
最初と最後の回答の資源レコードはゾーンのＳＯＡレコードです。すなわち
動作は質問タイプがＩＸＦＲである以外のＡＸＦＲ回答と同じです。

If incremental zone transfer is available, one or more difference
sequences is returned. The list of difference sequences is preceded
and followed by a copy of the server's current version of the SOA.
もし逐次的ゾーン転送が利用可能でなら、1つ以上の差分列が返されます。差
分列のリストはサーバの現在の版のＳＯＡで始まりＳＯＡで終わります。

Each difference sequence represents one update to the zone (one SOA
serial change) consisting of deleted RRs and added RRs. The first RR
of the deleted RRs is the older SOA RR and the first RR of the added
RRs is the newer SOA RR.
各差分列がゾーンの１つの更新を表現し（１つのＳＯＡシリアルの変更）削
除した資源レコードと追加した資源レコードを含みます。削除される資源レ
コードの最初の最初の資源レコードは古いＳＯＡ資源レコードで、追加され
る最初の資源レコードは新しいＳＯＡ資源レコードです。

Modification of an RR is performed first by removing the original RR
and then adding the modified one.

資源レコードの修正は元の資源レコードを削除し、次に修正した資源レコー
ドを追加することで行われます。

The sequences of differential information are ordered oldest first
newest last. Thus, the differential sequences are the history of
changes made since the version known by the IXFR client up to the
server's current version.
差分情報列は、古いのから新しいものの順です。つまり差分情報列はＩＸＦ
Ｒクライアントの知って津版から現在の版までの変更履歴です。

RRs in the incremental transfer messages may be partial. That is, if
a single RR of multiple RRs of the same RR type changes, only the
changed RR is transferred.
逐次的転送メッセージの資源レコードは部分的かもしれません。つまり、も
し同じ資源タイプの複数の資源レコード１つだけが変更になったら、変更に
なった資源レコードだけが送られます。

An IXFR client, should only replace an older version with a newer
version after all the differences have been successfully processed.
IXFRクライアントはすべての差分が正しく処理された後で、古い版と新しい
版を置き換えるだけにすべきです。

An incremental response is different from that of a non-incremental
response in that it begins with two SOA RRs, the server's current SOA
followed by the SOA of the client's version which is about to be
replaced.
逐次的応答と逐次的でない応答は、逐次的応答が２つのＳＯＡから始まる事
で異なっています、２つのＳＯＡはサーバの現在のＳＯＡとクライアントの
版のＳＯＡです。

5. Purging Strategy
5. 削除戦略

An IXFR server can not be required to hold all previous versions
forever and may delete them anytime. In general, there is a trade-off
between the size of storage space and the possibility of using IXFR.
ＩＸＦＲサーバーが永久にすべての前の版を持つ必要はなく、いつでもそれ
らを削除してもよいです。一般に、記憶スペースの大きさとＩＸＦＲの利用
可能性の間にトレードオフがあります。

Information about older versions should be purged if the total length
of an IXFR response would be longer than that of an AXFR response.
Given that the purpose of IXFR is to reduce AXFR overhead, this
strategy is quite reasonable. The strategy assures that the amount
of storage required is at most twice that of the current zone
information.
もっとも古い版の情報が、もしＩＸＦＲ回答全体の長さがＡＸＦＲ回答の長
さより長いなら削除されるべきです。ＩＸＦＲの目的がＡＸＦＲのオーバー
ヘッドを減らすことならば、この戦略は非常に合理的です。この戦略は必要
な記憶スペースが現在のゾーン情報の２倍程度なことを保障します。

Information older than the SOA expire period may also be purged.
期限切れのＳＯＡを持つ古い情報が同じく削除されるかもしれません。

6. Optional Condensation of Multiple Versions
6. 多数の版の任意の要約

An IXFR server may optionally condense multiple difference sequences
into a single difference sequence, thus, dropping information on
intermediate versions.
ＩＸＦＲサーバーがオプションで、複数の変更を要約し、途中の版の情報を
削除してもよいです。

This may be beneficial if a lot of versions, not all of which are
useful, are generated. For example, if multiple ftp servers share a
single DNS name and the IP address associated with the name is
changed once a minute to balance load between the ftp servers, it is
not so important to keep track of all the history of changes.
これは、もし多数の版が生成されるが、一部しか使われていないならば有益
であるかもしれません。例えば、もし多数のftpサーバーがひとつのＤＮＳ名
を共有し、名前と関連するＩＰアドレスが負荷分散のために１分毎に変更に
なるならば、変更のすべての履歴を記録・追跡することはそれほど重要では
ありません。

But, this feature may not be so useful if an IXFR client has access
to two IXFR servers: A and B, with inconsistent condensation results.
The current version of the IXFR client, received from server A, may
be unknown to server B. In such a case, server B can not provide
incremental data from the unknown version and a full zone transfer is
necessary.
しかしこの機能はＩＸＦＲクライアントが２つのＩＸＦＲサーバーにアクセ
スするなら有用でないかもしれません：ＡとＢが矛盾する要約を持つ。ＩＸ
ＦＲクライアントの現在の版は、サーバーＡから受け取られて、サーバーＢ
に未知であるかもしれません。このような場合、サーバーＢが未知の版から
逐次的なデータを供給することができず、完全なゾーン転送が必要です。

Condensation is completely optional. Clients can't detect from the
response whether the server has condensed the reply or not.
要約は完全に任意です。クライアントが回答からサーバーの答えが要約かど
うか検出できません。

For interoperability, IXFR servers, including those without the
condensation feature, should not flag an error even if it receives a
client's IXFR request with a unknown version number and should,
instead, attempt to perform a full zone transfer.
互換性のために、要約機能を含まないＩＸＦＲサーバーは、たとえ未知の版
数でクライアントのＩＸＦＲリクエストを受け取ても、エラーを返すべきで
はなく、代わりに完全ゾーン転送を行おうと試みるべきです。

7. Example
7. 例

Given the following three generations of data with the current serial
number of 3,
３世代のデータがあり、現在のシリアル番号が３だとします。

JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
1 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
NEZU.JAIN.AD.JP. IN A 133.69.136.5

NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
NEZU.JAIN.AD.JP.が削除されJAIN-BB.JAIN.AD.JP.が追加された

jain.ad.jp. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
2 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4
IN A 192.41.197.2

One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
JAIN-BB.JAIN.AD.JP.のＩＰアドレスの１つが変更になった

JAIN.AD.JP. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
3 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3
IN A 192.41.197.2

The following IXFR query
次のＩＸＦＲ問合せに対して

+---------------------------------------------------+
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=1 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+

could be replied to with the following full zone transfer message:
次の完全ゾーン転送メッセージで答えることができる：

or with the following incremental message:
次の逐次メッセージで答えることもできる：

or with the following condensed incremental message:
次の要約逐次メッセージで答えることも出来る：

or, if UDP packet overflow occurs, with the following message:
あるいはＵＤＰパケットが溢れるなら以下のメッセージで答えることもできます：

8. Acknowledgements
8. 謝辞

The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
and Jon Postel.
ＩＸＦＲの元々の考えは Anant KumarとSteve HotzとJon Postelによって考
え出されました。

For the refinement of the protocol and documentation, many people
have contributed including, but not limited to, Anant Kumar, Robert
Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the
members of the IETF DNSIND working group.
プロトコルと文書の改善のために、Anant KumarとRobert Austeinと
Paul VixieとRandy BushとMark AndrewsとRobert Elz とＩＥＴＦのＤＮＳＩ
ＮＤワークグループのメンバーやその他の人が寄与しています。

9. References
9. 参考文献

[NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt
Notification of Zone Changes", RFC 1996, August 1996.

[STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and
RFC 1035), November 1987.

10. Security Considerations
10. セキュリティの考慮

Though DNS is related to several security problems, no attempt is
made to fix them in this document.
ＤＮＳがいくつかのセキュリティ問題と関係があるがこの文書はそれらを直
す試みがされません。

This document is believed to introduce no additional security
problems to the current DNS protocol.
この文書は現在のＤＮＳプロトコルにセキュリティ問題を追加しないと信じ
られます。

11. Author's Address
11. 著者のアドレス

Masataka Ohta

Computer Center
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN

Phone: +81-3-5734-3299
Fax: +81-3-5734-3415
EMail: mohta@necom830.hpcl.titech.ac.jp

Japanese translation by Ishida So