idnits 2.17.1 draft-ietf-dnsext-ixfr-00.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 40 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 19 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 134: '...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 (March 2000) is 8798 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'XFRCLARIFY' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 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-00.txt Tokyo Institute of Technology 3 March 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 AXFR specification is very terse, and in practice it does not 55 contain sufficient information to construct interoperable 56 implementations. [XFRCLARIFY] gives the clarification on the AXFR 57 specification based on existing practice, which is, unless otherwise 58 noted, also applicable to IXFR. 60 2. Brief Description of the Protocol 62 If an IXFR client, which likely has an older version of a zone, 63 thinks it needs new information about the zone (typically through SOA 64 refresh timeout or the NOTIFY mechanism), it sends an IXFR message 65 containing the SOA serial number of its, presumably outdated, copy of 66 the zone. 68 An IXFR server should keep record of the newest version of the zone 69 and the differences between that copy and several older versions. 70 When an IXFR request with an older version number is received, the 71 IXFR server needs to send only the differences required to make that 72 version current. Alternatively, the server may choose to transfer 73 the entire zone just as in a normal full zone transfer. 75 When a zone has been updated, it should be saved in stable storage 76 before the new version is used to respond to IXFR (or AXFR) queries. 77 Otherwise, if the server crashes, data which is no longer available 78 may have been distributed to secondary servers, which can cause 79 persistent database inconsistencies. 81 If an IXFR query with the same or newer version number than that of 82 the server is received, it is replied to with a single SOA record of 83 the server's current version, just as a SOA query before TCP AXFR. 85 Transport of a query may be by either UDP or TCP. If an IXFR query 86 is via UDP, the IXFR server may attempt to reply using UDP if the 87 entire response can be contained in a single UDP packet. If the UDP 88 reply does not fit, the query is responded to with a single SOA 89 record of the server's current version to inform the client that a 90 TCP query should be initiated. 92 Thus, a client should first make an IXFR query using UDP. If the 93 query type or other part of the query is not recognized by the 94 server, an AXFR (preceded by a UDP SOA query) should be tried, 95 ensuring backward compatibility. If the query response is a single 96 packet with the entire new zone, or if the server does not have a 97 newer version than the client, everything is done. Otherwise, a TCP 98 IXFR query should be tried. 100 To ensure integrity, servers should use UDP checksums for all UDP 101 responses. A cautious client which receives a UDP packet with a 102 checksum value of zero should ignore the result and try a TCP IXFR 103 instead. 105 The query type value of IXFR assigned by IANA is 251. 107 3. Query Format 109 The IXFR query packet format is the same as that of a normal DNS 110 query, but with the query type being IXFR and the authority section 111 containing the SOA record of client's version of the zone. 113 4. Response Format 115 If incremental zone transfer is not available, the entire zone is 116 returned. The first and the last RR of the response is the SOA 117 record of the zone. I.e. the behavior is the same as an AXFR 118 response except the query type is IXFR. 120 If incremental zone transfer is available, one or more difference 121 sequences is returned. The list of difference sequences is preceded 122 and followed by a copy of the server's current version of the SOA. 124 Each difference sequence represents one update to the zone (one SOA 125 serial change) consisting of deleted RRs and added RRs. The first RR 126 of the deleted RRs is the older SOA RR and the first RR of the added 127 RRs is the newer SOA RR. 129 Modification of an RR is performed first by removing the original RR 130 and then adding the modified one. 132 A difference sequence which indicates the removal of a non-existent 133 RR is an indication of an error that the IXFR client is out-of-sync 134 with the IXFR server. The IXFR SHOULD be aborted, and an AXFR 135 requested from the same server. A difference sequence which 136 indicates the addition of a seemingly duplicate (through a node may 137 have multiple TXT RRs of the duplicated content) or conflicting RR 138 may just be a result of malformed zone ando should be treated just as 139 a AXFR with malformed zone content. 141 The sequences of differential information are ordered oldest first 142 newest last. Thus, the differential sequences are the history of 143 changes made since the version known by the IXFR client up to the 144 server's current version. 146 RR sets (RRs of the same RR types) in the incremental transfer 147 messages may be partial. For examle, if a single RR of multiple RRs 148 of the same RR type changes, only the changed RR needs to be 149 transferred. 151 An IXFR client, should only replace an older version with a newer 152 version after all the differences have been successfully processed. 154 An incremental response is different from that of a non-incremental 155 response in that it begins with two SOA RRs, the server's current SOA 156 followed by the SOA of the client's version which is about to be 157 replaced. 159 To determine whether an IXFR response received over TCP is 160 incremental or not, it is necessary to try to receive the first two 161 answer RRs in the answer stream (which may or may not involve 162 receiving two TCP DNS messages). The first RR is always an SOA. If 163 the second RR does not exist, the client copy of the zone is up to 164 date and no zone transfer is necessary. If the second RR is an SOA 165 with a serial number different from the first SOA, the response is 166 incremental, in IXFR format. If it is a non-SOA RR or a SOA RR with 167 the same serial number as the initial SOA RR, it is a nonincremental 168 response in AXFR format. The last case cannot arise unless the zone 169 is malformed containing only the SOA record without NS records. 171 This is the only way to identify an incremental response. A slave 172 cannot reliably identify an incremental response based on the 173 presence or absence of a question section, the QTYPE field of a 174 possible question section, or the number of response RRs per message, 176 5. Purging Strategy 178 An IXFR server can not be required to hold all previous versions 179 forever and may delete them anytime. In general, there is a trade-off 180 between the size of storage space and the possibility of using IXFR. 182 Information about older versions should be purged if the total length 183 of an IXFR response would be longer than that of an AXFR response. 184 Given that the purpose of IXFR is to reduce AXFR overhead, this 185 strategy is quite reasonable. The strategy assures that the amount 186 of storage required is at most twice that of the current zone 187 information. 189 Information older than the SOA expire period should also be purged. 191 6. Optional Condensation of Multiple Versions 193 An IXFR server may optionally condense multiple difference sequences 194 into a single difference sequence, thus, dropping information on 195 intermediate versions. 197 This may be beneficial if a lot of versions, not all of which are 198 useful, are generated. For example, if multiple ftp servers share a 199 single DNS name and the IP address associated with the name is 200 changed once a minute to balance load between the ftp servers, it is 201 not so important to keep track of all the history of changes. 203 But, this feature may not be so useful if an IXFR client has access 204 to two IXFR servers: A and B, with inconsistent condensation results. 205 The current version of the IXFR client, received from server A, may 206 be unknown to server B. In such a case, server B can not provide 207 incremental data from the unknown version and a full zone transfer is 208 necessary. 210 Condensation is completely optional. Clients can't detect from the 211 response whether the server has condensed the reply or not. 213 For interoperability, IXFR servers, including those without the 214 condensation feature, should not flag an error even if it receives a 215 client's IXFR request with a version number known not to exist (which 216 means that the server has versions with version numbers newer and 217 older than, but not equal to, the version number) and should, 218 instead, attempt to perform a full zone transfer by replying with a 219 single SOA record of the server's current version (UDP case) or with 220 a full zone content (UDP or TCP case). 222 7. Example 224 Given the following three generations of data with the current serial 225 number of 3, 227 JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. ( 228 1 600 600 3600000 604800) 229 IN NS NS.JAIN.AD.JP. 230 NS.JAIN.AD.JP. IN A 133.69.136.1 231 NEZU.JAIN.AD.JP. IN A 133.69.136.5 233 NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added. 235 jain.ad.jp. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. ( 236 2 600 600 3600000 604800) 237 IN NS NS.JAIN.AD.JP. 238 NS.JAIN.AD.JP. IN A 133.69.136.1 239 JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 240 IN A 192.41.197.2 242 One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed. 244 JAIN.AD.JP. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. ( 245 3 600 600 3600000 604800) 246 IN NS NS.JAIN.AD.JP. 247 NS.JAIN.AD.JP. IN A 133.69.136.1 248 JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 249 IN A 192.41.197.2 251 The following IXFR query 253 +---------------------------------------------------+ 254 Header | OPCODE=SQUERY | 255 +---------------------------------------------------+ 256 Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | 257 +---------------------------------------------------+ 258 Answer | | 259 +---------------------------------------------------+ 260 Authority | JAIN.AD.JP. IN SOA serial=1 | 261 +---------------------------------------------------+ 262 Additional | | 263 +---------------------------------------------------+ 265 could be replied to with the following full zone transfer message: 267 +---------------------------------------------------+ 268 Header | OPCODE=SQUERY, RESPONSE | 269 +---------------------------------------------------+ 270 Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | 271 +---------------------------------------------------+ 272 Answer | JAIN.AD.JP. IN SOA serial=3 | 273 | JAIN.AD.JP. IN NS NS.JAIN.AD.JP. | 274 | NS.JAIN.AD.JP. IN A 133.69.136.1 | 275 | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | 276 | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | 277 | JAIN.AD.JP. IN SOA serial=3 | 278 +---------------------------------------------------+ 279 Authority | | 280 +---------------------------------------------------+ 281 Additional | | 282 +---------------------------------------------------+ 284 or with the following incremental message: 286 +---------------------------------------------------+ 287 Header | OPCODE=SQUERY, RESPONSE | 288 +---------------------------------------------------+ 289 Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | 290 +---------------------------------------------------+ 291 Answer | JAIN.AD.JP. IN SOA serial=3 | 292 | JAIN.AD.JP. IN SOA serial=1 | 293 | NEZU.JAIN.AD.JP. IN A 133.69.136.5 | 294 | JAIN.AD.JP. IN SOA serial=2 | 295 | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | 296 | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | 297 | JAIN.AD.JP. IN SOA serial=2 | 298 | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | 299 | JAIN.AD.JP. IN SOA serial=3 | 300 | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | 301 | JAIN.AD.JP. IN SOA serial=3 | 302 +---------------------------------------------------+ 303 Authority | | 304 +---------------------------------------------------+ 305 Additional | | 306 +---------------------------------------------------+ 308 or with the following condensed incremental message: 310 +---------------------------------------------------+ 311 Header | OPCODE=SQUERY, RESPONSE | 312 +---------------------------------------------------+ 313 Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | 314 +---------------------------------------------------+ 315 Answer | JAIN.AD.JP. IN SOA serial=3 | 316 | JAIN.AD.JP. IN SOA serial=1 | 317 | NEZU.JAIN.AD.JP. IN A 133.69.136.5 | 318 | JAIN.AD.JP. IN SOA serial=3 | 319 | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | 320 | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | 321 | JAIN.AD.JP. IN SOA serial=3 | 322 +---------------------------------------------------+ 323 Authority | | 324 +---------------------------------------------------+ 325 Additional | | 326 +---------------------------------------------------+ 328 or, if UDP packet overflow occurs, with the following message: 330 +---------------------------------------------------+ 331 Header | OPCODE=SQUERY, RESPONSE | 332 +---------------------------------------------------+ 333 Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | 334 +---------------------------------------------------+ 335 Answer | JAIN.AD.JP. IN SOA serial=3 | 336 +---------------------------------------------------+ 337 Authority | | 338 +---------------------------------------------------+ 339 Additional | | 340 +---------------------------------------------------+ 342 8. Acknowledgements 344 The original idea of IXFR was conceived by Anant Kumar, Steve Hotz 345 and Jon Postel. 347 For the refinement of the protocol and documentation, many people 348 have contributed including, but not limited to, Anant Kumar, Robert 349 Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz, Andreas 350 Gustafsson, Josh Littlefield, Olafur Gudmundsson, William King and 351 the members of the IETF DNSEXT working group. 353 9. References 355 [NOTIFY] Vixie, P., "A Mechanism for Prompt Notification of Zone 356 Changes (DNS NOTIFY)", RFC1996, August 1996. 358 [STD13] Mockapetris, P., "Domain Name System" (RFC1034 and RFC1035), 359 November 1987. 361 [XFRCLARIFY] 363 10. Security Considerations 365 Though DNS is related to several security problems, no attempt is 366 made to fix them in this document. 368 This document is believed to introduce no additional security 369 problems to the current DNS protocol. 371 11. Author's Address 373 Masataka Ohta 374 Computer Center, Tokyo Institute of Technology 375 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN 377 Phone: +81-3-5734-3299, Fax: +81-3-5734-3415 378 EMail: mohta@necom830.hpcl.titech.ac.jp 380 Comments should be directed to DNSEXT WG . 382 12. Full Copyright Statement 384 "Copyright (C) The Internet Society (March/5/2000). All Rights 385 Reserved. 387 This document and translations of it may be copied and furnished to 388 others, and derivative works that comment on or otherwise explain it 389 or assist in its implementation may be prepared, copied, published 390 and distributed, in whole or in part, without restriction of any 391 kind, provided that the above copyright notice and this paragraph are 392 included on all such copies and derivative works. However, this 393 document itself may not be modified in any way, such as by removing 394 the copyright notice or references to the Internet Society or other 395 Internet organizations, except as needed for the purpose of 396 developing Internet standards in which case the procedures for 397 copyrights defined in the Internet Standards process must be 398 followed, or as required to translate it into languages other than 399 English. 401 The limited permissions granted above are perpetual and will not be 402 revoked by the Internet Society or its successors or assigns. 404 This document and the information contained herein is provided on an 405 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 406 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 407 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 408 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 409 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.