idnits 2.17.00 (12 Aug 2021) /tmp/idnits61956/draft-ietf-dnsind-ixfr-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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. 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 (February 1996) is 9585 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. 'NOTIFY' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT M. Ohta 3 draft-ietf-dnsind-ixfr-06.txt Tokyo Institute of Technology 4 February 1996 6 Incremental Zone Transfer in DNS 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 This document proposes extensions to the DNS protocols to provide an 29 incremental zone transfer (IXFR) mechanism. 31 1. Introduction 33 For rapid propagation of changes to a DNS database [STD13], it is 34 necessary to reduce latency by actively notifying servers of the 35 change. This is accomplished by the NOTIFY extension of the DNS 36 [NOTIFY]. 38 The current full zone transfer mechanism (AXFR) is not an efficient 39 means to propagate changes to a small part of a zone, as it transfers 40 the entire zone file. 42 Incremental transfer (IXFR) as proposed is a more efficient 43 mechanism, as it transfers only the changed portion(s) of a zone. 45 In this document, a secondary name server which requests IXFR is 46 called an IXFR client and a primary or secondary name server which 47 responds to the request is called an IXFR server. 49 2. Brief Description of the Protocol 50 If an IXFR client, which likely has an older version of a zone, 51 thinks it needs new information about the zone (typically through SOA 52 refresh timeout or the NOTIFY mechanism), it sends an IXFR message 53 containing the SOA serial number of its, presumably outdated, copy of 54 the zone. 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. 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. 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. 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. 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. If the query response is a single 83 packet with the entire new zone, or if the server does not have a 84 newer version than the client, everything is done. Otherwise, a TCP 85 IXFR query should be tried. 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. 92 The query type value of IXFR assigned by IANA is 251. 94 3. Query Format 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. 100 4. Response Format 102 If incremental zone transfer is not available, the entire zone is 103 returned. The first and the last RR of the response is the SOA 104 record of the zone. I.e. the behavior is the same as an AXFR 105 response except the query type is IXFR. 107 If incremental zone transfer is available, one or more difference 108 sequences is returned. The list of difference sequences is preceded 109 and followed by a copy of the server's current version of the SOA. 111 Each difference sequence represents one update to the zone (one SOA 112 serial change) consisting of deleted RRs and added RRs. The first RR 113 of the deleted RRs is the older SOA RR and the first RR of the added 114 RRs is the newer SOA RR. 116 Modification of an RR is performed first by removing the original RR 117 and then adding the modified one. 119 The sequences of differential information are ordered oldest first 120 newest last. Thus, the differential sequences are the history of 121 changes made since the version known by the IXFR client up to the 122 server's current version. 124 RRs in the incremental transfer messages may be partial. That is, if 125 a single RR of multiple RRs of the same RR type changes, only the 126 changed RR is transferred. 128 An IXFR client, should only replace an older version with a newer 129 version after all the differences have been successfully processed. 131 An incremental response is different from that of a non-incremental 132 response in that it begins with two SOA RRs, the server's current SOA 133 followed by the SOA of the client's version which is about to be 134 replaced. 136 5. Purging Strategy 138 An IXFR server can not be required to hold all previous versions 139 forever and may delete them anytime. In general, there is a trade-off 140 between the size of storage space and the possibility of using IXFR. 142 Information about older versions should be purged if the total length 143 of an IXFR response would be longer than that of an AXFR response. 144 Given that the purpose of IXFR is to reduce AXFR overhead, this 145 strategy is quite reasonable. The strategy assures that the amount 146 of storage required is at most twice that of the current zone 147 information. 149 Information older than the SOA expire period may also be purged. 151 6. Optional Condensation of Multiple Versions 153 An IXFR server may optionally condense multiple difference sequences 154 into a single difference sequence, thus, dropping information on 155 intermediate versions. 157 This may be beneficial if a lot of versions, not all of which are 158 useful, are generated. For example, if multiple ftp servers share a 159 single DNS name and the IP address associated with the name is 160 changed once a minute to balance load between the ftp servers, it is 161 not so important to keep track of all the history of changes. 163 But, this feature may not be so useful if an IXFR client has access 164 to two IXFR servers: A and B, with inconsistent condensation results. 165 The current version of the IXFR client, received from server A, may 166 be unknown to server B. In such a case, server B can not provide 167 incremental data from the unknown version and a full zone transfer is 168 necessary. 170 Condensation is completely optional. Clients can't detect from the 171 response whether the server has condensed the reply or not. 173 For interoperability, IXFR servers, including those without the 174 condensation feature, should not flag an error even if it receives a 175 client's IXFR request with a unknown version number and should, 176 instead, attempt to perform a full zone transfer. 178 7. Example 180 Given the following three generations of data with the current serial 181 number of 3, 183 JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. ( 184 1 600 600 3600000 604800) 185 IN NS NS.JAIN.AD.JP. 186 NS.JAIN.AD.JP. IN A 133.69.136.1 187 NEZU.JAIN.AD.JP. IN A 133.69.136.5 189 NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added. 191 jain.ad.jp. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. ( 192 2 600 600 3600000 604800) 193 IN NS NS.JAIN.AD.JP. 195 NS.JAIN.AD.JP. IN A 133.69.136.1 196 JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 197 IN A 192.41.197.2 199 One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed. 201 JAIN.AD.JP. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. ( 202 3 600 600 3600000 604800) 203 IN NS NS.JAIN.AD.JP. 204 NS.JAIN.AD.JP. IN A 133.69.136.1 205 JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 206 IN A 192.41.197.2 208 The following IXFR query 210 +---------------------------------------------------+ 211 Header | OPCODE=SQUERY | 212 +---------------------------------------------------+ 213 Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | 214 +---------------------------------------------------+ 215 Answer | | 216 +---------------------------------------------------+ 217 Authority | JAIN.AD.JP. IN SOA serial=1 | 218 +---------------------------------------------------+ 219 Additional | | 220 +---------------------------------------------------+ 222 could be replied to with the following full zone transfer message: 224 +---------------------------------------------------+ 225 Header | OPCODE=SQUERY, RESPONSE | 226 +---------------------------------------------------+ 227 Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | 228 +---------------------------------------------------+ 229 Answer | JAIN.AD.JP. IN SOA serial=3 | 230 | JAIN.AD.JP. IN NS NS.JAIN.AD.JP. | 231 | NS.JAIN.AD.JP. IN A 133.69.136.1 | 232 | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | 233 | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | 234 | JAIN.AD.JP. IN SOA serial=3 | 235 +---------------------------------------------------+ 236 Authority | | 237 +---------------------------------------------------+ 238 Additional | | 239 +---------------------------------------------------+ 241 or with the following incremental message: 243 +---------------------------------------------------+ 244 Header | OPCODE=SQUERY, RESPONSE | 245 +---------------------------------------------------+ 246 Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | 247 +---------------------------------------------------+ 248 Answer | JAIN.AD.JP. IN SOA serial=3 | 249 | JAIN.AD.JP. IN SOA serial=1 | 250 | NEZU.JAIN.AD.JP. IN A 133.69.136.5 | 251 | JAIN.AD.JP. IN SOA serial=2 | 252 | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | 253 | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | 254 | JAIN.AD.JP. IN SOA serial=2 | 255 | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | 256 | JAIN.AD.JP. IN SOA serial=3 | 257 | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | 258 | JAIN.AD.JP. IN SOA serial=3 | 259 +---------------------------------------------------+ 260 Authority | | 261 +---------------------------------------------------+ 262 Additional | | 263 +---------------------------------------------------+ 265 or with the following condensed incremental 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 SOA serial=1 | 274 | NEZU.JAIN.AD.JP. IN A 133.69.136.5 | 275 | JAIN.AD.JP. IN SOA serial=3 | 276 | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | 277 | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | 278 | JAIN.AD.JP. IN SOA serial=3 | 279 +---------------------------------------------------+ 280 Authority | | 281 +---------------------------------------------------+ 282 Additional | | 283 +---------------------------------------------------+ 285 or, if UDP packet overflow occurs, with the following message: 287 +---------------------------------------------------+ 288 Header | OPCODE=SQUERY, RESPONSE | 289 +---------------------------------------------------+ 290 Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | 291 +---------------------------------------------------+ 292 Answer | JAIN.AD.JP. IN SOA serial=3 | 293 +---------------------------------------------------+ 294 Authority | | 295 +---------------------------------------------------+ 296 Additional | | 297 +---------------------------------------------------+ 299 8. Acknowledgements 301 The original idea of IXFR was conceived by Anant Kumar, Steve Hotz 302 and Jon Postel. 304 For the refinement of the protocol and documentation, many people 305 have contributed including, but not limited to, Anant Kumar, Robert 306 Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the 307 members of the IETF DNSIND working group. 309 9. References 311 [NOTIFY] Vixie, P., "DNS NOTIFY: a mechanism for prompt notification 312 of zone changes", work in progress as . 315 [STD13] Mockapetris, P., "Domain Name System" (RFC1034 and RFC1035), 316 November 1987. 318 10. Security Considerations 320 Though DNS is related to several security problems, no attempt is 321 made to fix them in this document. 323 This document is believed to introduce no additional security 324 problems to the current DNS protocol. 326 11. Author's Address 328 Masataka Ohta 329 Computer Center, Tokyo Institute of Technology 330 2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN 332 Phone: +81-3-5734-3299, Fax: +81-3-5734-3415 333 EMail: mohta@necom830.cc.titech.ac.jp