home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1900s / rfc1995.txt < prev    next >
Text File  |  1996-08-22  |  17KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            M. Ohta
  8. Request for Comments: 1995                 Tokyo Institute of Technology
  9. Updates: 1035                                                August 1996
  10. Category: Standards Track
  11.  
  12.  
  13.                     Incremental Zone Transfer in DNS
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    This document proposes extensions to the DNS protocols to provide an
  26.    incremental zone transfer (IXFR) mechanism.
  27.  
  28. 1. Introduction
  29.  
  30.    For rapid propagation of changes to a DNS database [STD13], it is
  31.    necessary to reduce latency by actively notifying servers of the
  32.    change.  This is accomplished by the NOTIFY extension of the DNS
  33.    [NOTIFY].
  34.  
  35.    The current full zone transfer mechanism (AXFR) is not an efficient
  36.    means to propagate changes to a small part of a zone, as it transfers
  37.    the entire zone file.
  38.  
  39.    Incremental transfer (IXFR) as proposed is a more efficient
  40.    mechanism, as it transfers only the changed portion(s) of a zone.
  41.  
  42.    In this document, a secondary name server which requests IXFR is
  43.    called an IXFR client and a primary or secondary name server which
  44.    responds to the request is called an IXFR server.
  45.  
  46. 2. Brief Description of the Protocol
  47.  
  48.    If an IXFR client, which likely has an older version of a zone,
  49.    thinks it needs new information about the zone (typically through SOA
  50.    refresh timeout or the NOTIFY mechanism), it sends an IXFR message
  51.    containing the SOA serial number of its, presumably outdated, copy of
  52.    the zone.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Ohta                        Standards Track                     [Page 1]
  59.  
  60. RFC 1995            Incremental Zone Transfer in DNS         August 1996
  61.  
  62.  
  63.    An IXFR server should keep record of the newest version of the zone
  64.    and the differences between that copy and several older versions.
  65.    When an IXFR request with an older version number is received, the
  66.    IXFR server needs to send only the differences required to make that
  67.    version current.  Alternatively, the server may choose to transfer
  68.    the entire zone just as in a normal full zone transfer.
  69.  
  70.    When a zone has been updated, it should be saved in stable storage
  71.    before the new version is used to respond to IXFR (or AXFR) queries.
  72.    Otherwise, if the server crashes, data which is no longer available
  73.    may have been distributed to secondary servers, which can cause
  74.    persistent database inconsistencies.
  75.  
  76.    If an IXFR query with the same or newer version number than that of
  77.    the server is received, it is replied to with a single SOA record of
  78.    the server's current version, just as in AXFR.
  79.  
  80.    Transport of a query may be by either UDP or TCP.  If an IXFR query
  81.    is via UDP, the IXFR server may attempt to reply using UDP if the
  82.    entire response can be contained in a single DNS packet.  If the UDP
  83.    reply does not fit, the query is responded to with a single SOA
  84.    record of the server's current version to inform the client that a
  85.    TCP query should be initiated.
  86.  
  87.    Thus, a client should first make an IXFR query using UDP.  If the
  88.    query type is not recognized by the server, an AXFR (preceded by a
  89.    UDP SOA query) should be tried, ensuring backward compatibility.  If
  90.    the query response is a single packet with the entire new zone, or if
  91.    the server does not have a newer version than the client, everything
  92.    is done.  Otherwise, a TCP IXFR query should be tried.
  93.  
  94.    To ensure integrity, servers should use UDP checksums for all UDP
  95.    responses.  A cautious client which receives a UDP packet with a
  96.    checksum value of zero should ignore the result and try a TCP IXFR
  97.    instead.
  98.  
  99.    The query type value of IXFR assigned by IANA is 251.
  100.  
  101. 3. Query Format
  102.  
  103.    The IXFR query packet format is the same as that of a normal DNS
  104.    query, but with the query type being IXFR and the authority section
  105.    containing the SOA record of client's version of the zone.
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Ohta                        Standards Track                     [Page 2]
  115.  
  116. RFC 1995            Incremental Zone Transfer in DNS         August 1996
  117.  
  118.  
  119. 4. Response Format
  120.  
  121.    If incremental zone transfer is not available, the entire zone is
  122.    returned.  The first and the last RR of the response is the SOA
  123.    record of the zone.  I.e. the behavior is the same as an AXFR
  124.    response except the query type is IXFR.
  125.  
  126.    If incremental zone transfer is available, one or more difference
  127.    sequences is returned.  The list of difference sequences is preceded
  128.    and followed by a copy of the server's current version of the SOA.
  129.  
  130.    Each difference sequence represents one update to the zone (one SOA
  131.    serial change) consisting of deleted RRs and added RRs.  The first RR
  132.    of the deleted RRs is the older SOA RR and the first RR of the added
  133.    RRs is the newer SOA RR.
  134.  
  135.    Modification of an RR is performed first by removing the original RR
  136.    and then adding the modified one.
  137.  
  138.    The sequences of differential information are ordered oldest first
  139.    newest last.  Thus, the differential sequences are the history of
  140.    changes made since the version known by the IXFR client up to the
  141.    server's current version.
  142.  
  143.    RRs in the incremental transfer messages may be partial.  That is, if
  144.    a single RR of multiple RRs of the same RR type changes, only the
  145.    changed RR is transferred.
  146.  
  147.    An IXFR client, should only replace an older version with a newer
  148.    version after all the differences have been successfully processed.
  149.  
  150.    An incremental response is different from that of a non-incremental
  151.    response in that it begins with two SOA RRs, the server's current SOA
  152.    followed by the SOA of the client's version which is about to be
  153.    replaced.
  154.  
  155.    5. Purging Strategy
  156.  
  157.    An IXFR server can not be required to hold all previous versions
  158.    forever and may delete them anytime. In general, there is a trade-off
  159.    between the size of storage space and the possibility of using IXFR.
  160.  
  161.    Information about older versions should be purged if the total length
  162.    of an IXFR response would be longer than that of an AXFR response.
  163.    Given that the purpose of IXFR is to reduce AXFR overhead, this
  164.    strategy is quite reasonable.  The strategy assures that the amount
  165.    of storage required is at most twice that of the current zone
  166.    information.
  167.  
  168.  
  169.  
  170. Ohta                        Standards Track                     [Page 3]
  171.  
  172. RFC 1995            Incremental Zone Transfer in DNS         August 1996
  173.  
  174.  
  175.    Information older than the SOA expire period may also be purged.
  176.  
  177. 6. Optional Condensation of Multiple Versions
  178.  
  179.    An IXFR server may optionally condense multiple difference sequences
  180.    into a single difference sequence, thus, dropping information on
  181.    intermediate versions.
  182.  
  183.    This may be beneficial if a lot of versions, not all of which are
  184.    useful, are generated. For example, if multiple ftp servers share a
  185.    single DNS name and the IP address associated with the name is
  186.    changed once a minute to balance load between the ftp servers, it is
  187.    not so important to keep track of all the history of changes.
  188.  
  189.    But, this feature may not be so useful if an IXFR client has access
  190.    to two IXFR servers: A and B, with inconsistent condensation results.
  191.    The current version of the IXFR client, received from server A, may
  192.    be unknown to server B. In such a case, server B can not provide
  193.    incremental data from the unknown version and a full zone transfer is
  194.    necessary.
  195.  
  196.    Condensation is completely optional. Clients can't detect from the
  197.    response whether the server has condensed the reply or not.
  198.  
  199.    For interoperability, IXFR servers, including those without the
  200.    condensation feature, should not flag an error even if it receives a
  201.    client's IXFR request with a unknown version number and should,
  202.    instead, attempt to perform a full zone transfer.
  203.  
  204. 7. Example
  205.  
  206.    Given the following three generations of data with the current serial
  207.    number of 3,
  208.  
  209.       JAIN.AD.JP.         IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
  210.                                         1 600 600 3600000 604800)
  211.                           IN NS  NS.JAIN.AD.JP.
  212.       NS.JAIN.AD.JP.      IN A   133.69.136.1
  213.       NEZU.JAIN.AD.JP.    IN A   133.69.136.5
  214.  
  215.    NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
  216.  
  217.       jain.ad.jp.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
  218.                                         2 600 600 3600000 604800)
  219.                           IN NS  NS.JAIN.AD.JP.
  220.       NS.JAIN.AD.JP.      IN A   133.69.136.1
  221.       JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4
  222.                           IN A   192.41.197.2
  223.  
  224.  
  225.  
  226. Ohta                        Standards Track                     [Page 4]
  227.  
  228. RFC 1995            Incremental Zone Transfer in DNS         August 1996
  229.  
  230.  
  231.    One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
  232.  
  233.       JAIN.AD.JP.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
  234.                                         3 600 600 3600000 604800)
  235.                           IN NS  NS.JAIN.AD.JP.
  236.       NS.JAIN.AD.JP.      IN A   133.69.136.1
  237.       JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3
  238.                           IN A   192.41.197.2
  239.  
  240.    The following IXFR query
  241.  
  242.                  +---------------------------------------------------+
  243.       Header     | OPCODE=SQUERY                                     |
  244.                  +---------------------------------------------------+
  245.       Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
  246.                  +---------------------------------------------------+
  247.       Answer     | <empty>                                           |
  248.                  +---------------------------------------------------+
  249.       Authority  | JAIN.AD.JP.         IN SOA serial=1               |
  250.                  +---------------------------------------------------+
  251.       Additional | <empty>                                           |
  252.                  +---------------------------------------------------+
  253.  
  254.    could be replied to with the following full zone transfer message:
  255.  
  256.                  +---------------------------------------------------+
  257.       Header     | OPCODE=SQUERY, RESPONSE                           |
  258.                  +---------------------------------------------------+
  259.       Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
  260.                  +---------------------------------------------------+
  261.       Answer     | JAIN.AD.JP.         IN SOA serial=3               |
  262.                  | JAIN.AD.JP.         IN NS  NS.JAIN.AD.JP.         |
  263.                  | NS.JAIN.AD.JP.      IN A   133.69.136.1           |
  264.                  | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
  265.                  | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
  266.                  | JAIN.AD.JP.         IN SOA serial=3               |
  267.                  +---------------------------------------------------+
  268.       Authority  | <empty>                                           |
  269.                  +---------------------------------------------------+
  270.       Additional | <empty>                                           |
  271.                  +---------------------------------------------------+
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Ohta                        Standards Track                     [Page 5]
  283.  
  284. RFC 1995            Incremental Zone Transfer in DNS         August 1996
  285.  
  286.  
  287.    or with the following incremental message:
  288.  
  289.                  +---------------------------------------------------+
  290.       Header     | OPCODE=SQUERY, RESPONSE                           |
  291.                  +---------------------------------------------------+
  292.       Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
  293.                  +---------------------------------------------------+
  294.       Answer     | JAIN.AD.JP.         IN SOA serial=3               |
  295.                  | JAIN.AD.JP.         IN SOA serial=1               |
  296.                  | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
  297.                  | JAIN.AD.JP.         IN SOA serial=2               |
  298.                  | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
  299.                  | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
  300.                  | JAIN.AD.JP.         IN SOA serial=2               |
  301.                  | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
  302.                  | JAIN.AD.JP.         IN SOA serial=3               |
  303.                  | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
  304.                  | JAIN.AD.JP.         IN SOA serial=3               |
  305.                  +---------------------------------------------------+
  306.       Authority  | <empty>                                           |
  307.                  +---------------------------------------------------+
  308.       Additional | <empty>                                           |
  309.                  +---------------------------------------------------+
  310.  
  311.    or with the following condensed incremental message:
  312.  
  313.                  +---------------------------------------------------+
  314.       Header     | OPCODE=SQUERY, RESPONSE                           |
  315.                  +---------------------------------------------------+
  316.       Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
  317.                  +---------------------------------------------------+
  318.       Answer     | JAIN.AD.JP.         IN SOA serial=3               |
  319.                  | JAIN.AD.JP.         IN SOA serial=1               |
  320.                  | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
  321.                  | JAIN.AD.JP.         IN SOA serial=3               |
  322.                  | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
  323.                  | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
  324.                  | JAIN.AD.JP.         IN SOA serial=3               |
  325.                  +---------------------------------------------------+
  326.       Authority  | <empty>                                           |
  327.                  +---------------------------------------------------+
  328.       Additional | <empty>                                           |
  329.                  +---------------------------------------------------+
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Ohta                        Standards Track                     [Page 6]
  339.  
  340. RFC 1995            Incremental Zone Transfer in DNS         August 1996
  341.  
  342.  
  343.    or, if UDP packet overflow occurs, with the following message:
  344.  
  345.                  +---------------------------------------------------+
  346.       Header     | OPCODE=SQUERY, RESPONSE                           |
  347.                  +---------------------------------------------------+
  348.       Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
  349.                  +---------------------------------------------------+
  350.       Answer     | JAIN.AD.JP.         IN SOA serial=3               |
  351.                  +---------------------------------------------------+
  352.       Authority  | <empty>                                           |
  353.                  +---------------------------------------------------+
  354.       Additional | <empty>                                           |
  355.                  +---------------------------------------------------+
  356.  
  357. 8. Acknowledgements
  358.  
  359.    The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
  360.    and Jon Postel.
  361.  
  362.    For the refinement of the protocol and documentation, many people
  363.    have contributed including, but not limited to, Anant Kumar, Robert
  364.    Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the
  365.    members of the IETF DNSIND working group.
  366.  
  367. 9. References
  368.  
  369.    [NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt
  370.    Notification of Zone Changes", RFC 1996, August 1996.
  371.  
  372.    [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and
  373.    RFC 1035), November 1987.
  374.  
  375. 10. Security Considerations
  376.  
  377.    Though DNS is related to several security problems, no attempt is
  378.    made to fix them in this document.
  379.  
  380.    This document is believed to introduce no additional security
  381.    problems to the current DNS protocol.
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Ohta                        Standards Track                     [Page 7]
  395.  
  396. RFC 1995            Incremental Zone Transfer in DNS         August 1996
  397.  
  398.  
  399. 11. Author's Address
  400.  
  401.    Masataka Ohta
  402.    Computer Center
  403.    Tokyo Institute of Technology
  404.    2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
  405.  
  406.    Phone: +81-3-5734-3299
  407.    Fax: +81-3-5734-3415
  408.    EMail: mohta@necom830.hpcl.titech.ac.jp
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Ohta                        Standards Track                     [Page 8]
  451.  
  452.