idnits 2.17.1 draft-ietf-dnsext-rfc1995bis-ixfr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 23, 2012) is 4386 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) == Missing Reference: 'RFCthis' is mentioned on line 1301, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-dnsext-rfc2671bis-edns0-08 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dnsext-rfc2671bis-edns0' ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) ** Obsolete normative reference: RFC 6195 (Obsoleted by RFC 6895) -- Obsolete informational reference (is this intentional?): RFC 5966 (Obsoleted by RFC 7766) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSext Working Group A. Hoenes 3 Internet-Draft TR-Sys 4 Obsoletes: 1995 (if approved) O. Sury 5 Intended status: Standards Track CZ.NIC 6 Expires: October 25, 2012 S. Kerr 7 ISC 8 April 23, 2012 10 DNS Incremental Zone Transfer Protocol (IXFR) 11 draft-ietf-dnsext-rfc1995bis-ixfr-01 13 Abstract 15 The standard means within the Domain Name System protocol for 16 maintaining coherence among a zone's authoritative name servers 17 consists of three mechanisms. Incremental Zone Transfer (IXFR) is 18 one of the mechanisms and originally was defined in RFC 1995. 20 This document aims to provide a more detailed and up-to-date 21 specification of the IXFR mechanism and to align it with the current 22 specification of the primary zone transfer mechanism, AXFR, given in 23 RFC 5936. Further, based on operational experience, this document 24 juxtaposes to the original IXFR query a new query type, IXFR-ONLY, 25 that will likely be preferred over IXFR in specific deployments. 27 This document obsoletes and replaces RFC 1995. 29 Discussion 31 Comments should be sent to the authors and/or the dnsext mailing 32 list. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 25, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Overview of DNS Zone Synchronization . . . . . . . . . . . 4 81 1.2. Incremental Zone Transfer (IXFR) - Conclusions from 82 Experience . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 84 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 85 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 2. Principles of IXFR Protocol Operation . . . . . . . . . . . . 7 87 3. IXFR Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 88 3.1. IXFR Query . . . . . . . . . . . . . . . . . . . . . . . . 12 89 3.1.1. Header Values . . . . . . . . . . . . . . . . . . . . 12 90 3.1.2. Question Section . . . . . . . . . . . . . . . . . . . 12 91 3.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . 12 92 3.1.4. Authority Section . . . . . . . . . . . . . . . . . . 12 93 3.1.5. Additional Section . . . . . . . . . . . . . . . . . . 13 94 3.2. IXFR Response . . . . . . . . . . . . . . . . . . . . . . 13 95 3.2.1. Header Values . . . . . . . . . . . . . . . . . . . . 14 96 3.2.2. Question Section . . . . . . . . . . . . . . . . . . . 15 97 3.2.3. Answer Section . . . . . . . . . . . . . . . . . . . . 15 98 3.2.4. Authority Section . . . . . . . . . . . . . . . . . . 16 99 3.2.5. Additional Section . . . . . . . . . . . . . . . . . . 16 100 3.3. Connection Aborts . . . . . . . . . . . . . . . . . . . . 16 101 4. Response Contents . . . . . . . . . . . . . . . . . . . . . . 16 102 4.1. Incremental Responses . . . . . . . . . . . . . . . . . . 20 103 5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 105 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 6.2. Purging Strategy . . . . . . . . . . . . . . . . . . . . . 23 107 6.3. Optional Condensation of Zone Changes . . . . . . . . . . 23 108 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 24 109 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 25 110 7.1. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . 25 111 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 26 112 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 113 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 114 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 116 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 117 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 118 Appendix A. Motivation for IXFR-ONLY . . . . . . . . . . . . . . 30 119 Appendix B. Substantial Changes Since RFC 1995 . . . . . . . . . 31 120 Appendix C. Change Log of WG Draft . . . . . . . . . . . . . . . 32 121 C.1. Draft Version 00 -> 01 . . . . . . . . . . . . . . . . . . 32 123 1. Introduction 125 1.1. Overview of DNS Zone Synchronization 127 The Domain Name System (DNS) standard facilities for maintaining 128 coherent servers for a zone consist of three elements. Authoritative 129 Transfer (AXFR) originally was defined in STD 13: "Domain Names - 130 Concepts and Facilities" [RFC1034] (referred to in this document as 131 RFC 1034) and "Domain Names - Implementation and Specification" 132 [RFC1035] (henceforth RFC 1035), and is now precisely specified in 133 "DNS Zone Transfer Protocol (AXFR)" [RFC5936] (henceforth RFC 5936). 134 Incremental Transfer (IXFR) was originally defined in "Incremental 135 Zone Transfer in DNS" [RFC1995]. A mechanism for prompt notification 136 of zone changes (NOTIFY) is defined in "A Mechanism for Prompt 137 Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of 138 these mechanisms is to enable a set of DNS name servers to remain 139 coherently authoritative for a given zone. 141 For large domains that incur frequent changes that need to be 142 available quickly to prospective DNS clients, AXFR has proven less 143 suitable because it always transfers the whole zone content. The 144 latency incurred in the propagation of changes to the DNS database 145 ([RFC1034], [RFC1035]) can be substantially reduced in such scenarios 146 by actively notifying secondary servers of the availability of a new 147 version of the authoritative zone data at the primary server for a 148 zone; this is accomplished by the DNS NOTIFY mechanism [RFC1996]. 149 The time and resources needed to accomplish the transfer of the new 150 zone content to the secondary servers in many cases can be reduced 151 substantially by only carrying forward the changes from a previous 152 version of the zone data. This is accomplished by the IXFR mechanism 153 originally specified in RFC 1995 [RFC1995] and, more precisely, in 154 this document. 156 1.2. Incremental Zone Transfer (IXFR) - Conclusions from Experience 158 The original specification for IXFR [RFC1995] has widely been 159 perceived as not precise and detailed enough to ensure interoperable 160 implementations, and multiple reports have been made to DNS working 161 groups of observed IXFR implementation behavior that was not regarded 162 as conformant with the spirit of the specification, as seen by the 163 rough consensus of the community. Therefore, this document aims at 164 giving a much more detailed and precise specification for the IXFR 165 protocol, incorporating experience from more than a decade and 166 evolved points of view -- in particular regarding security aspects of 167 DNS operations. Implementations of this RFC are fully backward 168 compatible with "proper" implementations of RFC 1995, but conformant 169 implementations follow some more specific requirements included in 170 this RFC to improve the performance and resilience of IXFR sessions. 172 The original IXFR automatically falls back to AXFR behavior whenever 173 the IXFR server cannot fulfill the given delta-update request. In 174 some deployments, in particular where multiple IXFR servers are 175 available to the IXFR client, this can lead to premature fallback to 176 AXFR-like behavior whenever the chosen IXFR server does not have the 177 wanted delta-update information available, but another possible IXFR 178 server would, which incurs the additional overhead that the client 179 wanted to avoid whenever possible by his initial choice to use IXFR. 180 This gap is closed by a variant of the IXFR mechanism, dubbed 181 "IXFR-ONLY", which originally has been proposed in "IXFR-ONLY to 182 Prevent IXFR Fallback to AXFR" [I-D.kerr-ixfr-only] and which is 183 fully specified below as well. 185 Thus, this document re-specifies the IXFR mechanism as it is deployed 186 in the Internet at large, giving more details than in the original 187 specification, and using RFC 5936 as its foundation. Additionally, 188 it newly specifies a versatile variant of IXFR, IXFR-ONLY. 190 This document is organized as follows: After presenting the 191 terminology used and elaborations on the scope of this protocol and 192 its specification in the next subsections, Section 2 gives an 193 overview on the principles of operation of the IXFR protocol. 194 Section 3 normatively specifies the IXFR query and response message 195 format and the basic rules governing their generation and processing. 196 Subsequent sections detail mandatory and optional server behavior, 197 and they supply management, security, and IANA considerations. 199 1.3. Requirements Language 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in BCP 14, "Key words for 204 use in RFCs to Indicate Requirement Levels" [RFC2119]. 206 1.4. Terminology 208 This document freely makes use of basic DNS terminology as introduced 209 in RFCs 1034 and 1035 ([RFC1034], [RFC1035]) and clarified and 210 expanded upon in RFCs 2181 and 4033 ([RFC2181], [RFC4033]). 212 The terms "AXFR server", "AXFR client", "AXFR session", "General- 213 purpose DNS implementation" and "Turnkey DNS implementation" are used 214 as defined in Section 1.1 of RFC 5936 [RFC5936]. This document also 215 adopts the typographical (letter case) conventions agreed upon there 216 for denoting fields/parts of DNS messages -- cf. Section 3. 218 The bare term "IXFR" is intended to refer to the generic case of an 219 IXFR or IXFR-ONLY query/response, unless it is clear from the context 220 that the original IXFR Q-Type is dealt with specifically. 222 An "IXFR client" is a (secondary) name server for a given DNS zone 223 that, based on a trigger event, for instance a DNS NOTIFY message, 224 issues an IXFR query to a "superordinate" authoritative server (e.g., 225 the primary server of the zone) and receives the IXFR response from 226 it. 228 An "IXFR server" is an authoritative server that is presumed to 229 become aware of changes to a zone earlier than other authoritiative 230 servers, for instance the primary server for a zone as specified in 231 STD 13 or a secondary server that already has synchronized with the 232 primary server, and that is configured to respond to IXFR queries. 234 The interaction and protocol exchange(s) performed by an IXFR client 235 and an IXFR server to issue an IXFR query and accomplish its 236 processing are collectively denoted as an "IXFR session". 238 The behavior of an IXFR server falling back to full zone transfer 239 when incremental updates are unavailable or unpractical is denoted 240 (by common colloquial shorthand) as "Fallback to AXFR", although 241 technically, no AXFR pseudo-RRs are involved in this protocol 242 variant. (This is sketched in Section 2 and detailed in Section 4.) 244 1.5. Scope 246 In general terms, authoritative name servers for a given zone can use 247 various means to achieve coherency of the zone contents they serve. 248 For example, there are DNS implementations that assemble answers from 249 data stored in relational databases (as opposed to master files), 250 relying on the database's non-DNS means to synchronize the database 251 instances. Some of these non-DNS solutions interoperate in some 252 fashion. However, AXFR, IXFR, and NOTIFY are the only protocol- 253 defined in-band mechanisms to provide coherence of a set of name 254 servers, and they are the only mechanisms specified by the IETF. 256 This document does not cover incoherent DNS situations. There are 257 applications of the DNS in which servers for a zone are designed to 258 be incoherent. For these configurations, a coherency mechanism as 259 described here would be unsuitable. 261 IXFR is an optional protocol component for authoritiative DNS 262 servers; it is not needed on DNS resolver software that does not 263 support the functions of an authoritative DNS server. Thus, all 264 usage of normative BCP 14 [RFC2119] language is applicable only to 265 DNS server implementations that claim support of this specification. 267 Whereas the original IXFR protocol already is widely implemented, 268 IXFR-ONLY offers an operational choice for administrators of zones 269 with a non-trivial propagation graph for the authoritative zone data, 270 who are looking for more options to fine-tune the synchronization 271 efficiency of their authoritative servers. It could be implemented 272 without bare IXFR, but for the sake of backwards compatibility and 273 flexibility, and for simplicity in documentation, it is strongly 274 RECOMMENDED that IXFR-ONLY be always implemented in concert with bare 275 IXFR. 277 2. Principles of IXFR Protocol Operation 279 Each version of the authoritative data of a DNS zone is identified by 280 the SOA serial number (cf. Section 4.3.5 of [RFC1034] and Section 281 3.3.13 of [RFC1035]); successive zone versions are tagged with 282 monotonically increasing serial numbers. Note that, as spelled out 283 at the former citation, "Serial number advances and comparisons use 284 sequence space arithmetic", and IXFR implementations need to pay 285 particular attention to possible wraps. Below, serial numbers are 286 symbolically referred to by "sn", mostly with some distinguishing 287 postfix. 289 When an IXFR client currently serving, say, sn_o of a particular zone 290 receives a trigger that it should incrementally update the zone data, 291 it sends one of the two flavors of an IXFR request to an IXFR server, 292 with the expectation to obtain in the IXFR response the change 293 information necessary to transform the sn_o zone data into the zone 294 data of the current zone version, say, sn_n. 296 The details of which triggers can and will start such IXFR session 297 are implementation dependent. Possible triggers are some time 298 schedule or a management request, but most likely the IXFR query will 299 be triggered by a DNS NOTIFY message received from an authoritative 300 server of higher precedence in the propagation graph for the zone. 302 Possible IXFR servers are usually configured (per zone) on an IXFR 303 client, amended with some indication of precedence. Similarly, IXFR 304 servers are configured (per zone) with the identities of the 305 secondary servers they should accept as IXFR clients. This way, some 306 authoritative servers for a given zone may act both as an IXFR client 307 and an IXFR server. Among all authoritative servers for a zone, at 308 least one server (the primary server of the zone) is not acting as an 309 IXFR client. This way, the {IXFR server, IXFR client} pairs form a 310 binary relation on the set of these servers that defines a directed 311 graph rooted at the primary server(s); this is the IXFR propagation 312 graph for the zone. 314 Note that, for the purpose of IXFR, it is possible that more than 315 one server can be acting as a primary server; this requires that 316 zone synchronization between these servers is accomplished by 317 other mechanisms, e.g., AXFR, or non-DNS means like distributed 318 database technology. 320 The most simple propagation graph is a star (hub and spokes) 321 configuration, with the primary server as the central hub. For 322 redundancy, important zones with many authoritative servers are 323 likely to be configured with a more dense propagation graph that, for 324 the sake of resilience and/or load sharing, gives IXFR clients a 325 choice of multiple IXFR servers to contact. All these configuration 326 details are a strictly local matter and do not affect 327 interoperability; hence, these details are out of scope for this 328 specification. The only property of the propagation graph that needs 329 to be ensured by the zone administration is that each secondary 330 (i.e., non-primary) server must be reachable by at least one path in 331 this graph that originates in a primary server. 333 In order to be able to act as a useful IXFR server, a DNS server 334 needs to keep track of the zone history, to a certain extent (as 335 directed by local policy, as well). To this end, the server must 336 maintain knowledge of the changes that have been applied successively 337 to the zone content from one SOA serial up to the current version. 338 This does not necessarily mean that each change needs to be recorded, 339 however; if some parts of the zone content change frequently, it 340 might be preferable to coalesce subsequent chunks of change 341 information -- both for local storage and/or for transmission --, for 342 instance instead of the change information from sn_1 to sn_2 and the 343 change information from sn_2 to sn_3 (where sn_1 < sn_2 < sn_3), the 344 change information from sn_1 to sn_3 can be provided. This 345 condensation of data has some downsides, however: if an IXFR client 346 serves sn_2 and asks an IXFR server for the delta information to the 347 current version of the zone, but the server has performed the above 348 condensation, it has no way to tell the necessary information to the 349 IXFR client, and the IXFR request necessarily is doomed to fail. 350 Therefore, it becomes apparent that an IXFR server must maintain 351 seemless chains of change information chunks from all past SOA serial 352 number values it wants/needs to support (because potential IXFR 353 clients currently serve these zone versions) to the current zone 354 version. See Section 6.3 for more details on Condensation. 356 Upon receipt of any IXFR query, the IXFR server conceptionally 357 constructs a chain of change information chunks from the SOA serial 358 number indicated by the client (sn_o) to the current zone version 359 (sn_n). 361 If this is not possible, in the case of bare IXFR, the server falls 362 back to AXFR, i.e. it provides the full zone content. In the case of 363 an IXFR-ONLY query, however, an error response SHOULD be returned 364 immediately to the IXFR client, thus giving it a chance to try with 365 an alternate IXFR server that might (still) serve the client's sn_o 366 and not to immediately incur the potential overhead of a full zone 367 transfer. However, if the full zone content would fit into a single 368 response packet over UDP, an IXFR server MAY refrain from signalling 369 an error in response to an IXFR-ONLY query and behave as if the query 370 had been IXFR. This is allowed because, in this case, the full IXFR 371 transaction can be executed in a single packet exchange and an error 372 return would necessitate more messages and hence cause additional 373 overhead and delay, contrary to the performance optimization goal of 374 IXFR-ONLY. 376 In case it turns out that the IXFR client already has the current 377 zone version (sn_o = sn_n) or even a more recent one (sn_o > sn_n), 378 the IXFR server does not reply with an empty chain of chunks, but 379 with only the (current) SOA record of the zone. 381 If the IXFR server determines that it would be inefficient to 382 transfer the series of chunks, it also may fall back to full zone 383 transfer. Note that this is recommended behavior for the IXFR 384 server, but the correct protocol operation does not depend on this 385 (useful) optimization. 387 Ordinarily, in the generic case, the IXFR server transmits the change 388 information chunks in their "natural" order (by ascending sn) to the 389 IXFR client. 391 Each such change information chunk -- say from sn_a to sn_b -- is 392 represented (conceptionally and on the wire) by a sequence of RR 393 deletions and a sequence of subsequent RR additions, all of which 394 need to be applied in order to transform the zone content at sn_a to 395 the zone content at sn_b. For transfer in the IXFR response, each 396 sequence starts with the corresponding SOA RR as its delimiter, and 397 the other RRs within it can be given in arbitrary order. 399 The whole chain of change information chunks is embedded in a pair of 400 copies of the new SOA RR (at sn_n), which serve as "sentinels". It 401 is important to point out that the SOA RR is used only as a marker in 402 this context and it can appear multiple times, as opposed to an 403 RRSIG(SOA) RR, which is treated as a common record and needs to 404 appear only once in the zone. That also means that an RRSIG(SOA) RR 405 for sn_o has to be deleted and an RRSIG(SOA) RR for sn_n has to be 406 added. In other words, any RRSIG(SOA) doesn't get any special 407 treatment in the context of IXFR, and SOA RRs are used as 408 "sentinels". 410 For example, if the IXFR server wants to transmit the changes from 411 sn_o to sn_n in three chunks, based on two intermediary zone versions 412 at sn_1 and sn_2 (where sn_o < sn_1 < sn_2 < sn_n), i.e., the chunk 413 with the change information from sn_o to sn_1, the chunk from sn_1 to 414 sn_2, and the chunk from sn_2 to sn_n, it would deliver in the 415 incremental IXFR response packet(s) the following resource records 416 (RRs), in order: 418 * SOA for sn_n # outer bracket 419 * SOA for sn_o # start of first chunk 420 * {0 or more other RRs to be deleted from the zone at sn_o} 421 * SOA for sn_1 422 * {0 or more other RRs to be added for getting the zone at sn_1} 423 * SOA for sn_1 # start of second chunk 424 * {0 or more other RRs to be deleted from the zone at sn_1} 425 * SOA for sn_2 426 * {0 or more other RRs to be added for getting the zone at sn_2} 427 * SOA for sn_2 # start of third chunk 428 * {0 or more other RRs to be deleted from the zone at sn_2} 429 * SOA for sn_n 430 * {0 or more other RRs to be added for getting the zone at sn_n} 431 * SOA for sn_n # outer bracket 433 In contrast, in the case of fallback to AXFR, the IXFR response would 434 convey, in order: 436 * SOA for sn_n # first instance 437 * {one or more other RRs of the zone at sn_n, in arbitrary order} 438 * SOA for sn_n # repeated as trailing delimiter 440 3. IXFR Messages 442 This section specifies the format of IXFR messages and the basic 443 message generation and processing rules. 445 An IXFR session is started with an IXFR query message sent from an 446 IXFR client to an IXFR server, which solicits one or more response 447 messages in return. 449 All these messages adhere to the basic DNS message format as 450 specified in RFC 1035 and later amended in various ways, for which 451 Section 2 of RFC 5936 gives an expanded bibliography. Implementers 452 should be aware of the considerations in RFC 5452, "Measures for 453 Making DNS More Resilient against Forged Answers" [RFC5452], and 454 follow the recommendations given there. 456 For convenience of the reader, the synopsis of the DNS message header 457 from RFC 6195 [RFC6195] (and the IANA registry for DNS Parameters 458 [DNSVALS]) is reproduced here informally: 460 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 461 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 462 | ID | 463 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 464 |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | 465 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 466 | QDCOUNT/ZOCOUNT | 467 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 468 | ANCOUNT/PRCOUNT | 469 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 470 | NSCOUNT/UPCOUNT | 471 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 472 | ARCOUNT | 473 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 475 This document makes use of the field names as they appear in this 476 diagram. The names of sections in the body of DNS messages are 477 capitalized in this document for clarity, e.g., "Additional section". 479 An IXFR session can be carried out over UDP (with tight restrictions 480 -- see below) and over TCP. Thus, the DNS message size limit from 481 RFC 1035 for DNS over UDP (and its extension specified in 482 RFC 2671bis, "Extension Mechanisms for DNS (EDNS0)" 483 [I-D.ietf-dnsext-rfc2671bis-edns0]) apply in the former case. 484 BCP 145, "Unicast UDP Usage Guidelines for Application Designers" 485 [RFC5405] contains valuable considerations regarding IP level 486 fragmentation of UDP messages, and RFC 6274, "Security Assessment of 487 the Internet Protocol Version 4" [RFC6274] contains a detailed 488 security assessment of IPv4 segmentation and reassembly; both 489 documents should be considered by implementers when deciding on the 490 maximum size of DNS response messages over UPD supported by an IXFR 491 server implementation. The upper limit on the permissible size of a 492 DNS message over TCP is only restricted by the TCP framing defined in 493 Section 4.2.2 of RFC 1035, which specifies a two-octet message length 494 field, understood to be unsigned, and thus causing a limit of 65535 495 octets. This limit is not changed by EDNS0, and it applies to IXFR 496 over TCP. 498 Note that, independent of transport, the standard DNS message 499 (name) compression facility (Section 4.1.4 of RFC 1035 [RFC1035]) 500 severely limits the utility of DNS message sizes above 16k octets. 501 The additional header overhead resulting from limiting IXFR 502 response messages to 16k is negligible in comparison to the 503 overhead resulting from the loss of ability to apply message 504 compression in larger records. 506 3.1. IXFR Query 508 An IXFR query is sent by a client whenever it wants to obtain the 509 delta information needed to update the content of a zone it is aware 510 of (as identified by its SOA serial number) to the most recent 511 version. The predominant trigger for this is the receipt of a DNS 512 NOTIFY message [RFC1996], but it also can be triggered by other 513 mechanisms or events, for instance as a result of a command line 514 request, say for debugging. The details for these triggers are 515 implemenation dependent and out of scope for this specification. 517 3.1.1. Header Values 519 The specification for AXFR query messages in Section 2.1.1 of RFC 520 5936 applies likewise for IXFR queries, with a single exception: 522 NSCOUNT Number of entries in Authority section; MUST be 1 524 3.1.2. Question Section 526 The Question section of an IXFR query MUST conform to Section 4.1.2 527 of RFC 1035, and it MUST contain (matching QDCOUNT=1 in the DNS 528 message header) a single resource record with the following values: 530 QNAME the name of the zone requested 532 QTYPE one of the two pseudo-RR types for incremental zone 533 transfer: IXFR (= 251) or IXFR-ONLY (= {TBD1}) 534 [DNSVALS] 536 QCLASS the class of the zone requested [DNSVALS] 538 The choice of QTYPE depends on the intended IXFR server behavior in 539 case the request cannot be fulfilled due to lack of stored 540 information on the server, as detailed below in Section 3.2. 542 3.1.3. Answer Section 544 The Answer section MUST be empty, as indicated by ANCOUNT=0 in the 545 DNS message header. 547 3.1.4. Authority Section 549 Corresponding to NSCOUNT=1 in the DNS message header, the Authority 550 section MUST contain a single DNS resource record, the SOA record of 551 the client's version of the zone content, identified by its serial 552 number (denoted as sn_o in this document). 554 3.1.5. Additional Section 556 Currently, two kinds of resource records are defined that can appear 557 in the Additional section of IXFR queries and responses: EDNS and DNS 558 transaction security. Future specifications defining RRs that can be 559 carried in the Additional section of normal DNS transactions need to 560 explicitly describe their use with IXFR, should that be desired. 562 All considerations from Section 2.1.5 of RFC 5936 apply in the same 563 manner for IXFR as they do for AXFR. 565 In order to support the extended RCODE assigned for CannotIXFR, EDNS0 566 support (RFC 2671bis [I-D.ietf-dnsext-rfc2671bis-edns0]) is REQUIRED 567 for IXFR-ONLY, and an IXFR-ONLY query MUST be sent with an EDNS OPT 568 RR in the Additional section of the query. Receipt of such query 569 without an OPT RR SHOULD result in an error response with FormErr 570 RCODE. 572 3.2. IXFR Response 574 An IXFR server that has received an IXFR query responds to it with an 575 IXFR response addressed to the transport source identifier from which 576 the query has been received, in particular using the same transport 577 protocol. 579 An IXFR response consists of one or more response messages. If the 580 IXFR query has been received over a connectionless transport 581 (currently: UDP), the IXFR response MUST consist of a single message. 582 If it is not possible to send the complete response in a single DNS 583 message, a response MUST be sent that only contains the currrent SOA 584 RR at the server; whose serial sn_n being larger than sn_o (in 585 sequence space arithmetics) is the signal to the IXFR client to retry 586 over connection-oriented transport (currently: TCP). 588 The conceptional "answer" carried in a multi-message response is the 589 concatenation of the content of the Answer sections in these response 590 messages, in the order they are sent; this is unambiguous from the 591 point of view of the IXFR client as well, since the applicable 592 connection-oriented transport preserves the order of messages sent. 594 If the server detects an error condition that makes it impossible to 595 fulfill the request, it immediately sends an error response, that is 596 a response message with non-zero RCODE. In case of connectionless 597 transport (UDP), this is the single response message sent. In case 598 of connection-oriented transport (TCP), the error condition might 599 occur after one or more response messages already have been sent; in 600 this case, the error message is sent as soon as need arises, and it 601 will abort the ongoing IXFR session; i.e., the error message is the 602 last response message sent by the server. The special case of a 603 server closing the TCP connection without sending an IXFR response 604 message is covered in Section 3.3. 606 If an IXFR server is not able or willing to send the incremental zone 607 change information to transform the client's version (sn_o) to its 608 newer version (sn_n), the behavior is specified as follows: In the 609 case of QTYPE=IXFR, the server SHOULD fall back to AXFR (see below). 610 In the case of QTYPE=IXFR-ONLY, it SHOULD respond with an appropriate 611 error, e.g., CannotIXFR (see below); however, in the (rather 612 unlikely) corner case where a full zone transfer can be sent in a 613 single response packet over connectionless transport (UDP), the IXFR 614 server MAY instead proceed to send this even in response to an 615 IXFR-ONLY query; doing so helps to achieve the overall performance 616 optimization goals of IXFR-ONLY. 618 Any IXFR response that is neither an immediate error response nor a 619 redirection to connection-oriented transport starts with the server's 620 version of the SOA resource record, sn_n, and its kind can be 621 determined from the second answer RR, if any. (See Sections 3.2.3 622 and 4 for a detailed discussion.) 623 If the server detects that the client's version is current (sn_o = 624 sn_n) or already is more recent than at the server (sn_o > sn_n), or 625 if the server detects that the entire response to an IXFR query 626 received over connectionless transport (UDP) cannot be placed into a 627 single response message, this SOA record is the only answer RR sent 628 to the client. Otherwise, the subsequent answer RRs sent form a 629 sequence of one or more change information chunks as described below 630 in Section 4, and the final "sentinel" RR sent is another copy of the 631 current SOA RR (sn_n). 632 In case of fallback to AXFR, the answer contains the same RRs (and is 633 subject to the same ordering rules) as specified in Sections 2.2 634 through 3 of RFC 5936, with the single difference being the echoed 635 QCODE (i.e., IXFR, or exceptionally -- as noted above -- IXFR-ONLY) 636 in the Question section. 638 3.2.1. Header Values 640 The specification for AXFR in Section 2.2.1 of RFC 5936 applies 641 likewise for IXFR queries, where in the case of IXFR the "new" 642 behavior from RFC 5936 is always followed, i.e. the query ID from the 643 IXFR query MUST be echoed in all IXFR response messages. 645 Note that unlike with all common DNS responses, but like AXFR, the 646 IXFR protocol makes no use of the TC (truncation) bit. To signal 647 that an IXFR session needs to be retried over TCP, an IXFR server 648 sends a response that in the Answer section solely contains its 649 current version of the SOA RR for the zone. 651 The only additonal rule to be followed applies to the deliberations 652 on the RCODE field in Note e) of Section 2.2.1 in RFC 5936: If the 653 IXFR server is not able to fulfill an IXFR-ONLY request, it SHOULD 654 respond with the extended RCODE CannotIXFR assigned on behalf of this 655 document (see Section 10); see above for the exceptional corner case 656 that allows to waive this requirement. 658 Note that only the lower 4 bits of the conceptual RCODE can be 659 carried in the RCODE message header field; the upper bits need to 660 be placed into the EXTENDED-RCODE subfield of the "TTL" field in 661 the OPT RR that, in this case, is REQUIRED in the Additional 662 section of the response -- see Section 6.1.3 of RFC 2671bis 663 [I-D.ietf-dnsext-rfc2671bis-edns0]. 665 3.2.2. Question Section 667 In the first response message, the IXFR server MUST copy this section 668 literally from the corresponding IXFR query message. For subsequent 669 response messages, it MAY do the same or leave the Question section 670 empty. However, if the last response message sent is an error 671 message (RCODE unequal to 0), the query MUST also be copied. 672 Accordingly, QDCOUNT in the DNS message header is set to either 1 673 (query copied) or 0 (otherwise). 675 When it is present, the content of this section MAY be used to 676 determine the context of the message, that is, the name of the zone 677 being transferred. The recipent (IXFR client) SHOULD apply the 678 response verification rules from RFC 5452 [RFC5452]. 680 Subsequent response messages with empty Question section are 681 demultiplexed (among all open DNS transactions being carried out on a 682 given transport connection, which already identifies the peer) to the 683 proper IXFR session by means of the ID message header field only. 685 3.2.3. Answer Section 687 The Answer section MUST be populated with the zone change information 688 or, in the case of fallback to AXFR, the full zone contents. 690 For multi-message IXFR responses, the conceptional answer is split 691 into segments that are sent in order. Each segment is comprised of 692 an integer number of full RRs, and for transport efficiency, the 693 response messages SHOULD be filled up with answer RRs as much as 694 possible for the response message size chosen by the IXFR server, 695 taking into account the space needed for the other sections in the 696 messages. 698 If an IXFR server intends to send a conceptual IXFR response that is 699 comprised of at least two answer RRs, the first two answe RRs of the 700 response MUST be sent in the first response packet to allow the IXFR 701 client to immediately distinguish the kind of response coming in. An 702 IXFR server MUST NOT send over connection-oriented transport the kind 703 of (single-RR) IXFR response that indicates that the server has to 704 send a multi-packet response and hence the IXFR request needs to be 705 retried over connection-orientend transport (currently: TCP); this 706 kind of response is only allowed in response to an IXFR query 707 received over connectionless transport (currently: UDP). 709 See Section 4 below for the normative details of the various kinds of 710 conceptual IXFR responses and the respective resource record ordering 711 requirements, as well as how an IXFR client distinguishes these 712 response kinds. 714 3.2.4. Authority Section 716 Corresponding to NSCOUNT=0 in the DNS message header, the Authority 717 section in IXFR response messages MUST be empty. 719 3.2.5. Additional Section 721 All considerations from Section 2.2.5 (and hence, by reference, also 722 Section 2.1.5) of RFC 5936 apply in the same manner for IXFR as they 723 do for AXFR. See also Section 3.1.5 of this document. 724 Note that hereby the rules for any DNS transactional security 725 meta-RRs (SIG(0)/TSIG) applicable for AXFR are implicitly extended 726 to apply to multi-message IXFR responses as well; in the absence 727 of explicit specification saying otherwise, this also holds for 728 future DNS transactional security methods (if any). 730 3.3. Connection Aborts 732 In case of an IXFR session carried over connection-oriented transport 733 (TCP), the considerations in Section 2.3 of RFC 5936 [RFC5936] apply 734 similarly. 736 In a nutshell: Servers SHOULD avoid dropping active connections 737 whenever possible, and clients nevertheless must be prepared to 738 gracefully deal with such aborts. 740 4. Response Contents 742 This section describes the structure of the sequence of resource 743 records (RRs) sent in IXFR reponses and how the IXFR client can 744 immediately distinguish the various cases covered. 746 The possible IXFR responses can be classified into various kinds of 747 responses by the number of answer RRs in the conceptual response. 749 (1) immediate-error: empty answer, non-zero RCODE; 751 (2) you-are-current: single SOA RR for sn_o = sn_n, RCODE = NoError; 753 (3) you-are-more-recent: single SOA RR for sn_o > sn_n, RCODE = 754 NoError; 756 (4) redirect-to-conn: single SOA RR for sn_o < sn_n, RCODE = 757 NoError; 759 (5) incremental: multiple RRs, starting and ending with the SOA RR 760 for sn_n (where sn_o < sn_n), which enclose a sequence of one 761 or more change information chunks, the first of which starts 762 with the SOA RR for sn_o (which consequentially is different 763 from sn_n); 764 this is detailed below in Section 4.1 765 (if need arises, a packetized incremental response can be 766 aborted in the second or later response message by sending an 767 empty Answer section and non-zero RCODE); 769 (6) full-xfr: multiple RRs, starting and ending with the SOA RR for 770 sn_n (where sn_o < sn_n), enclosing a serialization of all 771 other RRs in the zone for sn_n; this enclosed sequence of RRs 772 is non-empty -- since any zone needs to contain at least one 773 non-SOA RR, namely an NS RR --, does not contain any other SOA 774 RR, and thus cannot start with another SOA RR; 775 this is detailed in [RFC5936] 776 (if need arises, a packetized full-xfr response can be aborted 777 in the second or later response message by sending an empty 778 Answer section and non-zero RCODE). 780 If the IXFR server discovers an error condition before it sends the 781 first (or only) response message, the response content in the Answer 782 section is empty, and consequentially, ANCOUNT is set to 0 in that 783 message ("immediate-error" response, kind (1) above). 785 Otherwise, the response content starts with a copy of the current SOA 786 RR at the IXFR server (sn_n). There are several cases: 788 a. The server serial (sn_n) is the same as the client serial (sn_o) 789 sent in the Authority section of the IXFR query. In this case, 790 this SOA RR is the only RR in the response message, indicating to 791 the IXFR client that it already has the current zone content 792 ("you-are-current" response, kind (2) above). 794 b. The server serial (sn_n) is older than the client serial (sn_o) 795 sent in the Authority section of the IXFR query, and this SOA RR 796 is the only RR in the response message. This indicates that the 797 zone content held at the IXFR server actually lags behind the 798 IXFR client, and so the IXFR server cannot provide an update to 799 the zone data at the client ("you-are-more-recent" response, kind 800 (3) above). 802 c. The server serial (sn_n) is newer than the client serial (sn_o) 803 sent in the Authority section of the IXFR query, and this SOA RR 804 is the only RR in the response message. This indicates to the 805 IXFR client that its zone content is outdated and the IXFR server 806 is willing to send the incremental zone change information, but 807 is unable to do so in a single response message due to message 808 size limitations. 810 An IXFR server MUST NOT send this type of IXFR response over 811 connection-oriented transport (TCP), but it MAY use this type of 812 response over connectionless transport (UDP) to indicate to the 813 IXFR client that it should retry the IXFR query over connection- 814 oriented transport ("redirect-to-conn" response, kind (4) above). 816 An IXFR client that receives over connection-oriented transport 817 an IXFR response message (as the first response message related 818 to its IXFR query) that contains only a single SOA RR with sn_n 819 higher than sn_o MUST discard the response message (see below). 821 Note again that the "truncated response message" mechanism 822 specified in RFC 1035, which is signalled by setting the TC bit 823 in a response message, MUST NOT be used in an IXFR response. An 824 IXFR client that receives an IXFR response message with the TC 825 bit set MUST discard the message (see below for details). 827 d. The server serial (sn_n) is newer than the client serial (sn_o) 828 sent in the Authority section of the IXFR query, and this SOA RR 829 is followed by another SOA RR in the same response message. In 830 this case, the IXFR response is an incremental response (kind (5) 831 above), as detailed in Section 4.1 below. 833 If this second SOA RR also is for sn_n, a robust IXFR client will 834 assume that the server exposes behavior arguably not explicitly 835 forbidden in RFC 1995 to signal case (a) above. Hence, an IXFR 836 client MAY accept for resiliency an IXFR response with exactly 837 these two copies of the same SOA RR sent in a single response 838 message as an "empty incremental response" indicating that the 839 client's version of the zone is current; otherwise, the client 840 MUST discard a response starting with two copies of the sn_n SOA 841 RR. 843 Otherwise, if the second SOA RR is for sn_o, this indicates the 844 start of an ordinary incremental response as detailed below. 846 Otherwise (if the second SOA RR is for sn_x that differs from 847 both sn_o (as sent by the client) and sn_n (in the first SOA RR), 848 the client MUST discard the response message as bogus. 850 e. The server serial (sn_n) is newer than the client serial (sn_o) 851 sent in the Authority section of the IXFR query, and this SOA RR 852 is followed by another, non-SOA RR in the same response message. 854 This indicates a non-incremental response ("full-xfr" response, 855 kind (6) above, colloquially "fallback to AXFR"). In this case, 856 the response content is structured like an AXFR response, as 857 described in RFC 5936 ("new" behavior, no backward compatibility 858 kludges admitted); following the initial SOA RR it contains the 859 entire zone content besides the SOA RR and ends with a second 860 copy of the sn_n SOA RR as an end-of-response marker. 862 Such non-incremental IXFR response MUST NOT be sent in response 863 to an IXFR-ONLY query unless the entire intended response -- up 864 to and including the trailing sentinel sn_n SOA RR -- fits into a 865 single response message with a size that allows it to be sent 866 over connectionless transport (UDP), or would have allowed that 867 if it actually is carried over connection-oriented transport 868 (TCP). An IXFR client that receives an incomplete initial IXFR 869 response message that indicates such non-incremental response to 870 an IXFR-ONLY query MUST discard the message as bogus. 872 An IXFR client MUST discard any IXFR response that does not match one 873 of the forms described as kinds (1) through (6) above and is not 874 recognized by the above decision tree. 876 Whenever in the above cases the text says that the IXFR client "MUST 877 discard the message", the following behavior is implied: The IXFR 878 client MUST regard the IXFR session as terminated; this results in 879 subsequent silent discarding of further response messages that still 880 pretend to belong to the same IXFR session by means of the query ID 881 and the echoed Question (if present), because the IXFR client does 882 not maintain corresponding IXFR query/session state any more. The 883 IXFR client MAY log the event and SHOULD regard the IXFR server as 884 broken; hence, it SHOULD refrain from using the same IXFR server 885 again -- at least for considerable time, or until the usage has been 886 reinstated by an implementation-dependent management interaction. 888 From the above decision tree for the client it also follows that, to 889 allow unambiguous client behavior, if an IXFR server has to send a 890 response comprised of two or more RRs, it MUST send at least the 891 first two RRs in the first response message, as specified in 892 Section 3.2.3 above. 894 If the IXFR server discovers an error condition lately, after having 895 sent one or more response messages (all with RCODE set to 0), it can 896 abort the IXFR session by sending another response message with empty 897 Answer section and a non-zero RCODE. This MUST be the last message 898 sent in response to the IXFR query, that is, this error message 899 aborts the ongoing IXFR session. 901 The above rules ensure that an IXFR client can unambiguously 902 determine the kind of IXFR response from the first response message 903 alone. This encludes the ability to immediately detect the end of 904 any legitimate single-message IXFR response. An IXFR session with a 905 multi-message IXFR response ends when either 906 o a late error message arrives, i.e., a response message with non- 907 zero RCODE -- such message has an empty Answer section so that 908 there's no ambiguity as to which answer RRs might be regarded as 909 somehow valid anyhow (see Section 7.1 for the possible treatment 910 of RRs received previously in such IXFR session); or 911 o in the case of an incremental response, the third instance of the 912 SOA RR for sn_n is found in the answer (see Section 4.1 for the 913 rationale); or 914 o in the case of a non-incremental response, the second instance of 915 the SOA RR for sn_n is found in the answer. 916 Recall that in the second and third case, the SOA RR for sn_n was the 917 first RR sent in the first response message. If in these two cases, 918 the received response message contains more, extraneous RRs past that 919 sentinel SOA RR, an IXFR client MAY regard the entire response (or 920 the not yet committed part of the response, according to Section 7.1) 921 as bogus (see above); if the client accepts an otherwise consistent 922 response under these circumstances, it MUST discard the extraneous 923 RRs, and it MAY log the error and take 'discard' actions as above. 925 4.1. Incremental Responses 927 In an incremental response, the leading sn_n SOA RR is followed by 928 one or more change information chunks and concluded by a final copy 929 of the sn_n SOA RR -- in total, from the details given below, it 930 turns out that this is always exactly the third instance of that SOA 931 RR in the IXFR response. 933 Each change information chunk describes the changes to be performed 934 on a given "origin" version of the zone to obtain a "target" version 935 of the zone (i.e., one SOA serial change of the zone). It consists 936 of (1) a set of old RRs to be deleted from the "origin" zone version 937 and (2) a set of new RRs to be added after these deletions to obtain 938 the "target" version of the zone. (In this model, a change in a 939 single RR is represented by an RR deletion followed by an RR 940 addition.) These two sets are sent in this order, with each set 941 serialized as a sequence of the related SOA RR followed by other, 942 non-SOA RRs in a arbitrary order. This way, each SOA RR indicates 943 the end of the sequence of (zero or more) non-SOA RRs that precedes 944 it, and at the same time it either starts the next set of RRs or is 945 the trailing sn_n SOA of the response. 947 The "origin" sn of each change information chunk MUST precede its 948 "target" sn in the sense of sequence number arithmentics. 950 The change information chunks in an incremental response MUST be 951 ordered oldest first, newest last; in more detail: The first change 952 information chunk in an incremental response must have the client's 953 version (sn_o) as its origin sn; the origin sn of each subsequent 954 change information chunk MUST be the same as the target sn of the 955 preceding chunk, and the last change information chunk in an 956 incremental response MUST have the server's version (sn_n) as its 957 target sn. This "chaining" of chunks ensures that the client can 958 correctly construct the sn_n version from the sn_o version it holds 959 by conceptionally applying single-RR deletions and additions in the 960 order the RRs appear in the IXFR response. 962 Note that, as a consequence of the aforementioned rules, a valid 963 incremental IXFR response MUST contain exactly one copy of the sn_o 964 SOA RR (sent as the second RR in the response) and exactly three 965 copies of the sn_n SOA RR -- one as the first RR in the response, one 966 as the leading RR of the second sequence (set of RRs to be added) in 967 the last change information chunk, and one as the final "sentinel" RR 968 that indicates the end of the response contents. Likewise, each 969 "intermediate" SOA RR (with sn_o < sn < sn_n) will appear exactly 970 twice, once in the second part (new RRs) of a particular change 971 information chunk, and once in the first part of the immediately 972 following change information chunk. 974 Any IXFR response classified as a (non-empty) incremental response by 975 the decision tree presented above in Section 4 that violates any of 976 the above rules MUST cause the IXFR client to regard the response as 977 bogus; it MUST discard a response message in case its content allows 978 the client to detect such violation, with the caveats for "discard" 979 given in Section 4. 981 5. Transport 983 IXFR servers and IXFR clients MUST support transport over UDP and TCP 984 (see RFC 5966 [RFC5966]). As with all DNS transactions, IXFR 985 responses MUST be sent on the same transport association over which 986 the query arrives at the server. 988 If an IXFR server cannot send a full IXFR response for an IXFR query 989 received over UDP within a single response message over UDP due to 990 message size limitations, it MUST return the special form of response 991 that indicates to the client to retry over TCP (single-RR response 992 with the server SOA only, as described in Sections 3.2 and 4). 994 Given the limitation of the basic DNS message size over UDP to 512 995 octets, it is strongly RECOMMENDED that implementations of IXFR 996 servers and IXFR clients support RFC 2671bis, "Extension Mechanisms 997 for DNS (EDNS0)" [I-D.ietf-dnsext-rfc2671bis-edns0] and choose 998 extended DNS message size limits appropriate for their environment. 999 The default behavior of IXFR clients regarding the EDNS message size, 1000 and the maximum accepted by servers, SHOULD both be configurable. 1002 The considerations for AXFR transport over TCP in Section 4 of RFC 1003 5936 [RFC5936] apply similarly for IXFR. However, IXFR is commonly 1004 being used much more frequently than AXFR between a given pair of 1005 authoritiative servers, and often not authorized for use by servers 1006 outside the set of authorities for a zone, which are all under the 1007 control of a single administrative domain or a small number of 1008 cooperating administrative domains. In this environment, it might 1009 make sense for the sake of efficiency to maintain (and reuse) 1010 persistent TCP connections between the configured IXFR peers. 1011 Therefore, implementations of IXFR should allow to configure 1012 relatively high TCP User Timeout values and support the TCP UTO 1013 mechanism ([RFC5482]) that allows the peers to exchange their view of 1014 the TCP User Timeout and adapt the behavior of their TCP accordingly. 1015 To minimize unnecessary delays, IXFR server implementations SHOULD 1016 use available API functions to cause their TCP stacks to immediately 1017 dispatch for sending the first and last packet of any IXFR response 1018 and cause these to be delivered immediately to the recipient; for 1019 instance, immediate sending and setting of the 'PSH' TCP header flag 1020 in outgoing packets can often be achieved using the TCP_NODELAY 1021 socket option. 1023 6. Server Behavior 1025 6.1. General 1027 General considerations on IXFR server behavior, in particular 1028 response message generation and packet processing, are spread all 1029 over this document; in particular, see Sections 3.2 and 4. 1031 In addition to the current zone content, IXFR servers need to 1032 maintain history information on the zone content that enables them to 1033 respond with incremental responses for a sufficient range of 1034 versions. What is considered "sufficient" and how this history 1035 information is maintained, is a local matter. It may be appropriate 1036 to maintain the history information on stable storage as well to make 1037 it available spanning restarts of an IXFR server, as it is already 1038 required for the current zone content. 1040 6.2. Purging Strategy 1042 An IXFR server cannot be required to hold all previous versions 1043 forever and may delete them anytime. In general, there is a trade- 1044 off between the size of storage space and the possibility and need of 1045 using IXFR. 1047 Information about older versions should be purged as soon as the 1048 total length of an IXFR response would otherwise become larger than 1049 that of an AXFR response. Given that the purpose of IXFR is to 1050 reduce AXFR overhead, this strategy is quite reasonable. The 1051 strategy assures that the amount of storage required is at most twice 1052 that of the current zone information. 1054 Information older than the SOA expire period may also be purged. 1056 Once the current serial number of a zone advances so far that older 1057 serial numbers can no more be recognized immediately as older 1058 versions (under the rules of sequence space arithmetics), such 1059 previous versions MUST NOT be held available any more for IXFR 1060 purposes. In order to account for the propagation delay along the 1061 IXFR distribution graph, use of a reasonable safety margin against 1062 this hard limit has proven to be a good strategy for defensive 1063 implementation practice -- for instance implementations could limit 1064 the maximum serial number span made available for IXFR to a specific 1065 fraction of the 32-bit serial number range, e.g., one fourth (2^30). 1067 The Condensation techniques explored below in Section 6.3 might pose 1068 an opportunity to get rid of more recent, yet less relevant history 1069 information and as such might allow to cover a larger span of SOA 1070 versions than otherwise possible within the same amount of storage. 1072 6.3. Optional Condensation of Zone Changes 1074 An IXFR server MAY optionally condense a number of immediately 1075 succeeding change information chunks into a single chunk, thus 1076 dropping information on intermediate zone versions. 1078 This may be beneficial if a lot of versions, not all of which are 1079 useful, are generated. For example, if multiple ftp servers share a 1080 single DNS name and the IP address associated with the name is 1081 changed once a minute to balance load between the ftp servers, it is 1082 not so important to keep track of all the history of changes. 1084 Another example is where statefully managed client systems get IP 1085 addresses assigned dynamically by DHCP servers, and where the DHCP 1086 server(s) and/or the clients register their current contact 1087 information via DNS UPDATE whenever leases are given out or renewed. 1088 These transactions could be comprised of several independent update 1089 steps, for forward and reverse address resolution, for service 1090 discovery, etc., where multiple parts of the related information are 1091 maintained in the same zone. Intelligent condensation strategies 1092 might be able to identify subsequent incremental changes related to a 1093 single end-user system and collapse this information in a single 1094 change information chunk. 1096 But this feature may not be so useful if an IXFR client has access to 1097 two IXFR servers, A and B, with inconsistent condensation results. 1098 The current version of the IXFR client, received from server A, may 1099 be unknown to server B. In such a case, server B cannot provide 1100 incremental data from the unknown version and a full zone transfer is 1101 necessary. Therefore, it is highly desirable that alternative IXFR 1102 servers for a given set of IXFR clients expose similar (or at best, 1103 the same) condensation behavior. 1105 Condensation can be performed in two stages, perhaps in a 1106 complementary manner: Firstly, the history information stored on an 1107 IXFR server can be condensed to reduce storage requirements *and* 1108 IXFR response sizes to some degree. Additionally, IXFR servers can 1109 perform condensation "on the fly" in preparing IXFR responses; this 1110 might provide additional savings in IXFR response size while reducing 1111 the likelihood that IXFR queries cannot be responded with incremental 1112 responses due to the requested sn being "condensed out" of the stored 1113 history information. 1115 Condensation is completely optional. Clients cannot detect from the 1116 response whether or not the server has condensed the reply. 1118 For interoperability, IXFR servers, including those without the 1119 condensation feature, SHOULD NOT send an error response in case they 1120 receive a client's IXFR request with an unknown version number and 1121 SHOULD, instead, attempt to perform a full zone transfer. Of course, 1122 this in general does not apply if the client indicates its desire to 1123 try its luck in such case at another candidate IXFR server, by 1124 initiating the request with IXFR-ONLY (the single exception to this 1125 general case is the corner case discussed in Section 3.2). 1127 6.4. Authorization 1129 The considerations for AXFR presented in Section 5 of RFC 5936 1130 [RFC5936] apply in a similar fashion for IXFR. 1132 Given the basic desire for frequent use and the resulting processing 1133 load, operational considerations will, even more likely than for 1134 AXFR, dictate the need to closely restrict the usage of IXFR to the 1135 set of authoritiative servers for a given zone, and to precisely 1136 configure the IXFR distribution graph within the set of servers, by 1137 means of access lists on the server side and by configuring a 1138 prioritized IXFR server search list on the client side. 1140 Since IP addresses can be spoofed rather trivially in large parts of 1141 the open Internet, better authentication methods are needed as a base 1142 for authorization decisions unless the IXFR distribution graph can be 1143 restricted to protected networks under control of the same 1144 administration as the participating DNS servers. 1146 In particular, as detailed in the Section of RFC 5936 quoted above, 1147 implementations of IXFR SHOULD also support at least one flavor of 1148 DNS transaction security. Virtual private networks, virtual LANs, 1149 IPsec ([RFC4301]), and TCP-AO ([RFC5925] might also be applicable 1150 solutions to ensure proper authentication to base authorization 1151 decisions on. See Section 9 for more information. 1153 7. Client Behavior 1155 It is RECOMMENDED that IXFR client implementations supporting 1156 IXFR-ONLY allow to configure its usage per IXFR server, as part of 1157 the IXFR distribution graph configuration. 1159 An IXFR client SHOULD set an appropriate guard timeout whenever the 1160 content of a response message indicates that this is not the final 1161 message of an IXFR response. In case this timeout period elapses 1162 without another response message arriving, it SHOULD regard the IXFR 1163 session as failed and apply the caveats for the "discard" case 1164 presented in Section 4. 1166 If it is known to the IXFR client that an IXFR server conforms to the 1167 refined IXFR specification in this RFC, the guard timeout can be 1168 chosen rather large because the kind of IXFR response is 1169 unambiguously indicated in the first response message and the timing 1170 of the subsequent packet flow should be left to the connection- 1171 oriented transport in use, and the timeout only serves as a "last 1172 defense" in case of fatal failures not detected by the transport. 1174 7.1. Zone Integrity 1176 The elaborations on Zone Integrity for AXFR in Section 6 of RFC 5936 1177 [RFC5936] apply in a similar fashion for IXFR. 1179 However, during the receipt of an incremental IXFR response, and upon 1180 successful processing of an SOA RR that serves as a sentinel for the 1181 end of any change information chunk, an IXFR client MAY immediately 1182 apply and commit to stable storage the SOA serial number change 1183 described by that chunk (and previous chunks, if not already done). 1184 This operation MUST externally appear as an atomar operation. 1186 Before this operation can be attempted, the IXFR client SHOULD apply 1187 all feasable sanity checks for the change information chunk under 1188 consideration. In particular, it SHOULD verify that the RRs 1189 contained in the first part of the chunk (those to be deleted) are 1190 indeed literally contained in the data set for the most recent zone 1191 version the client has constructed so far. If a DNSSEC-aware IXFR 1192 client receives an IXFR response for a zone secured with DNSSEC 1193 [RFC4033], it MAY try to verify any RRSIG RR for the new zone SOA 1194 (received in the second part of the change information chunk), as 1195 another means to detect forged responses, and in case of failure 1196 forcibly abort the IXFR session. However, in order to avoid DoS 1197 attacks targeted at processing resources and amplification attacks, 1198 this SHOULD NOT be done if the IXFR session is secured by other means 1199 (in-band by TKEY/TSIG, in lower layers, e.g. by IPsec or other VPN 1200 technology) or if the necessary keys are unavailable (not already 1201 cached) and/or not already verified. Similarly, like in the case of 1202 AXFR, it is generally NOT RECOMMENDED to perform a full cryptographic 1203 verification of the new zone version -- which would consume very 1204 substantial computing resources, hence clearing the way for another 1205 type of DoS attack. 1207 8. Backwards Compatibility 1209 Despite a few potentially misleading statements in the previous 1210 specification, only a single detail has been identified so far that 1211 could give rise to backward compatibility concerns. This is 1212 addressed by the compatibility rules in Section 4 that allow an IXFR 1213 client to process an "empty incremental response" consisting of only 1214 a pair of instances of the server's SOA RR. 1216 The clarified and slightly tightened packetization requirements 1217 contained in Section 3.2.3 might cause an IXFR client to reject a 1218 poorly packetized multi-packet response previously sometimes regarded 1219 as acceptable under RFC 1995. An IXFR client implementation MAY 1220 provide a configuration option (globally, or per IXFR server) to 1221 admit such inefficient behavior on the server side, in which case it 1222 needs to wait for a second response message before it can distinguish 1223 unambiguously all response kinds (including protocol violations). In 1224 deployment scenarios with multiple candidate IXFR servers where 1225 expeditious switching to an alternate IXFR server (if needed) is 1226 intended, activation of such option would be detrimental. 1228 The introduction of IXFR-ONLY creates further interoperability 1229 considerations. An IXFR server utilizing IXFR-ONLY may receive an 1230 error response different from CannotIXFR persistently. (The actual 1231 RCODE reveived may depend on whether or not the server is aware of 1232 the allocation of the range of RR types set aside for Q-Types in 1233 [RFC6195] (and its predecessors), from which the IXFR-ONLY code point 1234 has been assigned.) This event likely indicates that the IXFR server 1235 chosen does not support IXFR-ONLY. In such case, the client will 1236 mark the server as "unusable of IXFR-ONLY" in his server list and try 1237 another potential IXFR server, or, if all candidates fail, retry the 1238 scan with bare IXFR, or alternatively try to immediately start an 1239 AXFR session. The latter should always be the method of last resort 1240 in case of persistent IXFR failures. 1242 9. Security Considerations 1244 This document presents a more detailed specification for the 1245 mechanism previously specified in RFC 1995, which has similar 1246 protocol behavior and security properties as the AXFR mechanism 1247 described in RFC 5936. Hence, beyond the general security 1248 considerations for the DNS laid down in RFC 3833 [RFC3833], similar 1249 considerations apply. 1251 Thus, the sections on Transport, Authorization and Zone Integrity 1252 that all include by reference the respective sections of RFC 5936 1253 [RFC5936] largely address the relevant concerns. Deployments of IXFR 1254 might be interested in using large values for the EDNS message size 1255 and thereby become more exposed to the various security threats 1256 against IP fragmentation; these and suitable mitigations are 1257 discussed in [RFC6274]. 1259 Since IXFR is likely to be used in a more frequent and continuous 1260 manner and hence a possible candidate for making use of long-lived, 1261 persistent TCP connections for its transport, besides IPsec (RFC 4301 1262 [RFC4301]), the more lightweight TCP Authentication mechanism 1263 described in RFC 5925 (TCP-AO, [RFC5925]) might, once deployed, be a 1264 suitable candidate for peer authentication and integrity protection 1265 of IXFR sessions. 1267 10. IANA Considerations 1269 The IANA Registry "Domain Name System (DNS) Parameters" [DNSVALS] 1270 contains a sub-registry "Resource Record (RR) TYPEs", in which 1271 [RFC6195] has reserved the range 128 through 255 for pseudo-RRs only 1272 being used in DNS queries, for short "Q-Types". This partial 1273 namespace is managed under the "DNS RRTYPE Allocation Policy" 1274 specified in RFC 6195 [RFC6195]. 1276 [[ This paragraph to be deleted on publication as an RFC ]] 1277 IANA and IESG: based on the provisions of RFC 6195, we ask for RFC 1278 4020 early allocation of the two code points needed for this memo, as 1279 described below. 1281 Since RFC 1995, the Q-Type 251 has been assigned to IXFR. Upon 1282 publication of this memo as an RFC, IANA will update / has updated 1283 the description for that entry to say "incremental zone transfer" and 1284 the Reference for that entry to point to this RFC. 1286 Upon publication of this memo as an RFC, IANA also will assign / has 1287 assigned the Q-Type {TBD1} to the TYPE mnemonic IXFR-ONLY, with 1288 description "incremental zone transfer w/o fallback", and pointing to 1289 this memo. 1291 The IANA Registry "Domain Name System (DNS) Parameters" [DNSVALS] 1292 contains a sub-registry "DNS RCODEs", which is managed under "IETF 1293 Review" assignment policy, as specified in RFC 6195 [RFC6195]. IANA 1294 is requested to allocate / has allocated from that sub-registry a new 1295 Extended RCODE value (above 16, only usable with EDNS) for 1296 CannotIXFR: 1298 RCODE Name Description Reference 1299 Decimal 1300 --------- ---------- ---------------------------------- --------- 1301 {TBD2} CannotIXFR IXFR not possible, would fall back [RFCthis] 1303 11. Acknowledgements 1305 Masataka Ohta is acknowledged for his original work as the author of 1306 RFC 1995 [RFC1995], as are the contributors listed in the 1307 Acknowledgements section of that RFC. Andreas Gustafsson has 1308 initiated the first attempt to clarify RFC 1995 in November 1999 and 1309 contributed text to the DNSIND WG for a proposed document revision. 1310 Masataka Ohta's subsequent draft [OLD-IXFRbis] has not been pursued 1311 until RFC publication; thanks to Andreas for eventually bringing this 1312 earlier work to the attention of the authors of this memo. 1314 The specification of IXFR-ONLY in this document is based on the 1315 original proposal [I-D.kerr-ixfr-only], in which the operational need 1316 for this behavior has been identified and carried into the IETF. 1318 The DNSEXT working group and its predecessor (DNSIND) are 1319 acknowledged for their discussion on the above documents. 1320 Substantial text has been borrowed from there and from [RFC5936]. 1322 Discussions of the draft on the dnsext list have directed the 1323 evolution of this document; in particular, we acknowledge (in 1324 alphabetical order) Mark Andrews, Ray Bellis, Brian Dickson, Andreas 1325 Gustafsson, Shane Kerr, Warren Kumari, Edward Lewis, Josh 1326 Littlefield, Masataka Ohta, Paul Vixie, Florian Weimer, and Wouter 1327 Wijngaards for their comments and reviews. 1329 12. References 1331 12.1. Normative References 1333 [I-D.ietf-dnsext-rfc2671bis-edns0] 1334 Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1335 for DNS (EDNS0)", draft-ietf-dnsext-rfc2671bis-edns0-08 1336 (work in progress), February 2012. 1338 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1339 STD 13, RFC 1034, November 1987. 1341 [RFC1035] Mockapetris, P., "Domain names - implementation and 1342 specification", STD 13, RFC 1035, November 1987. 1344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1345 Requirement Levels", BCP 14, RFC 2119, March 1997. 1347 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1348 for Application Designers", BCP 145, RFC 5405, 1349 November 2008. 1351 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 1352 Resilient against Forged Answers", RFC 5452, January 2009. 1354 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 1355 (AXFR)", RFC 5936, June 2010. 1357 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA 1358 Considerations", BCP 42, RFC 6195, March 2011. 1360 12.2. Informative References 1362 [DNSVALS] IANA Registry, "Domain Name System (DNS) Parameters", 1363 protocol parameter registry available at:, 1364 . 1366 [I-D.kerr-ixfr-only] 1367 Sury, O. and S. Kerr, "IXFR-ONLY to Prevent IXFR Fallback 1368 to AXFR", draft-kerr-ixfr-only-01 (work in progress), 1369 February 2010. 1371 [OLD-IXFRbis] 1372 Ohta, M., "Incremental Zone Transfer in DNS", 1373 draft-ietf-dnsext-ixfr-01 (work in progress), June 2000. 1375 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1376 August 1996. 1378 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1379 Changes (DNS NOTIFY)", RFC 1996, August 1996. 1381 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1382 Specification", RFC 2181, July 1997. 1384 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1385 Name System (DNS)", RFC 3833, August 2004. 1387 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1388 Rose, "DNS Security Introduction and Requirements", 1389 RFC 4033, March 2005. 1391 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1392 Internet Protocol", RFC 4301, December 2005. 1394 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 1395 RFC 5482, March 2009. 1397 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1398 Authentication Option", RFC 5925, June 2010. 1400 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 1401 Requirements", RFC 5966, August 2010. 1403 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 1404 Version 4", RFC 6274, July 2011. 1406 Appendix A. Motivation for IXFR-ONLY 1408 IXFR is an efficient means to transfer changes in zones from IXFR 1409 servers to IXFR clients. However, when an IXFR client has multiple 1410 IXFR servers for a single zone, it is possible that not all IXFR 1411 servers hold the zone content with the same serial number(s). In 1412 this case, if an IXFR client attempts an IXFR from an IXFR server 1413 that does not have the zone content with the serial number used by 1414 the IXFR client, the IXFR server will fall back to a full zone 1415 transfer (like in AXFR) when it has a version of the zone with serial 1416 number greater than the serial requested by the IXFR client. 1418 For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for 1419 a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the 1420 same zone. An IXFR client that has the zone content with serial 1421 number 2 and sends an IXFR request to IXFR server NS2 will get a full 1422 zone transfer (AXFR style) of the zone at serial number 3. This is 1423 because NS2 does not know the zone with serial number 2, and 1424 therefore is not able to report the differences between the zone with 1425 serial number 2 and 3. 1427 If the IXFR client in this example had known to send the query to 1428 IXFR server NS1, then it could have gotten an incremental transfer. 1429 But an IXFR clients can only know what the *latest* version of the 1430 zone is at an IXFR server -- this information is available via an SOA 1431 query. 1433 The IXFR-ONLY query type provides a way for the IXFR client to ask 1434 each IXFR server to return an error instead of sending the current 1435 version of the zone via full zone transfer. By using this, an IXFR 1436 client can check each IXFR server until it finds one able to actually 1437 provide an incremental transfer. If it doesn't succeed, it can fall 1438 back and try with bare IXFR instead of IXFR-ONLY, or it can 1439 immediately start an AXFR session with an AXFR server of its choice 1440 (the preferred AXFR server might be distinct from the most prefered 1441 IXFR server). 1443 By providing IXFR-ONLY support, the policy control over the zone 1444 synchronization operation switches to the client side, which is 1445 preferable under various operational settings. 1447 Appendix B. Substantial Changes Since RFC 1995 1449 This is a summary of the substantial changes since RFC 1995 1450 [RFC1995]. 1452 o Corrected a few technical flaws: incorrect comparison with AXFR; 1453 improper implied requirement of performing SOA query over UDP; 1454 improper reference to transfer of partial RRs in a response 1455 message corrected (to be read as transfer of partial RRsets in a 1456 response message -- as it has always been understood by 1457 implementers, since STD 13 requires only entire RRs to be present 1458 in DNS messages). 1460 o New specification based on the revised AXFR specification, 1461 RFC 5936 [RFC5936]. 1463 o Slightly tightened packetization requirements for multi-packet 1464 responses to ensure more timely client-side processing (immediate 1465 determination of kind of response based upon first response 1466 packet, faster determination of protocol violations). 1468 o Many clarifications and details supplied, text vastly reorganized 1469 and expanded, but no other (intentional) technical deviation from 1470 the previous specification, as understood by implementers. 1472 o Addition of new IXFR-ONLY protocol variant, based on operational 1473 experience and perceived need. 1475 o Major additions to Security Considerations. 1477 o Historical example dropped (incompatible with IESG policy on 1478 examples). Instead, abstract examples have been added to 1479 Section 2. 1481 Appendix C. Change Log of WG Draft 1483 [[ Entire section to be deleted before publication as an RFC. ]] 1485 The changes of the individual draft (draft-ah-dnsext-rfc1995bis-ixfr) 1486 up to adoption as a WG draft (draft-ietf-dnsext-rfc1995bis-ixfr-00) 1487 are detailed in Appendix C of the latter, but not reproduced below 1488 any more. 1490 C.1. Draft Version 00 -> 01 1492 o Removed text pertaining to individual draft stage. 1493 o Several text adoptions based on evaluation of previous work in 1494 DNSIND & DNSEXT (in 1999 & 2000) made available by Andreas 1495 Gustafsson. 1496 o Added more text to s1.2 regarding motivation for this memo. 1497 o Added to s1.4 hint to spelling conventions for DNS message parts 1498 (borrowed from RFC 5936); clarified there that IXFR is a Q-Type 1499 RR. 1500 o s2: Clarified preconditions on SOA serial numbers with quotes from 1501 STD 13; s6.2: IXFR server now MUST NOT hold available via IXFR 1502 zone versions that cannot clearly be recognized as older than the 1503 current version; with regard to propagation delays, text 1504 recommends safety margin: limit SOA serial span covered to e.g. 1505 1/4 of the serial number space (i.e. 2^30). 1506 o s2, s3.2, s4: Draft now accommodates the (hopefully rare) case of 1507 the IXFR server's zone being older than the version that the 1508 client has. 1509 o s2, s4: Draft now strictly follows RFC 5936 RR ordering 1510 requirements for non-incremental responses (i.e. no more 1511 recommendation for grouping RRs into RRsets). Example in s2 now 1512 also clearly indicates possibility of having zero "other" RRs to 1513 be deleted or to be added in a change information chunk. 1514 o Clarified which kinds of responses are covered by last para in 1515 s3.2. 1517 o s3.2, s3.2.1: Resolved text that has become inconsistent by the 1518 introduction (per the last individual draft version) of the 1519 (optional) exceptional single-packet non-incremental IXFR-ONLY 1520 response. 1521 o s3.2.2: Clarified that subsequent packets of multi-packet IXFR 1522 responses with empty Question section are demultiplexed into the 1523 appropriate IXFR session by only the DNS message header ID. 1524 o s3.2.3: Based on feedback emphasizing the importance of rules that 1525 ensure efficient protocol operation and thereby making the 1526 requirements at least as strong as for AXFR, the requirements on 1527 packetization of multi-packet IXFR responses have been clearly 1528 spelled out and clarified, making the requirements comparable of 1529 what is specified for AXFR in RFC 5936; previously, the slightly 1530 tightened requirements were arguably hidden in other parts of the 1531 text. 1532 o s3.2.5: Added explicit note regarding DNS transactional security. 1533 o s4: Added classification of IXFR response kinds. Updated decision 1534 tree to refer to these kinds. Added discussion of end-of-session 1535 detection for multi-packet IXFR responses. 1536 o s4.1: Dropped last para -- new packetization requirements now are 1537 limited to what is made explicit in s3.2.3. 1538 o s5: Added note on TCP_NODELY socket option / PSH flag for TCP. 1539 o s7: Added discussion of precautionary receive timeout. 1540 o s8: Added elaborations on backward compatibility regarding the 1541 slightly strenghtened packetization requirements from s3.2.3. 1542 o Updated Acknowledgements; added Informative Ref. to expired '2000 1543 IXFR-bis draft. 1544 o Addressed review comments from Lubos Slovak. 1545 o Updated Appendix B with regard to above changes. 1546 o Removed old Appendix C, added new Appendix C. 1547 o Numerous editorial corrections and improvements. 1549 Authors' Addresses 1551 Alfred Hoenes 1552 TR-Sys 1553 Gerlinger Str. 12 1554 Ditzingen D-71254 1555 Germany 1557 EMail: ah@TR-Sys.de 1558 Ondrej Sury 1559 CZ.NIC 1560 Americka 23 1561 120 00 Praha 2 1562 CZ 1564 Phone: +420 222 745 110 1565 EMail: ondrej.sury@nic.cz 1567 Shane Kerr 1568 ISC 1569 Bennebrokestraat 17-I 1570 Amsterdam NL-1015 PR 1571 Netherlands 1573 Phone: +31 64 6336297 1574 EMail: shane@isc.org