File: rfc1995.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (451 lines) | stat: -rw-r--r-- 16,810 bytes parent folder | download | duplicates (13)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
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
451






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.

1. Introduction

   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].

   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.

   Incremental transfer (IXFR) as proposed is a more efficient
   mechanism, as it transfers only the changed portion(s) of a zone.

   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

   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.





Ohta                        Standards Track                     [Page 1]

RFC 1995            Incremental Zone Transfer in DNS         August 1996


   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.

   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

   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.








Ohta                        Standards Track                     [Page 2]

RFC 1995            Incremental Zone Transfer in DNS         August 1996


4. Response Format

   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.

   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.

   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

   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.



Ohta                        Standards Track                     [Page 3]

RFC 1995            Incremental Zone Transfer in DNS         August 1996


   Information older than the SOA expire period may also be purged.

6. Optional Condensation of Multiple Versions

   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.

   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

   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.

      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



Ohta                        Standards Track                     [Page 4]

RFC 1995            Incremental Zone Transfer in DNS         August 1996


   One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.

      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:

                 +---------------------------------------------------+
      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>                                           |
                 +---------------------------------------------------+










Ohta                        Standards Track                     [Page 5]

RFC 1995            Incremental Zone Transfer in DNS         August 1996


   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>                                           |
                 +---------------------------------------------------+








Ohta                        Standards Track                     [Page 6]

RFC 1995            Incremental Zone Transfer in DNS         August 1996


   or, if UDP packet overflow occurs, with the following message:

                 +---------------------------------------------------+
      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

   The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
   and 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.

9. References

   [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

   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.












Ohta                        Standards Track                     [Page 7]

RFC 1995            Incremental Zone Transfer in DNS         August 1996


11. Author's Address

   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









































Ohta                        Standards Track                     [Page 8]