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


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
                         DNS逐次的ゾーン転送

Status of this Memo
この文書の状態



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

Abstract
概要

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

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].
   DNSデータベース[STD13]に対する変更の速い普及のために、サーバーに能
   動的に変更を通知し遅れを減らすことが必要です。これはDNSの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.
   この文書でIXFRを要求するセカンダリネームサーバをIXFRクライア
   ントと呼び、要求にこたえるプライマリかセカンダリネームサーバをIXF
   Rサーバを呼びます。


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.
   もし古い版のゾーンをもつIXFRクライアントがゾーンの新しい版を得よ
   うとしたとき(多分SOA更新タイムアウトかNOTIFYメカニズムで)、クライア
   ントは多分ソーンの古いコピーの、SOAシリアル番号を含むIXFRメッセー
   ジを送ります。

   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.
   IXFRサーバーがゾーンの最新版といくつかの古い版からの差分レコード
   を保持するべきです。古い版数のIXFR要求を受けたときにIXFRサー
   バーはその版と現在の版の差分だけを送る必要があります。代わりにサーバ
   は標準完全ゾーン転送のように全部のゾーンを移すことに決めてもよいです。

   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.
   ゾーンが最新にされた時、サーバは新しい版をIXFR(あるいはAXFR)
   で使う前に安定した記憶装置に保存すべきです。さもなければ、もしサーバー
   がクラッシュした時、もう使えないデータがセカンダリサーバーに配られて
   しまったかもしれなく、これは持続的なデータベース矛盾を起こすことがあ
   ります。

   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.
   もしサーバと同じか新しい版のIXFR要求が来たら、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.
   要求はUDPを使うかもTCPを使うかもしれません。もしIXFR要求が
   UDPで行われるなら、IXFRサーバは全部の回答がひとつのDNSパケッ
   トに載るならばUDPで返事を試みてもよいです。もしUDPに答えが載ら
   ないならクライアントにTCPを使うべきことを知らせるた現在の版のSO
   Aレコードだけが返されます。

   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.
   このためクライアントは最初IXFRの問合せにUDPを使うようにするべ
   きです。もし問合せタイプがサーバーで認識されないなら、AXFR(UD
   PのSOA問合せより優先)が逆方向互換性を保証するため試みられるべき
   です。もし問合せ回答が全部の新しいゾーンを持つひとつのパケットか、も
   しサーバーがクライアントより新しい版を持っていないなら、すべてが終わ
   ります。そうでなければTCPでIXFR問合せがされるべきです。

   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.
   完全性を保証するために、サーバーがすべてのUDP回答にUDPチェック
   サムを使うべきです。チェックサムがゼロのUDPパケットを受け取る用心
   深いクライアントが結果を無視し、代わりにTCPのIXFRを試みるべき
   です。

   The query type value of IXFR assigned by IANA is 251.
   IANAの割り当てたIXFR質問タイプ値は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.
   IXFR問合せパケットフォーマットは標準DNS問合せと同じだが、問合
   せタイプがIXFRで権威セクションのクライアントの持つゾーンの版のS
   OAレコードを含みます。


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.
   もし逐次的ゾーン転送が利用可能ではないなら全部のゾーンが返されます。
   最初と最後の回答の資源レコードはゾーンのSOAレコードです。すなわち
   動作は質問タイプがIXFRである以外のAXFR回答と同じです。

   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つ以上の差分列が返されます。差
   分列のリストはサーバの現在の版のSOAで始まりSOAで終わります。

   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.
   各差分列がゾーンの1つの更新を表現し(1つのSOAシリアルの変更)削
   除した資源レコードと追加した資源レコードを含みます。削除される資源レ
   コードの最初の最初の資源レコードは古いSOA資源レコードで、追加され
   る最初の資源レコードは新しいSOA資源レコードです。

   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.
   差分情報列は、古いのから新しいものの順です。つまり差分情報列はIXF
   Rクライアントの知って津版から現在の版までの変更履歴です。

   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.
   逐次的転送メッセージの資源レコードは部分的かもしれません。つまり、も
   し同じ資源タイプの複数の資源レコード1つだけが変更になったら、変更に
   なった資源レコードだけが送られます。

   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.
   逐次的応答と逐次的でない応答は、逐次的応答が2つのSOAから始まる事
   で異なっています、2つのSOAはサーバの現在のSOAとクライアントの
   版のSOAです。

   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.
   IXFRサーバーが永久にすべての前の版を持つ必要はなく、いつでもそれ
   らを削除してもよいです。一般に、記憶スペースの大きさと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.
   もっとも古い版の情報が、もしIXFR回答全体の長さがAXFR回答の長
   さより長いなら削除されるべきです。IXFRの目的がAXFRのオーバー
   ヘッドを減らすことならば、この戦略は非常に合理的です。この戦略は必要
   な記憶スペースが現在のゾーン情報の2倍程度なことを保障します。

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

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.
   IXFRサーバーがオプションで、複数の変更を要約し、途中の版の情報を
   削除してもよいです。

   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サーバーがひとつのDNS名
   を共有し、名前と関連するIPアドレスが負荷分散のために1分毎に変更に
   なるならば、変更のすべての履歴を記録・追跡することはそれほど重要では
   ありません。

   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.
   しかしこの機能はIXFRクライアントが2つのIXFRサーバーにアクセ
   スするなら有用でないかもしれません:AとBが矛盾する要約を持つ。IX
   FRクライアントの現在の版は、サーバーAから受け取られて、サーバーB
   に未知であるかもしれません。このような場合、サーバーBが未知の版から
   逐次的なデータを供給することができず、完全なゾーン転送が必要です。

   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.
   互換性のために、要約機能を含まないIXFRサーバーは、たとえ未知の版
   数でクライアントのIXFRリクエストを受け取ても、エラーを返すべきで
   はなく、代わりに完全ゾーン転送を行おうと試みるべきです。

