idnits 2.17.1 draft-ietf-dnsext-ixfr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 26 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 19 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 141: '...server. The IXFR SHOULD be aborted, an...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2000) is 8717 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT M. Ohta 2 draft-ietf-dnsext-ixfr-01.txt Tokyo Institute of Technology 3 June 2000 5 Incremental Zone Transfer in DNS 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright (C) The Internet Society (March/5/2000). All Rights 29 Reserved. 31 Abstract 33 This document proposes extensions to the DNS protocols to provide an 34 incremental zone transfer (IXFR) mechanism. 36 1. Introduction 38 For rapid propagation of changes to a DNS database [STD13], it is 39 necessary to reduce latency by actively notifying servers of the 40 change. This is accomplished by the NOTIFY extension of the DNS 41 [NOTIFY]. 43 The current full zone transfer mechanism (AXFR) is not an efficient 44 means to propagate changes to a small part of a zone, as it transfers 45 the entire zone file. 47 Incremental transfer (IXFR) as proposed is a more efficient 48 mechanism, as it transfers only the changed portion(s) of a zone. 50 In this document, a secondary name server which requests IXFR is 51 called an IXFR client and a primary or secondary name server which 52 responds to the request is called an IXFR server. 54 The current AXFR specification in [STD13] is very terse, and in 55 practice it does not contain sufficient information to construct 56 interoperable implementations. This memo assumes AXFR protocol used 57 in existing interoperable implementations. 59 2. Brief Description of the Protocol 61 If an IXFR client, which likely has an older version of a zone, 62 thinks it needs new information about the zone (typically through SOA 63 refresh timeout or the NOTIFY mechanism), it sends an IXFR message 64 containing the SOA serial number of its, presumably outdated, copy of 65 the zone. 67 An IXFR server should keep record of the newest version of the zone 68 and the differences between that copy and several older versions. 69 When an IXFR request with an older version number is received, the 70 IXFR server needs to send only the differences required to make that 71 version current. Alternatively, the server may choose to transfer 72 the entire zone just as in a normal full zone transfer. 74 When a zone has been updated, it should be saved in stable storage 75 before the new version is used to respond to IXFR (or AXFR) queries. 76 Otherwise, if the server crashes, data which is no longer available 77 may have been distributed to secondary servers, which can cause 78 persistent database inconsistencies. 80 If an IXFR query with the same or newer version number than that of 81 the server is received, it is replied to with a single SOA record of 82 the server's current version, just as a SOA query before TCP AXFR. 84 Transport of a query may be by either UDP or TCP. If an IXFR query 85 is via UDP, the IXFR server may attempt to reply using UDP if the 86 entire response can be contained in a single UDP packet. If the UDP 87 reply does not fit, the query is responded to with a single SOA 88 record of the server's current version to inform the client that a 89 TCP query should be initiated. 91 Thus, a client should first make an IXFR query using UDP. If the 92 query type or other part of the query is not recognized by the 93 server, an AXFR (preceded by a UDP SOA query) should be tried, 94 ensuring backward compatibility. If the query response is a single 95 packet with the entire new zone, or if the server does not have a 96 newer version than the client, everything is done. Otherwise, a TCP 97 IXFR query should be tried. 99 To ensure integrity, servers should use UDP checksums for all UDP 100 responses. A cautious client which receives a UDP packet with a 101 checksum value of zero should ignore the result and try a TCP IXFR 102 instead. 104 The query type value of IXFR assigned by IANA is 251. 106 3. Query Format 108 The IXFR query packet format is the same as that of a normal DNS 109 query, but with the query type being IXFR and the authority section 110 containing the SOA record of client's version of the zone. 112 4. Response Format 114 If incremental zone transfer is not available, the entire zone is 115 returned. The first and the last RR of the response is the SOA 116 record of the zone. I.e. the behavior is the same as an AXFR 117 response except the query type is IXFR. 119 If incremental zone transfer is available, one or more difference 120 sequences is returned. The list of difference sequences is preceded 121 and followed by a copy of the server's current version of the SOA. 123 Each difference sequence represents one update to the zone (one SOA 124 serial change) consisting of deleted RRs and added RRs. The first RR 125 of the deleted RRs is the older SOA RR and the first RR of the added 126 RRs is the newer SOA RR. 128 Modification of an RR is performed first by removing the original RR 129 and then adding the modified one. 131 Each individual difference sequence must leave the zone in a 132 consistent state with contents identical to those visible in the 133 master at the time identified by the new SOA serial number. During a 134 transfer, the slave server may save the zone data to stable storage 135 and use it in responding to queries after applying one or more 136 complete difference sequences even if they do not yet form a complete 137 incremental transfer. 139 A difference sequence which indicates the removal of a non-existent 140 RR is an indication of an error that the IXFR client is out-of-sync 141 with the IXFR server. The IXFR SHOULD be aborted, and an AXFR 142 requested from the same server. A difference sequence which 143 indicates the addition of a seemingly duplicate (though a node may 144 have multiple TXT RR's with duplicate content) or conflicting RR may 145 just be a malformed zone. In any case the IXFR should be aborted and 146 AXFR performed. 148 The sequences of differential information are ordered oldest first 149 newest last. Thus, the differential sequences are the history of 150 changes made since the version known by the IXFR client up to the 151 server's current version. 153 RR sets (RRs of the same RR types) in the incremental transfer 154 messages may be partial. For example, if a single RR of multiple RRs 155 of the same RR type changes, only the changed RR needs to be 156 transferred. 158 An IXFR client, should only replace an older version with a newer 159 version after all the differences have been successfully processed. 161 An incremental response is different from that of a non-incremental 162 response in that it begins with two SOA RRs, the server's current SOA 163 followed by the SOA of the client's version which is about to be 164 replaced. 166 A slave receiving an IXFR response needs to classify it as one of the 167 following four cases: 169 UDP-overflow An indication that the transfer will not fit in a 170 UDP packet and should be retried over TCP 172 up-to-date An indication that the serial number of the 173 request is current and no transfer is necessary 175 incremental An incremental transfer 177 nonincremental A full zone transfer 179 Performing this classification requires some care. For example, 180 UDP-overflow responses differ from UDP up-to-date responses only in 181 the value of the SOA serial number. Also, to distinguish between a 182 nonincremental and an incremental transfer, the slave needs to 183 receive the first two response RRs and check whether the second one 184 is a SOA. If the master chose to transmit each RR in a separate TCP 185 message, this involves waiting for a second TCP response message. On 186 the other hand, in the case of an up-to-date response, the slave must 187 not wait for a second TCP message as doing so would cause it to hang 188 waiting for a message the master will never send. Therefore, the 189 slave must examine the first message and eliminate the possibility 190 that it is a TCP up-to-date response before it attempts to receive a 191 second message. 193 Slaves must not attempt to classify a response based on incidental 194 information such as the presence or absence of a question section, 195 the QTYPE field of a possible question section, or the number of 196 response RRs in a TCP response message. 198 An example algorithm for classifying IXFR responses appears in 199 Appendix A. 201 5. Purging Strategy 203 An IXFR server can not be required to hold all previous versions 204 forever and may delete them anytime. In general, there is a trade- 205 off between the size of storage space and the possibility of using 206 IXFR. 208 Information about older versions should be purged if the total length 209 of an IXFR response would be longer than that of an AXFR response. 210 Given that the purpose of IXFR is to reduce AXFR overhead, this 211 strategy is quite reasonable. The strategy assures that the amount 212 of storage required is at most twice that of the current zone 213 information. 215 Information older than the SOA expire period should also be purged. 217 6. Optional Condensation of Multiple Versions 219 An IXFR server may optionally condense multiple difference sequences 220 into a single difference sequence, thus, dropping information on 221 intermediate versions. 223 This may be beneficial if a lot of versions, not all of which are 224 useful, are generated. For example, if multiple ftp servers share a 225 single DNS name and the IP address associated with the name is 226 changed once a minute to balance load between the ftp servers, it is 227 not so important to keep track of all the history of changes. 229 But, this feature may not be so useful if an IXFR client has access 230 to two IXFR servers: A and B, with inconsistent condensation results. 231 The current version of the IXFR client, received from server A, may 232 be unknown to server B. In such a case, server B can not provide 233 incremental data from the unknown version and a full zone transfer is 234 necessary. 236 Condensation is completely optional. Clients can't detect from the 237 response whether the server has condensed the reply or not. 239 For interoperability, IXFR servers, including those without the 240 condensation feature, should not flag an error even if it receives a 241 client's IXFR request with a version number known not to exist (which 242 means that the server has versions with version numbers newer and 243 older than, but not equal to, the version number) and should, 244 instead, attempt to perform a full zone transfer by replying with a 245 single SOA record of the server's current version (UDP case) or with 246 a full zone content (UDP or TCP case). 248 7. Example 250 Given the following three generations of data with the current serial 251 number of 3, 253 example.domain. IN SOA ns.example.domain. rt.example.domain. ( 254 1 600 600 3600000 604800) 255 IN NS ns.example.domain. 256 ns.example.domain. IN A 10.0.0.1 257 ftp.example.domain. IN A 10.0.1.1 259 ftp.example.domain. is removed and www.example.domain. is added. 261 example.domain. IN SOA ns.example.domain. rt.example.domain. ( 262 2 600 600 3600000 604800) 263 IN NS ns.example.domain. 264 ns.example.domain. IN A 10.0.0.1 265 www.example.domain. IN A 10.0.1.2 266 IN A 10.0.2.1 268 One of the IP addresses of www.example.domain. is changed. 270 example.domain. IN SOA ns.example.domain. rt.example.domain. ( 271 3 600 600 3600000 604800) 272 IN NS ns.example.domain. 273 ns.example.domain. IN A 10.0.0.1 274 www.example.domain. IN A 10.0.3.1 275 IN A 10.0.2.1 277 The following IXFR query 279 +---------------------------------------------------+ 280 Header | OPCODE=SQUERY | 281 +---------------------------------------------------+ 282 Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | 283 +---------------------------------------------------+ 284 Answer | | 285 +---------------------------------------------------+ 286 Authority | example.domain. IN SOA serial=1 | 287 +---------------------------------------------------+ 288 Additional | | 289 +---------------------------------------------------+ 291 could be replied to with the following full zone transfer message: 293 +---------------------------------------------------+ 294 Header | OPCODE=SQUERY, RESPONSE | 295 +---------------------------------------------------+ 296 Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | 297 +---------------------------------------------------+ 298 Answer | example.domain. IN SOA serial=3 | 299 | example.domain. IN NS NS.JAIN.AD.JP. | 300 | ns.example.domain. IN A 10.0.0.1 | 301 | www.example.domain. IN A 10.0.3.1 | 302 | www.example.domain. IN A 10.0.2.1 | 303 | example.domain. IN SOA serial=3 | 304 +---------------------------------------------------+ 305 Authority | | 306 +---------------------------------------------------+ 307 Additional | | 308 +---------------------------------------------------+ 310 or with the following incremental message: 312 +---------------------------------------------------+ 313 Header | OPCODE=SQUERY, RESPONSE | 314 +---------------------------------------------------+ 315 Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | 316 +---------------------------------------------------+ 317 Answer | example.domain. IN SOA serial=3 | 318 | example.domain. IN SOA serial=1 | 319 | ftp.example.domain. IN A 10.0.1.1 | 320 | example.domain. IN SOA serial=2 | 321 | www.example.domain. IN A 10.0.1.2 | 322 | www.example.domain. IN A 10.0.2.1 | 323 | example.domain. IN SOA serial=2 | 324 | www.example.domain. IN A 10.0.1.2 | 325 | example.domain. IN SOA serial=3 | 326 | www.example.domain. IN A 10.0.3.1 | 327 | example.domain. IN SOA serial=3 | 328 +---------------------------------------------------+ 329 Authority | | 330 +---------------------------------------------------+ 331 Additional | | 332 +---------------------------------------------------+ 334 or with the following condensed incremental message: 336 +---------------------------------------------------+ 337 Header | OPCODE=SQUERY, RESPONSE | 338 +---------------------------------------------------+ 339 Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | 340 +---------------------------------------------------+ 342 Answer | example.domain. IN SOA serial=3 | 343 | example.domain. IN SOA serial=1 | 344 | ftp.example.domain. IN A 10.0.1.1 | 345 | example.domain. IN SOA serial=3 | 346 | www.example.domain. IN A 10.0.3.1 | 347 | www.example.domain. IN A 10.0.2.1 | 348 | example.domain. IN SOA serial=3 | 349 +---------------------------------------------------+ 350 Authority | | 351 +---------------------------------------------------+ 352 Additional | | 353 +---------------------------------------------------+ 355 or, if UDP packet overflow occurs, with the following message: 357 +---------------------------------------------------+ 358 Header | OPCODE=SQUERY, RESPONSE | 359 +---------------------------------------------------+ 360 Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | 361 +---------------------------------------------------+ 362 Answer | example.domain. IN SOA serial=3 | 363 +---------------------------------------------------+ 364 Authority | | 365 +---------------------------------------------------+ 366 Additional | | 367 +---------------------------------------------------+ 369 8. Acknowledgements 371 The original idea of IXFR was conceived by Anant Kumar, Steve Hotz 372 and Jon Postel. 374 For the refinement of the protocol and documentation, many people 375 have contributed including, but not limited to, Anant Kumar, Robert 376 Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz, Andreas 377 Gustafsson, Josh Littlefield, Olafur Gudmundsson, William King and 378 the members of the IETF DNSEXT working group. 380 9. References 382 [NOTIFY] Vixie, P., "A Mechanism for Prompt Notification of Zone 383 Changes (DNS NOTIFY)", RFC1996, August 1996. 385 [STD13] Mockapetris, P., "Domain Name System" (RFC1034 and RFC1035), 386 November 1987. 388 10. Appendix A Appendix A. Pseudocode for response classification 389 The following pseudocode outlines one possible algorithm for 390 classifying IXFR responses. 392 receive the first response message; 393 extract the first response RR, always an SOA; 394 if (the serial number of this SOA RR is less 395 than or equal to that of the request) { 396 the response is an up-to-date response; 397 } else { 398 if (the response message was received by UDP and 399 contains no more RRs after the initial SOA) { 400 the response is a UDP-overflow response; 401 } else { 402 extract the second response RR, waiting for a second TCP 403 response message if necessary; 404 if (this second RR is an SOA) { 405 the response is an incremental transfer; 406 } else { 407 the response is a nonincremental transfer; 408 } 409 } 410 } 412 11. Security Considerations 414 Though DNS is related to several security problems, no attempt is 415 made to fix them in this document. 417 This document is believed to introduce no additional security 418 problems to the current DNS protocol. 420 12. Author's Address 422 Masataka Ohta 423 Computer Center, Tokyo Institute of Technology 424 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN 426 Phone: +81-3-5734-3299, Fax: +81-3-5734-3415 427 EMail: mohta@necom830.hpcl.titech.ac.jp 429 Comments should be directed to DNSEXT WG . 431 13. Full Copyright Statement 433 "Copyright (C) The Internet Society (March/5/2000). All Rights 434 Reserved. 436 This document and translations of it may be copied and furnished to 437 others, and derivative works that comment on or otherwise explain it 438 or assist in its implementation may be prepared, copied, published 439 and distributed, in whole or in part, without restriction of any 440 kind, provided that the above copyright notice and this paragraph are 441 included on all such copies and derivative works. However, this 442 document itself may not be modified in any way, such as by removing 443 the copyright notice or references to the Internet Society or other 444 Internet organizations, except as needed for the purpose of 445 developing Internet standards in which case the procedures for 446 copyrights defined in the Internet Standards process must be 447 followed, or as required to translate it into languages other than 448 English. 450 The limited permissions granted above are perpetual and will not be 451 revoked by the Internet Society or its successors or assigns. 453 This document and the information contained herein is provided on an 454 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 455 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 456 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 457 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 458 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.