external/bsd/bind/dist/doc/rfc/rfc1995.txt

   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 \f
  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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f