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