7. Example
7. 例

   Given the following three generations of data with the current serial
   number of 3,
   3世代のデータがあり、現在のシリアル番号が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.のIPアドレスの1つが変更になった

      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
   次のIXFR問合せに対して

                 +---------------------------------------------------+
      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:
   次の完全ゾーン転送メッセージで答えることができる:


                 +---------------------------------------------------+
      Header     | OPCODE=SQUERY, RESPONSE                           |
                 +---------------------------------------------------+
      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
                 +---------------------------------------------------+
      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
                 | JAIN.AD.JP.         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           |
                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
                 | JAIN.AD.JP.         IN SOA serial=3               |
                 +---------------------------------------------------+
      Authority  | <empty>                                           |
                 +---------------------------------------------------+
      Additional | <empty>                                           |
                 +---------------------------------------------------+

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

                 +---------------------------------------------------+
      Header     | OPCODE=SQUERY, RESPONSE                           |
                 +---------------------------------------------------+
      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
                 +---------------------------------------------------+
      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
                 | JAIN.AD.JP.         IN SOA serial=1               |
                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
                 | JAIN.AD.JP.         IN SOA serial=2               |
                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
                 | JAIN.AD.JP.         IN SOA serial=2               |
                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
                 | JAIN.AD.JP.         IN SOA serial=3               |
                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
                 | JAIN.AD.JP.         IN SOA serial=3               |
                 +---------------------------------------------------+
      Authority  | <empty>                                           |
                 +---------------------------------------------------+
      Additional | <empty>                                           |
                 +---------------------------------------------------+

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

                 +---------------------------------------------------+
      Header     | OPCODE=SQUERY, RESPONSE                           |
                 +---------------------------------------------------+
      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
                 +---------------------------------------------------+
      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
                 | JAIN.AD.JP.         IN SOA serial=1               |
                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
                 | JAIN.AD.JP.         IN SOA serial=3               |
                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
                 | JAIN.AD.JP.         IN SOA serial=3               |
                 +---------------------------------------------------+
      Authority  | <empty>                                           |
                 +---------------------------------------------------+
      Additional | <empty>                                           |
                 +---------------------------------------------------+

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


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

8. Acknowledgements
8. 謝辞

   The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
   and Jon Postel.
   IXFRの元々の考えは 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 とIETFのDNSI
   NDワークグループのメンバーやその他の人が寄与しています。


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.
   DNSがいくつかのセキュリティ問題と関係があるがこの文書はそれらを直
   す試みがされません。

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

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