idnits 2.17.1 draft-ah-dnsext-rfc1995bis-ixfr-03.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 (March 9, 2012) is 4430 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 1143, 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: September 10, 2012 March 9, 2012 8 DNS Incremental Zone Transfer Protocol (IXFR) 9 draft-ah-dnsext-rfc1995bis-ixfr-03 11 Abstract 13 The standard means within the Domain Name System protocol for 14 maintaining coherence among a zone's authoritative name servers 15 consists of three mechanisms. Incremental Zone Transfer (IXFR) is 16 one of the mechanisms and originally was defined in RFC 1995. 18 This document aims to provide a more detailed and up-to-date 19 specification of the IXFR mechanism and to align it with the current 20 specification of the primary zone transfer mechanism, AXFR, given in 21 RFC 5936. Further, based on operational experience, this document 22 juxtaposes to the original IXFR query a new query type, IXFR-ONLY, 23 that will likely be preferred over IXFR in specific deployments. 25 This document obsoletes and replaces RFC 1995. 27 Discussion 29 This draft targets adoption by the DNSEXT working group. Comments 30 should be sent to the authors and/or the dnsext mailing list. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 10, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1. Overview of DNS Zone Synchronization . . . . . . . . . . . 4 80 1.2. Incremental Zone Transfer (IXFR) - Conclusions from 81 Experience . . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 83 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 84 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 2. Principles of IXFR Protocol Operation . . . . . . . . . . . . 6 86 3. IXFR Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 87 3.1. IXFR Query . . . . . . . . . . . . . . . . . . . . . . . . 12 88 3.1.1. Header Values . . . . . . . . . . . . . . . . . . . . 12 89 3.1.2. Question Section . . . . . . . . . . . . . . . . . . . 12 90 3.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . 12 91 3.1.4. Authority Section . . . . . . . . . . . . . . . . . . 12 92 3.1.5. Additional Section . . . . . . . . . . . . . . . . . . 13 93 3.2. IXFR Response . . . . . . . . . . . . . . . . . . . . . . 13 94 3.2.1. Header Values . . . . . . . . . . . . . . . . . . . . 14 95 3.2.2. Question Section . . . . . . . . . . . . . . . . . . . 15 96 3.2.3. Answer Section . . . . . . . . . . . . . . . . . . . . 15 97 3.2.4. Authority Section . . . . . . . . . . . . . . . . . . 15 98 3.2.5. Additional Section . . . . . . . . . . . . . . . . . . 16 99 3.3. Connection Aborts . . . . . . . . . . . . . . . . . . . . 16 100 4. Response Contents . . . . . . . . . . . . . . . . . . . . . . 16 101 4.1. Incremental Responses . . . . . . . . . . . . . . . . . . 18 102 5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 104 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 20 105 6.2. Purging Strategy . . . . . . . . . . . . . . . . . . . . . 21 106 6.3. Optional Condensation of Zone Changes . . . . . . . . . . 21 107 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 22 108 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 23 109 7.1. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . 23 110 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 24 111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 112 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 113 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 114 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 115 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 116 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 117 Appendix A. Motivation for IXFR-ONLY . . . . . . . . . . . . . . 27 118 Appendix B. Substantial Changes Since RFC 1995 . . . . . . . . . 28 119 Appendix C. Evaluation of List Discussion, Draft Changes 120 since -02 . . . . . . . . . . . . . . . . . . . . . . 29 122 1. Introduction 124 1.1. Overview of DNS Zone Synchronization 126 The Domain Name System (DNS) standard facilities for maintaining 127 coherent servers for a zone consist of three elements. Authoritative 128 Transfer (AXFR) originally was defined in STD 13: "Domain Names - 129 Concepts and Facilities" [RFC1034] (referred to in this document as 130 RFC 1034) and "Domain Names - Implementation and Specification" 131 [RFC1035] (henceforth RFC 1035), and is now precisely specified in 132 "DNS Zone Transfer Protocol (AXFR)" [RFC5936] (henceforth RFC 5936). 133 Incremental Transfer (IXFR) was originally defined in "Incremental 134 Zone Transfer in DNS" [RFC1995]. A mechanism for prompt notification 135 of zone changes (NOTIFY) is defined in "A Mechanism for Prompt 136 Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of 137 these mechanisms is to enable a set of DNS name servers to remain 138 coherently authoritative for a given zone. 140 For large domains that incur frequent changes that need to be 141 available quickly to prospective DNS clients, AXFR has proven less 142 suitable because it always transfers the whole zone content. The 143 latency incurred in the propagation of changes to the DNS database 144 ([RFC1034], [RFC1035]) can be substantially reduced in such scenarios 145 by actively notifying secondary servers of the availability of a new 146 version of the authoritative zone data at the primary server for a 147 zone; this is accomplished by the DNS NOTIFY mechanism [RFC1996]. 148 The time and resources needed to accomplish the transfer of the new 149 zone content to the secondary servers in many cases can be reduced 150 substantially by only carrying forward the changes from a previous 151 version of the zone data. This is accomplished by the IXFR mechanism 152 originally specified in RFC 1995 [RFC1995] and, more precisely, in 153 this document. 155 1.2. Incremental Zone Transfer (IXFR) - Conclusions from Experience 157 The original IXFR automatically falls back to AXFR behavior whenever 158 the IXFR server cannot fulfill the given delta-update request. In 159 some deployments, in particular where multiple IXFR servers are 160 available to the IXFR client, this can lead to premature fallback to 161 AXFR-like behavior whenever the chosen IXFR server does not have the 162 wanted delta-update information available, but another possible IXFR 163 server would, which incurs the additional overhead that the client 164 wanted to avoid whenever possible by his initial choice to use IXFR. 165 This gap is closed by a variant of the IXFR mechanism, dubbed 166 "IXFR-ONLY", which originally has been proposed in "IXFR-ONLY to 167 Prevent IXFR Fallback to AXFR" [I-D.kerr-ixfr-only] and which is 168 fully specified below as well. 170 Thus, this document re-specifies the IXFR mechanism as it is deployed 171 in the Internet at large, giving more details than in the original 172 specification, and using RFC 5936 as its foundation. Additionally, 173 it newly specifies a versatile variant of IXFR, IXFR-ONLY. 175 This document is organized as follows: After presenting the 176 terminology used and elaborations on the scope of this protocol and 177 its specification in the next subsections, Section 2 gives an 178 overview on the principles of operation of the IXFR protocol. 179 Section 3 normatively specifies the IXFR query and response message 180 format and the basic rules governing their generation and processing. 181 Subsequent sections detail mandatory and optional server behavior, 182 and they supply management, security, and IANA considerations. 184 1.3. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in BCP 14, "Key words for 189 use in RFCs to Indicate Requirement Levels" [RFC2119]. 191 1.4. Terminology 193 This document makes freely use of basic DNS terminology as introduced 194 in RFCs 1034 and 1035 ([RFC1034], [RFC1035]) and clarified and 195 expanded upon in RFCs 2181 and 4033 ([RFC2181], [RFC4033]). 197 The terms "AXFR server", "AXFR client", "AXFR session", "General- 198 purpose DNS implementation" and "Turnkey DNS implementation" are used 199 as defined in Section 1.1 of RFC 5936 [RFC5936]. 201 The bare term "IXFR" is intended to refer to the generic case of an 202 IXFR or IXFR-ONLY query/response, unless it is clear from the context 203 that the original IXFR is dealt with specifically. 205 An "IXFR client" is a (secondary) name server for a given DNS zone 206 that, based on a trigger event, for instance a DNS NOTIFY message, 207 issues an IXFR query to a "superordinate" authoritative server (e.g., 208 the primary server of the zone) and receives the IXFR response from 209 it. 211 An "IXFR server" is an authoritative server that is presumed to 212 become aware of changes to a zone earlier than other authoritiative 213 servers, for instance the primary server for a zone as specified in 214 STD 13 or a secondary server that already has synchronized with the 215 primary server, and that is configured to respond to IXFR queries. 217 The interaction and protocol exchange(s) performed by an IXFR client 218 and an IXFR server to issue an IXFR query and accomplish its 219 processing are collectively denoted as an "IXFR session". 221 The behavior of an IXFR server falling back to full zone transfer 222 when incremental updates are unavailable or unpractical is denoted 223 (by common colloquial shorthand) as "Fallback to AXFR", although 224 technically, no AXFR pseudo-RRs are involved in this protocol 225 variant. (This is sketched in Section 2 and detailed in Section 4 226 below.) 228 1.5. Scope 230 In general terms, authoritative name servers for a given zone can use 231 various means to achieve coherency of the zone contents they serve. 232 For example, there are DNS implementations that assemble answers from 233 data stored in relational databases (as opposed to master files), 234 relying on the database's non-DNS means to synchronize the database 235 instances. Some of these non-DNS solutions interoperate in some 236 fashion. However, AXFR, IXFR, and NOTIFY are the only protocol- 237 defined in-band mechanisms to provide coherence of a set of name 238 servers, and they are the only mechanisms specified by the IETF. 240 This document does not cover incoherent DNS situations. There are 241 applications of the DNS in which servers for a zone are designed to 242 be incoherent. For these configurations, a coherency mechanism as 243 described here would be unsuitable. 245 IXFR is an optional protocol component for authoritiative DNS 246 servers; it is not needed on DNS resolver software that does not 247 support the functions of an authoritative DNS server. Thus, all 248 usage of normative BCP 14 [RFC2119] language is applicable only to 249 DNS server implementations that claim support of this specification. 251 Whereas the original IXFR already is widely implemented, IXFR-ONLY 252 offers an operational choice for administrators of zones with a non- 253 trivial propagation graph for the authoritative zone data, who are 254 looking for more options to fine-tune the synchronization efficiency 255 of their authoritative servers. It could be implemented without bare 256 IXFR, but for the sake of backwards compatibility and flexibility, 257 and for simplicity in documentation, it is strongly RECOMMENDED that 258 IXFR-ONLY be always implemented in concert with bare IXFR. 260 2. Principles of IXFR Protocol Operation 262 Each version of the authoritative data of a DNS zone is identified by 263 the SOA serial number (cf. Section 3.3.13 of [RFC1035]); succesive 264 versions are tagged with monotonically increasing serial numbers. 266 Below, serial numbers are symbolically referred to by "sn". mostly 267 with some distinguishing postfix. 269 When an IXFR client currently serving, say, sn_o of a particular zone 270 receives a trigger that it should incrementally update the zone data, 271 it sends one of the two flavors of an IXFR request to an IXFR server, 272 with the expectation to obtain in the IXFR response the change 273 information necessary to transform the sn_o zone data into the zone 274 data of the current zone version, say, sn_n. 276 The details of which triggers can and will start such IXFR session 277 are implementation dependent. Possible triggers are some time 278 schedule or a management request, but most likely the IXFR query will 279 be triggered by a DNS NOTIFY message received from an authoritative 280 server of higher precedence in the propagation graph for the zone. 282 Possible IXFR servers are usually configured (per zone) on an IXFR 283 client, amended with some indication of precedence. Similarly, IXFR 284 servers are configured (per zone) with the identities of the 285 secondary servers they should accept as IXFR clients. This way, some 286 authoritative servers for a given zone may act both as an IXFR client 287 and an IXFR server. Among all authoritative servers for a zone, at 288 least one server (the primary server of the zone) is not acting as an 289 IXFR client. This way, the {IXFR server, IXFR client} pairs form a 290 binary relation on the set of these servers that defines a directed 291 graph rooted at the primary server(s); this is the IXFR propagation 292 graph for the zone. 294 Note that, for the purpose of IXFR, it is possible that more than 295 one server can be acting as a primary server; this requires that 296 zone synchronization between these servers is accomplished by 297 other mechanisms, e.g., AXFR, or non-DNS means like distributed 298 database technology. 300 The most simple propagation graph is a star (hub and spokes) 301 configuration, with the primary server as the central hub. For 302 redundancy, important zones with many authoritative servers are 303 likely to be configured with a more dense propagation graph that, for 304 the sake of resilience and/or load sharing, gives IXFR clients a 305 choice of multiple IXFR servers to contact. All these configuration 306 details are a strictly local matter and do not affect 307 interoperability; hence, these details are out of scope for this 308 specification. The only property of the propagation graph that needs 309 to be ensured by the zone administration is that each secondary 310 (i.e., non-primary) server must be reachable by at least one path in 311 this graph that originates in a primary server. 313 In order to be able to act as a useful IXFR server, a DNS server 314 needs to keep track of the zone history, to a certain extent (as 315 directed by local policy, as well). To this end, the server must 316 maintain knowledge of the changes that have been applied successively 317 to the zone content from one SOA serial up to the current version. 318 This does not necessarily mean that each change needs to be recorded, 319 however; if some parts of the zone content change frequently, it 320 might be preferable to coalesce subsequent chunks of change 321 information -- both for local storage and/or for transmission --, for 322 instance instead of the change information from sn_1 to sn_2 and the 323 change information from sn_2 to sn_3 (where sn_1 < sn_2 < sn_3), the 324 change information from sn_1 to sn_3 can be provided. This 325 condensation of data has some downsides, however: if an IXFR client 326 serves sn_2 and asks an IXFR server for the delta information to the 327 current version of the zone, but the server has performed the above 328 condensation, it has no way to tell the necessary information to the 329 IXFR client, and the IXFR request necessarily is doomed to fail. 330 Therefore, is becomes apparent that an IXFR server must maintain 331 seemless chains of change information chunks from all past SOA serial 332 number values it wants/needs to support (because potential IXFR 333 clients currently serve these zone versions) to the current zone 334 version. See Section 6.3 for more details on Condensation. 336 Upon receipt of any IXFR query, the IXFR server conceptionally 337 constructs a chain of change information chunks from the SOA serial 338 number indicated by the client (sn_o) to the current zone version 339 (sn_n). 341 If this is not possible, in the case of bare IXFR, the server falls 342 back to AXFR, i.e. it provides the full zone content. In the case of 343 an IXFR-ONLY query, however, an error response SHOULD be returned 344 immediately to the IXFR client, thus giving it a chance to try with 345 an alternate IXFR server that might (still) serve the client's sn_o 346 and not to immediately incur the potential overhead of a full zone 347 transfer. However, if the full zone content would fit into a single 348 response packet over UDP, an IXFR server MAY refrain from signalling 349 an error in response to an IXFR-ONLY query and behave as if the query 350 had been IXFR. This is allowed because, in this case, the full IXFR 351 transaction can be executed in a single packet exchange and an error 352 return would necessitate more messages and hence cause additional 353 overhead and delay, contrary to the performance optimization goal of 354 IXFR-ONLY. 356 In case it turns out that the IXFR client already has the current 357 zone version (sn_o = sn_n), the IXFR server does not reply with an 358 empty chain of chunks, but with the (current) SOA record of the zone. 360 If the IXFR server determines that it would be inefficient to 361 transfer the series of chunks, it also may fall back to full zone 362 transfer. Note that this is recommended behavior for the IXFR 363 server, but the correct protocol operation does not depend on this 364 (useful) optimization. 366 Ordinarily, in the generic case, the IXFR server transmits the change 367 information chunks in their "natural" order (by ascending sn) to the 368 IXFR client. 370 Each such change information chunk -- say from sn_a to sn_b -- is 371 represented (conceptionally and on the wire) by a sequence of RR 372 deletions and a sequence of subsequent RR additions, all of which 373 need to be applied in order to transform the zone content at sn_a to 374 the zone content at sn_b. For transfer in the IXFR response, each 375 sequence starts with the corresponding SOA RR as its delimiter, and 376 the other RRs within it can be given in arbitrary order. 378 The whole chain of change information chunks is embedded in a pair of 379 copies of the new SOA RR (at sn_n) that serve as "sentinels". It is 380 important to point out that the SOA RR is used only as a marker in 381 this context and it can appear multiple times, as opposed to an 382 RRSIG(SOA) RR, which is treated as a common record and needs to 383 appear only once in the zone. That also means that an RRSIG(SOA) RR 384 for sn_o has to be deleted and an RRSIG(SOA) RR for sn_n has to be 385 added. In other words, any RRSIG(SOA) doesn't get any special 386 treatment in the context of IXFR, and SOA RRs are used as 387 "sentinels". 389 For example, if the IXFR server wants to transmit the changes from 390 sn_o to sn_n in three chunks, based on two intermediary zone versions 391 at sn_1 and sn_2 (where sn_o < sn_1 < sn_2 < sn_n), i.e., the chunk 392 with the change information from sn_o to sn_1, the chunk from sn_1 to 393 sn_2, and the chunk from sn_2 to sn_n, it would deliver in the IXFR 394 response packet(s) the following resource records (RRs), in order: 396 * SOA for sn_n # outer bracket 397 * SOA for sn_o # start of first chunk 398 * {other RRs to be deleted from the zone at sn_o} 399 * SOA for sn_1 400 * {other RRs to be added for getting the zone at sn_1} 401 * SOA for sn_1 # start of second chunk 402 * {other RRs to be deleted from the zone at sn_1} 403 * SOA for sn_2 404 * {other RRs to be added for getting the zone at sn_2} 405 * SOA for sn_2 # start of third chunk 406 * {other RRs to be deleted from the zone at sn_2} 407 * SOA for sn_n 408 * {other RRs to be added for getting the zone at sn_n} 409 * SOA for sn_n # outer bracket 411 In contrast, in the case of fallback to AXFR, the IXFR response would 412 convey, in order: 414 * SOA for sn_n # first instance 415 * {DNSSEC signature RRs for the SOA, if any} 416 * {other RRsets of the zone at sn_n, in arbitrary order} 417 * SOA for sn_n # repeated as trailing delimiter 419 3. IXFR Messages 421 This section specifies the format of IXFR messages and the basic 422 message generation and processing rules. 424 An IXFR session is started with an IXFR query message sent from an 425 IXFR client to an IXFR server, which solicits one or more response 426 messages in return. 428 All these messages adhere to the basic DNS message format as 429 specified in RFC 1035 and later amended in various ways, for which 430 Section 2 of RFC 5936 gives an expanded bibliography. Implementers 431 should be aware of the considerations in "Measures for Making DNS 432 More Resilient against Forged Answers" [RFC5452] and follow the 433 recommendations given there. 435 For convenience of the reader, the synopsis of the DNS message header 436 from RFC 6195 [RFC6195] (and the IANA registry for DNS Parameters 437 [DNSVALS]) is reproduced here informally: 439 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 440 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 441 | ID | 442 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 443 |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | 444 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 445 | QDCOUNT/ZOCOUNT | 446 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 447 | ANCOUNT/PRCOUNT | 448 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 449 | NSCOUNT/UPCOUNT | 450 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 451 | ARCOUNT | 452 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 454 This document makes use of the field names as they appear in this 455 diagram. The names of sections in the body of DNS messages are 456 capitalized in this document for clarity, e.g., "Additional section". 458 An IXFR session can be carried out over UDP (with tight restrictions 459 -- see below) and over TCP. Thus, the DNS message size limit from 460 RFC 1035 for DNS over UDP (and its extension specified in 461 RFC 2671bis, "Extension Mechanisms for DNS (EDNS0)" 462 [I-D.ietf-dnsext-rfc2671bis-edns0]) apply in the former case. 463 BCP 145, "Unicast UDP Usage Guidelines for Application Designers" 464 [RFC5405] contains valuable considerations regarding IP level 465 fragmentation of UDP messages, and RFC 6274, "Security Assessment of 466 the Internet Protocol Version 4" [RFC6274] contains a detailed 467 security assessment of IPv4 segmentation and reassembly; both 468 documents should be considered by implementers when deciding on the 469 maximum size of DNS response messages over UPD supported by an IXFR 470 server implementation. The upper limit on the permissible size of a 471 DNS message over TCP is only restricted by the TCP framing defined in 472 Section 4.2.2 of RFC 1035, which specifies a two-octet message length 473 field, understood to be unsigned, and thus causing a limit of 65535 474 octets. This limit is not changed by EDNS0, and it applies to IXFR 475 over TCP. 477 Note that, independent of transport, the standard DNS message 478 (name) compression facility (Section 4.1.4 of RFC 1035 [RFC1035]) 479 severely limits the utility of DNS message sizes above 16k octets. 480 The additional header overhead resulting from limiting IXFR 481 response messages to 16k is negligible in comparison to the 482 overhead resulting from the loss of ability to apply message 483 compression in larger records. 485 3.1. IXFR Query 487 An IXFR query is sent by a client whenever it wants to obtain the 488 delta information needed to update the content of a zone it is aware 489 of (as identified by its SOA serial number) to the most recent 490 version. The predominant trigger for this is the receipt of a DNS 491 NOTIFY message [RFC1996], but it also can be triggered by other 492 mechanisms or events, for instance as a result of a command line 493 request, say for debugging. The details for these triggers are 494 implemenation dependent and out of scope for this specification. 496 3.1.1. Header Values 498 The specification for AXFR query messages in Section 2.1.1 of RFC 499 5936 applies likewise for IXFR queries, with a single exception: 501 NSCOUNT Number of entries in Authority section; MUST be 1 503 3.1.2. Question Section 505 The Question section of an IXFR query MUST conform to Section 4.1.2 506 of RFC 1035, and it MUST contain (matching QDCOUNT=1 in the DNS 507 message header) a single resource record with the following values: 509 QNAME the name of the zone requested 511 QTYPE one of the two pseudo-RR types for incremental zone 512 transfer: IXFR (= 251) or IXFR-ONLY (= {TBD1}) 513 [DNSVALS] 515 QCLASS the class of the zone requested [DNSVALS] 517 The choice of QTYPE depends on the intended IXFR server behavior in 518 case the request cannot be fulfilled due to lack of stored 519 information on the server, as detailed below in Section 3.2. 521 3.1.3. Answer Section 523 The Answer section MUST be empty, as indicated by ANCOUNT=0 in the 524 DNS message header. 526 3.1.4. Authority Section 528 Corresponding to NSCOUNT=1 in the DNS message header, the Authority 529 section MUST contain a single DNS resource record, the SOA record of 530 the client's version of the zone content, identified by its serial 531 number (denoted as sn_o in this document). 533 3.1.5. Additional Section 535 Currently, two kinds of resource records are defined that can appear 536 in the Additional section of IXFR queries and responses: EDNS and DNS 537 transaction security. Future specifications defining RRs that can be 538 carried in the Additional section of normal DNS transactions need to 539 explicitly describe their use with IXFR, should that be desired. 541 All considerations from Section 2.1.5 of RFC 5936 apply in the same 542 manner for IXFR as they do for AXFR. 544 In order to support the extended RCODE assigned for CannotIXFR, EDNS0 545 support (RFC 2671bis [I-D.ietf-dnsext-rfc2671bis-edns0]) is REQUIRED 546 for IXFR-ONLY, and an IXFR-ONLY query MUST be sent with an EDNS OPT 547 RR in the Additional section of the query. Receipt of such query 548 without an OPT RR SHOULD result in an error response with FormErr 549 RCODE. 551 3.2. IXFR Response 553 An IXFR server that has received an IXFR query responds to it with an 554 IXFR response addressed to the transport source identifier from which 555 the query has been received, in particular using the same transport 556 protocol. 558 An IXFR response consists of one or more response messages. If the 559 IXFR query has been received over a connectionless transport 560 (currently: UDP), the IXFR response MUST consist of a single message. 561 If it is not possible to send the complete response in a single DNS 562 message, a response MUST BE sent that only contains the currrent SOA 563 RR at the server; whose serial sn_n being different from sn_o is the 564 signal to the IXFR client to retry over connection-oriented transport 565 (currently: TCP). 567 The conceptional "answer" carried in a multi-message response is the 568 concatenation of the content of the Answer sections in these response 569 messages, in the order they are sent; this is unambiguous from the 570 point of view of the IXFR client as well, since the applicable 571 connection-oriented transport preserves the order of messages sent. 573 If the server detects an error condition that makes it impossible to 574 fulfill the request, it immediately sends an error response, that is 575 a response message with non-zero RCODE. In case of connectionless 576 transport (UDP), this is the single response message sent. In case 577 of connection-oriented transport (TCP), the error condition might 578 occur after one of more response messages already have been sent; in 579 this case, the error message is sent as soon as need arises, and it 580 will abort the ongoing IXFR session; i.e., the error message is the 581 last response message sent by the server. The special case of a 582 server closing the TCP connection without sending an IXFR response 583 message is covered in Section 3.3. 585 If an IXFR server is not able or willing to send the incremental zone 586 change information to transform the client's version (sn_o) to its 587 newer version (sn_n), the behavior is specified as follows: In the 588 case of QTYPE=IXFR, the server SHOULD fall back to AXFR (see below). 589 In the case of QTYPE=IXFR-ONLY, it SHOULD respond with an appropriate 590 error, e.g., CannotIXFR (see below); however, in the (rather 591 unlikely) corner case where a full zone transfer can be sent in a 592 single response packet over connectionless transport (UDP), the IXFR 593 server MAY instead proceed to send this even in response to an 594 IXFR-ONLY query; doing so helps to achieve the overall performance 595 optimization goals of IXFR-ONLY. 597 Any non-error IXFR response starts with the server's version of the 598 SOA resource record, sn_n. 599 If the server detects that the client's version is current (sn_n = 600 sn_o), or if the server detects that the entire response to an IXFR 601 query received over connectionless transport (UDP) cannot be placed 602 into a single response message, this SOA record is the only answer RR 603 sent to the client. Otherwise, the subsequent answer RRs sent form a 604 sequence of one or more change information chunks as described below 605 in Section 4, and the final "sentinel" RR sent is another copy of the 606 current SOA RR. 607 In case of fallback to AXFR, the answer contains the same RRs (and is 608 subject to the same ordering rules) as specified in Sections 2.2 609 through 3 of RFC 5936, with the single difference being the echoed 610 QCODE (i.e., IXFR) in the Question section. 612 3.2.1. Header Values 614 The specification for AXFR in Section 2.2.1 of RFC 5936 applies 615 likewise for IXFR queries, where in the case of IXFR the "new" 616 behavior from RFC 5936 is always followed, i.e. the query ID from the 617 IXFR query MUST be echoed in all IXFR response messages. 619 Note that unlike with all common DNS responses, but like AXFR, the 620 IXFR protocol makes no use of the TC (truncation) bit. To signal 621 that an IXFR session needs to be retried over TCP, an IXFR server 622 sends a response that in the Answer section solely contains its 623 current version of the SOA RR for the zone. 625 The only additonal rule to be followed applies to the deliberations 626 on the RCODE field in Note e) of Section 2.2.1 in RFC 5936: If the 627 IXFR server is not able to fulfill an IXFR-ONLY request, is SHOULD -- 628 see above for the exceptional corner case -- respond with the 629 extended RCODE CannotIXFR assigned on behalf of this document (see 630 Section 10). 632 Note that only the lower 4 bits of the conceptual RCODE can be 633 carried in the RCODE message header field; the upper bits need to 634 be placed into the EXTENDED-RCODE subfield of the "TTL" field in 635 the OPT RR that, in this case, is REQUIRED in the Additional 636 section of the response -- see Section 6.1.3 of RFC 2671bis 637 [I-D.ietf-dnsext-rfc2671bis-edns0]. 639 3.2.2. Question Section 641 In the first response message, the IXFR server MUST copy this section 642 literally from the corresponding IXFR query message. For subsequent 643 response messages, it MAY do the same or leave the Question section 644 empty. However, if the last response message sent is an error 645 message (RCODE unequal to 0), the query MUST also be copied. 646 Accordingly, QDCOUNT in the DNS message header is set to either 1 647 (query copied) or 0 (otherwise). 649 When it is present, the content of this section MAY be used to 650 determine the context of the message, that is, the name of the zone 651 being transferred. The recipent (IXFR client) SHOULD apply the 652 response verification rules from RFC 5452 [RFC5452]. 654 3.2.3. Answer Section 656 The Answer section MUST be populated with the zone change information 657 or, in the case of fallback to AXFR, the full zone contents. 659 For multi-message IXFR responses, the conceptional answer is split 660 into segments that are sent in order. Each segment is comprised of 661 an integer number of full RRs, and for transport efficiency, the 662 response messages should be filled up with answer RRs as much as 663 possible for the response message size chosen by the IXFR server, 664 taking into account the space needed for the other sections in the 665 messages. 667 See Section 4 below for the normative details of the resource record 668 ordering requirements. 670 3.2.4. Authority Section 672 Corresponding to NSCOUNT=0 in the DNS message header, the Authority 673 section in IXFR response messages MUST be empty. 675 3.2.5. Additional Section 677 All considerations from Section 2.2.5 (and hence, by reference, also 678 Section 2.1.5) of RFC 5936 apply in the same manner for IXFR as they 679 do for AXFR. See also Section 3.1.5 of this document. 681 3.3. Connection Aborts 683 In case of an IXFR session carried over connection-oriented transport 684 (TCP), the considerations in Section 2.3 of RFC 5936 [RFC5936] apply 685 similarly. 687 In a nutshell: Servers SHOULD avoid dropping active connections 688 whenever possible, and clients nevertheless must be prepared to 689 gracefully deal with such aborts. 691 4. Response Contents 693 This section describes the structure of the sequence of resource 694 records (RRs) sent in IXFR reponses and how the IXFR client can 695 distinguish the various cases covered. 697 If the IXFR server discovers an error condition before it sends the 698 first (or only) response message, the response content in the Answer 699 section is empty, and consequentially, ANCOUNT is set to 0 in that 700 message. 702 Otherwise, the response content starts with a copy of the current SOA 703 RR at the IXFR server (sn_n). There are several cases: 705 a. The server serial (sn_n) is the same as the client serial (sn_o) 706 sent in the Authority section of the IXFR query. In this case, 707 this SOA RR is the only RR in the response message, indicating to 708 the IXFR client that it already has the current zone content. 710 b. The server serial (sn_n) differs from the client serial (sn_o) 711 sent in the Authority section of the IXFR query, and this SOA RR 712 is the only RR in the response message. This indicates to the 713 IXFR client that its zone content is outdated and the IXFR server 714 is willing to send the incremental zone change information, but 715 is unable to do so in a single response message due to message 716 size limitations. 718 An IXFR server MUST NOT send this type of IXFR response over 719 connection-oriented transport (TCP), but it MAY use this type of 720 response over connectionless transport (UDP). 722 An IXFR client that receives over connection-oriented transport 723 an IXFR response message (as the first response message related 724 to its IXFR query) that contains only a single SOA RR with sn_n 725 unequal to sn_o MUST discard the response message (see below). 727 Note again that the "truncated response message" mechanism 728 specified in RFC 1035, which is signalled by setting the TC bit 729 in a response message, MUST NOT be used in an IXFR response. An 730 IXFR client that receives an IXFR response message with the TC 731 bit set MUST discard the message (see below for details). 733 c. The server serial (sn_n) differs from the client serial (sn_o) 734 sent in the Authority section of the IXFR query, and this SOA RR 735 is followed by another SOA RR in the same response message. In 736 this case, the IXFR response is an incremental response. 738 If this second SOA RR also carries sn_n, the IXFR client SHOULD 739 assume that the server exposes behavior arguably not explicitly 740 forbidden in RFC 1995 to signal case a) above; an IXFR client 741 SHOULD accept for resiliency an IXFR response with exactly these 742 two copies of the same SOA RR sent in a single response message 743 as an "empty incremental response" indicating that the client's 744 version of the zone is current. Otherwise, the client MUST 745 discard a response starting with two copies of the sn_n SOA RR. 747 Otherwise, if the second SOA RR carries sn_o, this indicates the 748 start of an ordinary incremental response as detailed below. 750 Otherwise (if the second SOA RR carries sn_x that differs from 751 both sn_o (as sent by the client) and sn_n (in the first SOA RR), 752 the client MUST discard the response message as bogus. 754 d. The server serial (sn_n) is not the same as the client serial 755 (sn_o) sent in the Authority section of the IXFR query, and this 756 SOA RR is followed by another, non-SOA RR in the same response 757 message. 759 This indicates a non-incremental response, "fallback to AXFR". 760 In this case, the response content is structured like an AXFR 761 response, as described in RFC 5936 ("new" behavior, no backward 762 compatibility kludges admitted); it contains the entire zone 763 content -- preferably with whole RRsets grouped together -- and 764 ends with a second copy of the sn_n SOA RR as an end-of-response 765 marker. 767 A non-incremental IXFR response MUST NOT be sent in response to 768 an IXFR-ONLY query unless the entire intended IXFR response -- up 769 to and including the trailing sentinel sn_n SOA RR -- fits into a 770 single response message with a size that allows it to be sent 771 over connectionless transport (UDP), or would have allowed that 772 if it actually is carried over connection-oriented transport 773 (TCP). An IXFR client that receives an incomplete initial IXFR 774 response message that indicates such non-incremental response to 775 an IXFR-ONLY query MUST discard the message as bogus. 777 Whenever in the above cases the text says that the IXFR client "MUST 778 discard the message", the following behavior is implied: The IXFR 779 client MUST regard the IXFR session as terminated; this results in 780 subsequent silent discarding of further response messages that still 781 pretend to belong to the same IXFR session by means of the query ID 782 and the echoed Question (if present), because the IXFR client does 783 not maintain corresponding IXFR query/session state any more. The 784 IXFR client MAY log the event and SHOULD regard the IXFR server as 785 broken; hence, it SHOULD refrain from using the same IXFR server 786 again -- at least for considerable time, or until the usage has been 787 reinstated by an implementation-dependent management interaction. 789 From the above decision tree for the client it also follows that, to 790 allow unambiguous client behavior, if an IXFR server has to send a 791 response comprised of two or more RRs, it MUST send at least the 792 first two RRs in the first response message. 794 If the IXFR server discovers an error condition lately, after having 795 sent one or more response messages (all with RCODE set to 0), it can 796 abort the IXFR session by sending another response message with empty 797 Answer section and a non-zero RCODE. This MUST be the last message 798 sent in response to the IXFR query, that is, this error message 799 aborts the ongoing IXFR session. 801 4.1. Incremental Responses 803 In an incremental response, the leading sn_n SOA RR is followed by 804 one or more change information chunks and concluded by a second copy 805 of the sn_n SOA RR. 807 Each change information chunk describes the changes to be performed 808 on a given "origin" version of the zone to obtain a "target" version 809 of the zone (i.e., one SOA serial change of the zone). It consists 810 of (1) a set of old RRs to be deleted from the "origin" zone version 811 and (2) a set of new RRs to be added after these deletions to obtain 812 the "target" version of the zone. (In this model, a change in a 813 single RR is represented by an RR deletion followed by an RR 814 addition.) These two sets are sent in this order, with each set 815 serialized as a sequence of the related SOA RR followed by other, 816 non-SOA RRs in a arbitrary order. This way, each SOA RR indicates 817 the end of the sequence of (zero or more) non-SOA RRs that precedes 818 it, and at the same time it either starts the next set of RRs or is 819 the trailing sn_n SOA of the response. 821 The "origin" sn of each change information chunk MUST precede its 822 "target" sn in the sense of sequence number arithmentics. 824 The change information chunks in an incremental response MUST be 825 ordered oldest first, newest last; in more detail: The first change 826 information chunk in an incremental response must have the client's 827 version (sn_o) as its origin sn; the origin sn of each subsequent 828 change information chunk MUST be the same as the target sn of the 829 preceding chunk, and the last change information chunk in an 830 incremental response MUST have the server's version (sn_n) as its 831 target sn. This "chaining" of chunks ensures that the client can 832 correctly construct the sn_n version from the sn_o version it holds 833 by conceptionally applying single-RR deletions and additions in the 834 order the RRs appear in the IXFR response. 836 Note that, as a consequence of the aforementioned rules, a valid 837 incremental IXFR response MUST contain exactly one copy of the sn_o 838 SOA RR (sent as the second RR in the response) and exactly three 839 copies of the sn_n SOA RR -- one as the first RR in the response, one 840 as the leading RR of the second sequence (set of RRs to be added) in 841 the last change information chunk, and one as the final "sentinel" RR 842 that indicates the end of the response contents. Likewise, each 843 "intermediate" SOA RR (with sn_o < sn < sn_n) will appear exactly 844 twice, once in the second part (new RRs) of a particular change 845 information chunk, and once in the first part of the immediately 846 following change information chunk. 848 Any IXFR response classified as a (non-empty) incremental response by 849 the decision tree presented above in Section 4 that violates any of 850 the above rules MUST cause the IXFR client to regard the response as 851 bogus; it MUST discard a response message in case its content allows 852 the client to detect such violation, with the caveats for "discard" 853 given in Section 4. 855 In support of avoiding clients to draw wrong conclusions on the end 856 of an incremental response, it is RECOMMENDED that an IXFR server not 857 send the aforementioned second instance of the sn_n SOA RR as the 858 last RR in a (non-final) response message. 860 5. Transport 862 IXFR servers and IXFR clients MUST support transport over UDP and TCP 863 (see RFC 5966 [RFC5966]). As with all DNS transactions, IXFR 864 responses MUST be sent on the same transport association over which 865 the query arrives at the server. 867 If an IXFR server cannot send a full IXFR response for an IXFR query 868 received over UDP within a single response message over UDP due to 869 message size limitations, it MUST return the special form of response 870 that indicates to the client to retry over TCP (single-RR response 871 with the server SOA only, as described in Sections 3.2 and 4). 873 Given the limitation of the basic DNS message size over UDP to 512 874 octets, it is strongly RECOMMENDED that implementations of IXFR 875 servers and IXFR clients support RFC 2671bis, "Extension Mechanisms 876 for DNS (EDNS0)" [I-D.ietf-dnsext-rfc2671bis-edns0] and choose 877 extended DNS message size limits appropriate for their environment. 878 The default behavior of IXFR clients regarding the EDNS message size, 879 and the maximum accepted by servers, SHOULD both be configurable. 881 The considerations for AXFR transport over TCP in Section 4 of RFC 882 5936 [RFC5936] apply similarly for IXFR. However, IXFR is commonly 883 being used much more frequently than AXFR between a given pair of 884 authoritiative servers, and often not authorized for use by servers 885 outside the set of authorities for a zone, which are all under the 886 control of a single administrative domain or a small number of 887 cooperating administrative domains. In this environment, it might 888 make sense for the sake of efficiency to maintain (and reuse) 889 persistent TCP connections between the configured IXFR peers. 890 Therefore, implementations of IXFR should allow to configure 891 relatively high TCP User Timeout values and support the TCP UTO 892 mechanism ([RFC5482]) that allows the peers to exchange their view of 893 the TCP User Timeout and adapt the behavior of their TCP accordingly. 895 6. Server Behavior 897 6.1. General 899 General considerations on IXFR server behavior, in particular 900 response message generation and packet processing, are spread all 901 over this document; in particular, see Sections 3.2 and 4. 903 In addition to the current zone content, IXFR servers need to 904 maintain history information on the zone content that enables them to 905 respond with incremental responses for a sufficient range of 906 versions. What is considered "sufficient" and how this history 907 information is maintained, is a local matter. It may be appropriate 908 to maintain the history information on stable storage as well to make 909 it available spanning restarts of an IXFR server, as it is already 910 required for the current zone content. 912 6.2. Purging Strategy 914 An IXFR server cannot be required to hold all previous versions 915 forever and may delete them anytime. In general, there is a trade- 916 off between the size of storage space and the possibility and need of 917 using IXFR. 919 Information about older versions should be purged as soon as the 920 total length of an IXFR response would otherwise become larger than 921 that of an AXFR response. Given that the purpose of IXFR is to 922 reduce AXFR overhead, this strategy is quite reasonable. The 923 strategy assures that the amount of storage required is at most twice 924 that of the current zone information. 926 Information older than the SOA expire period may also be purged. 928 The Condensation techniques explored below in Section 6.3 might pose 929 an opportunity to get rid of more recent, yet less relevant history 930 information and as such might allow to cover a larger span of SOA 931 versions than otherwise possible within the same amount of storage. 933 6.3. Optional Condensation of Zone Changes 935 An IXFR server MAY optionally condense a number of immediately 936 succeeding change information chunks into a single chunk, thus 937 dropping information on intermediate zone versions. 939 This may be beneficial if a lot of versions, not all of which are 940 useful, are generated. For example, if multiple ftp servers share a 941 single DNS name and the IP address associated with the name is 942 changed once a minute to balance load between the ftp servers, it is 943 not so important to keep track of all the history of changes. 945 Another example is where statefully managed client systems get IP 946 addresses assigned dynamically by DHCP servers, and where the DHCP 947 server(s) and/or the clients register their current contact 948 information via DNS UPDATE whenever leases are given out or renewed. 949 These transactions could be comprised of several independent update 950 steps, for forward and reverse address resolution, for service 951 discovery, etc., where multiple parts of the related information are 952 maintained in the same zone. Intelligent condensation strategies 953 might be able to identify subsequent incremental changes related to a 954 single end-user system and collapse this information in a single 955 change information chunk. 957 But this feature may not be so useful if an IXFR client has access to 958 two IXFR servers, A and B, with inconsistent condensation results. 959 The current version of the IXFR client, received from server A, may 960 be unknown to server B. In such a case, server B cannot provide 961 incremental data from the unknown version and a full zone transfer is 962 necessary. Therefore, it is highly desirable that alternative IXFR 963 servers for a given set of IXFR clients expose similar (or at best, 964 the same) condensation behavior. 966 Condensation can be performed in two stages, perhaps in a 967 complementary manner: Firstly, the history information stored on an 968 IXFR server can be condensed to reduce storage requirements *and* 969 IXFR response sizes to some degree. Additionally, IXFR servers can 970 perform condensation "on the fly" in preparing IXFR responses; this 971 might provide additional savings in IXFR response size while reducing 972 the likelihood that IXFR queries cannot be responded with incremental 973 responses due to the requested sn being "condensed out" of the stored 974 history information. 976 Condensation is completely optional. Clients cannot detect from the 977 response whether or not the server has condensed the reply. 979 For interoperability, IXFR servers, including those without the 980 condensation feature, SHOULD NOT send an error response in case they 981 receive a client's IXFR request with an unknown version number and 982 SHOULD, instead, attempt to perform a full zone transfer. Of course, 983 this in general does not apply if the client indicates its desire to 984 try its luck in such case at another candidate IXFR server, by 985 initiating the request with IXFR-ONLY (the exception to the general 986 case is the corner case discussed in Section 3.2). 988 6.4. Authorization 990 The considerations for AXFR presented in Section 5 of RFC 5936 991 [RFC5936] apply in a similar fashion for IXFR. 993 Given the basic desire for frequent use and the resulting processing 994 load, operational considerations will, even more likely than for 995 AXFR, dictate the need to closely restrict the usage of IXFR to the 996 set of authoritiative servers for a given zone, and to precisely 997 configure the IXFR distribution graph within the set of servers, by 998 means of access lists on the server side and by configuring a 999 prioritized IXFR server search list on the client side. 1001 Since IP addresses can be spoofed rather trivially in large parts of 1002 the open Internet, better authentication methods are needed as a base 1003 for authorization decisions unless the IXFR distribution graph can be 1004 restricted to protected networks under control of the same 1005 administration as the participating DNS servers. 1007 In particular, as detailed in the Section of RFC 5936 quoted above, 1008 implementations of IXFR SHOULD also support at least one flavor of 1009 DNS transaction security. Virtual private networks, virtual LANs, 1010 IPsec ([RFC4301]), and TCP-AO ([RFC5925] might also be applicable 1011 solutions to ensure proper authentication to base authorization 1012 decisions on. See Section 9 for more information. 1014 7. Client Behavior 1016 It is RECOMMENDED that IXFR client implementations supporting 1017 IXFR-ONLY allow to configure its usage per IXFR server, as part of 1018 the IXFR distribution graph configuration. 1020 An IXFR client SHOULD set an appropriate guard timeout whenever the 1021 content of a response message indicates that this is not the final 1022 message of an IXFR response. In case this timeout period elapses 1023 without another response message arriving, it SHOULD regard the IXFR 1024 session as failed and apply the caveats for the "discard" case 1025 presented in Section 4. 1027 7.1. Zone Integrity 1029 The elaborations on Zone Integrity for AXFR in Section 6 of RFC 5936 1030 [RFC5936] apply in a similar fashion for IXFR. 1032 However, during the receipt of an incremental IXFR response, and upon 1033 successful processing of an SOA RR that serves as a sentinel for the 1034 end of any change information chunk, an IXFR client MAY immediately 1035 apply and commit to stable storage the SOA serial number change 1036 described by that chunk (and previous chunks, if not already done). 1037 This operation MUST externally appear as an atomar operation. 1039 Before this operation can be attempted, the IXFR client SHOULD apply 1040 all feasable sanity checks for the change information chunk under 1041 consideration. In particular, it SHOULD verify that the RRs 1042 contained in the first part of the chunk (those to be deleted) are 1043 indeed literally contained in the data set for the most recent zone 1044 version the client has constructed so far. If a DNSSEC-aware IXFR 1045 client receives an IXFR response for a zone secured with DNSSEC 1046 [RFC4033], it MAY try to verify any RRSIG RR for the new zone SOA 1047 (received in the second part of the change information chunk), as 1048 another means to detect forged responses, and in case of failure 1049 forcibly abort the IXFR session. However, in order to avoid DoS 1050 attacks targeted at processing resources and amplification attacks, 1051 this SHOULD NOT be done if the IXFR session is secured by other means 1052 (in-band by TKEY/TSIG, in lower layers, e.g. by IPsec or other VPN 1053 technology) or if the necessary keys are unavailable (not already 1054 cached) and/or not already verified. Similarly, like in the case of 1055 AXFR, it is generally NOT RECOMMENDED to perform a full cryptographic 1056 verification of the new zone version -- which would consume very 1057 substantial computing resources, hence clearing the way for another 1058 type of DoS attack. 1060 8. Backwards Compatibility 1062 Despite a few potentially misleading statements in the previous 1063 specification, only a single detail has been identified so far that 1064 could give rise to backward compatibility concerns. This is 1065 addressed by the compatibility rules in Section 4 that allow an IXFR 1066 client to process an "empty incremental response" consisting of only 1067 a pair of instances of the server's SOA RR. 1069 The introduction of IXFR-ONLY creates further interoperability 1070 considerations. An IXFR server utilizing IXFR-ONLY may receive an 1071 error response different from CannotIXFR persistently. (The actual 1072 RCODE reveived may depend on whether or not the server is aware of 1073 the allocation of the range of RR types set aside for Q-Types in 1074 [RFC6195] (and its predecessors), from which the IXFR-ONLY code point 1075 has been assigned.) This event likely indicates that the IXFR server 1076 chosen does not support IXFR-ONLY. In such case, the client will 1077 mark the server as "unusable of IXFR-ONLY" in his server list and try 1078 another potential IXFR server, or, if all candidates fail, retry the 1079 scan with bare IXFR, or alternatively try to immediately start an 1080 AXFR session. The latter should always be the method of last resort 1081 in case of persistent IXFR failures. 1083 9. Security Considerations 1085 This document presents a more detailed specification for the 1086 mechanism previously specified in RFC 1995, which has similar 1087 protocol behavior and security properties as the AXFR mechanism 1088 described in RFC 5936. Hence, beyond the general security 1089 considerations for the DNS laid down in RFC 3833 [RFC3833], similar 1090 considerations apply. 1092 Thus, the sections on Transport, Authorization and Zone Integrity 1093 that all include by reference the respective sections of RFC 5936 1094 [RFC5936] largely address the relevant concerns. Deployments of IXFR 1095 might be interested in using large values for the EDNS message size 1096 and thereby become more exposed to the various security threats 1097 against IP fragmentation; these and suitable mitigations are 1098 discussed in [RFC6274]. 1100 Since IXFR is likely to be used in a more frequent and continuous 1101 manner and hence a possible candidate for making use of long-lived, 1102 persistent TCP connections for its transport, besides IPsec (RFC 4301 1104 [RFC4301]), the more lightweight TCP Authentication mechanism 1105 described in RFC 5925 (TCP-AO, [RFC5925]) might, once deployed, be a 1106 suitable candidate for peer authentication and integrity protection 1107 of IXFR sessions. 1109 10. IANA Considerations 1111 The IANA Registry "Domain Name System (DNS) Parameters" [DNSVALS] 1112 contains a sub-registry "Resource Record (RR) TYPEs", in which 1113 [RFC6195] has reserved the range 128 through 255 for pseudo-RRs only 1114 being used in DNS queries, for short "Q-Types". This partial 1115 namespace is managed under the "DNS RRTYPE Allocation Policy" 1116 specified in RFC 6195 [RFC6195]. 1118 [[ This paragraph to be deleted on publication as an RFC ]] 1119 IANA and IESG: based on the provisions of RFC 6195, we ask for RFC 1120 4020 early allocation of the two code points needed for this memo, as 1121 described below. 1123 Since RFC 1995, the Q-Type 251 has been assigned to IXFR. Upon 1124 publication of this memo as an RFC, IANA will update / has updated 1125 the description for that entry to say "incremental zone transfer" and 1126 the Reference for that entry to point to this RFC. 1128 Upon publication of this memo as an RFC, IANA also will assign / has 1129 assigned the Q-Type {TBD1} to the TYPE mnemonic IXFR-ONLY, with 1130 description "incremental zone transfer w/o fallback", and pointing to 1131 this memo. 1133 The IANA Registry "Domain Name System (DNS) Parameters" [DNSVALS] 1134 contains a sub-registry "DNS RCODEs", which is managed under "IETF 1135 Review" assignment policy, as specified in RFC 6195 [RFC6195]. IANA 1136 is requested to allocate / has allocated from that sub-registry a new 1137 Extended RCODE value (above 16, only usable with EDNS) for 1138 CannotIXFR: 1140 RCODE Name Description Reference 1141 Decimal 1142 --------- ---------- ---------------------------------- --------- 1143 {TBD2} CannotIXFR IXFR not possible, would fall back [RFCthis] 1145 11. Acknowledgements 1147 Masataka Ohta is acknowledged for his original work as the author of 1148 RFC 1995 [RFC1995], and this extends to the contributors listed in 1149 the Acknowledgements section of that RFC. 1151 The specification of IXFR-ONLY in this document is based on the 1152 original proposal [I-D.kerr-ixfr-only], whose authors are 1153 acknowledged for identifying the operational need for this behavior 1154 and carrying it to the IETF. 1156 The DNSEXT working group and its predecessor (DNSIND) are 1157 acknowledged for their discussion on the above documents. 1158 Substantial text has been borrowed from there and from [RFC5936]. 1160 Discussions of the draft on the dnsext list have directed the 1161 evolution of this document; in particular, we acknowledge (in 1162 alphabetical order) Mark Andrews, Brian Dickson, Shane Kerr, Edward 1163 Lewis, Josh Littlefield, Masataka Ohta, Paul Vixie, and Wouter 1164 Wijngaards for their comments and reviews. 1166 12. References 1168 12.1. Normative References 1170 [I-D.ietf-dnsext-rfc2671bis-edns0] 1171 Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1172 for DNS (EDNS0)", draft-ietf-dnsext-rfc2671bis-edns0-08 1173 (work in progress), February 2012. 1175 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1176 STD 13, RFC 1034, November 1987. 1178 [RFC1035] Mockapetris, P., "Domain names - implementation and 1179 specification", STD 13, RFC 1035, November 1987. 1181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1182 Requirement Levels", BCP 14, RFC 2119, March 1997. 1184 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1185 for Application Designers", BCP 145, RFC 5405, 1186 November 2008. 1188 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 1189 Resilient against Forged Answers", RFC 5452, January 2009. 1191 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 1192 (AXFR)", RFC 5936, June 2010. 1194 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA 1195 Considerations", BCP 42, RFC 6195, March 2011. 1197 12.2. Informative References 1199 [DNSVALS] IANA Registry, "Domain Name System (DNS) Parameters", 1200 protocol parameter registry available at:, January 2012, 1201 . 1203 [I-D.kerr-ixfr-only] 1204 Sury, O. and S. Kerr, "IXFR-ONLY to Prevent IXFR Fallback 1205 to AXFR", draft-kerr-ixfr-only-01 (work in progress), 1206 February 2010. 1208 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1209 August 1996. 1211 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1212 Changes (DNS NOTIFY)", RFC 1996, August 1996. 1214 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1215 Specification", RFC 2181, July 1997. 1217 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1218 Name System (DNS)", RFC 3833, August 2004. 1220 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1221 Rose, "DNS Security Introduction and Requirements", 1222 RFC 4033, March 2005. 1224 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1225 Internet Protocol", RFC 4301, December 2005. 1227 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 1228 RFC 5482, March 2009. 1230 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1231 Authentication Option", RFC 5925, June 2010. 1233 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 1234 Requirements", RFC 5966, August 2010. 1236 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 1237 Version 4", RFC 6274, July 2011. 1239 Appendix A. Motivation for IXFR-ONLY 1241 IXFR is an efficient means to transfer changes in zones from IXFR 1242 servers to IXFR clients. However, when an IXFR client has multiple 1243 IXFR servers for a single zone, it is possible that not all IXFR 1244 servers hold the zone content with the same serial number(s). In 1245 this case, if an IXFR client attempts an IXFR from an IXFR server 1246 that does not have the zone content with the serial number used by 1247 the IXFR client, the IXFR server will fall back to a full zone 1248 transfer (like in AXFR) when it has a version of the zone with serial 1249 number greater than the serial requested by the IXFR client. 1251 For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for 1252 a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the 1253 same zone. An IXFR client that has the zone content with serial 1254 number 2 and sends an IXFR request to IXFR server NS2 will get a full 1255 zone transfer (AXFR style) of the zone at serial number 3. This is 1256 because NS2 does not know the zone with serial number 2, and 1257 therefore is not able to report the differences between the zone with 1258 serial number 2 and 3. 1260 If the IXFR client in this example had known to send the query to 1261 IXFR server NS1, then it could have gotten an incremental transfer. 1262 But an IXFR clients can only know what the *latest* version of the 1263 zone is at an IXFR server -- this information is available via an SOA 1264 query. 1266 The IXFR-ONLY query type provides a way for the IXFR client to ask 1267 each IXFR server to return an error instead of sending the current 1268 version of the zone via full zone transfer. By using this, an IXFR 1269 client can check each IXFR server until it finds one able to actually 1270 provide an incremental transfer. If it doesn't succeed, it can fall 1271 back and try with bare IXFR instead of IXFR-ONLY, or it can 1272 immediately start an AXFR session with an AXFR server of its choice 1273 (the preferred AXFR server might be distinct from the most prefered 1274 IXFR server). 1276 By providing IXFR-ONLY support, the policy control over the zone 1277 synchronization operation switches to the client side, which is 1278 preferable under various operational settings. 1280 Appendix B. Substantial Changes Since RFC 1995 1282 This is a summary of the substantial changes since RFC 1995 1283 [RFC1995]. 1285 o Corrected a few technical flaws: incorrect comparison with AXFR; 1286 improper impled requirement of performing SOA query over UDP; 1287 improper reference to transfer of partial RRs in a response 1288 message corrected (to be read as transfer of partial RRsets in a 1289 response message -- as it has always been understood by 1290 implementers, since STD 13 requires only entire RRs to be present 1291 in DNS messages). 1293 o New specification based on the revised AXFR specification, 1294 RFC 5936 [RFC5936]. 1296 o Many clarifications and details supplied, text vastly reorganized 1297 and expanded, but no (intentional) technical deviation from the 1298 previous specification, as understood by implementers. 1300 o Addition of new IXFR-ONLY protocol variant, based on operational 1301 experience and perceived need. 1303 o Major additions to Security Considerations. 1305 o Historical example dropped (incompatible with IESG policy on 1306 examples). Instead, abstract examples have been added to 1307 Section 2. 1309 Appendix C. Evaluation of List Discussion, Draft Changes since -02 1311 [[ Temporary Section, to be deleted in next draft version. ]] 1313 The previous (-02) version of this draft has been extensively 1314 discussed on the dnsext mailing list during the June through August 1315 2011 timeframe. Due to temporary unavailability of the primary 1316 author, the concensus-building based on that discussion is summed up 1317 below, instead of flooding the mailing list with a bunch of (very 1318 belated) response messages. Messages are quoted below as 1319 "{msgNNNNN}", based on the message numbers (NNNNN -- a 5-digit 1320 number) assigned in the list archive using URIs following the pattern 1321 . 1323 {msg11353}, item 1: It is claimed frequently that IETF documents are 1324 too "microscopic" in their perspective and do not give the "glue" 1325 context information allowing even a non-specialized reader to see how 1326 the specified functionality relates to other parts of protocols, 1327 deployment, and common usage. Therefore, like in the kindred AXFR 1328 document, RFC 5936, context information for the invocation of IXFR is 1329 given in the draft -- btw, in a style that resembles descriptions 1330 given in the basic DNS Standards, RFCs 1034 and 1035. 1331 If zones don't change, and no NOTIFYs are sent, IXFR isn't needed. 1332 As RFC 1996 (NOTIFY) indicates, NOTIFY was intended as the primary 1333 trigger for IXFR requests, and that's what this draft re-states from 1334 the perspective of IXFR. 1335 Minor editorial changes have been performed. 1337 {msg11353}, item 2, {msg11359} and more messages down the thread: 1338 As has been pointed out by Brian D. (et al.) in {msg11354}, 1339 {msg11363} (and follow-up discussion), the term "Fallback to AXFR" 1340 describes IXFR server behavior specified in RFC 1995 and present in 1341 all major DNS server implementations. 1342 Overall, substantial discussion apparently has been caused by 1343 confusion about the (admittedly a bit colloquial) term "Fallback to 1344 AXFR". Another thread on this behavior was started by Mark A. 1345 ({msg11373} ff.). 1346 To clarify and resolve this issue, a definition for this term has 1347 been added to Section 1.4. 1348 The justification for clarifications to the present IXFR 1349 specification and the need for interoperably specified IXFR-ONLY has 1350 been reinforced by several contributors, e.g. Brian D., Mark A., and 1351 Masataka O. ({msg11354}, {msg11355}, {msg11356}, {msg11365}, ff.). 1352 We have not found any indications in the draft text where the 1353 detailed specification of (classical) IXFR would contradict RFC 1995, 1354 and it has been indicated on the list that the draft also correctly 1355 reflects the on-the-wire IXFR behavior of all major implementations 1356 represented by active participants on the list. 1358 {msg11353}, final item: IMO, RFC 1995 would have deserved at least 3 1359 Technical Errata and roughly a dozen Editorial Errata, and it lacks a 1360 lot of precidion, so we agree that a refresh of this original 1361 specification should be welcome. 1362 The suggested additional test by DNSSEC-aware IXFR clients of the 1363 RRSIG(SOA) RRset now is mentioned in a newly added paragraph of 1364 Section 7.1 (that section is referred to in the Security 1365 Considerations). 1367 {msg11373}, {msg11374} and follow-ups: The draft already represents 1368 in detail the different possible responses on an IXFR query that have 1369 been inherent in RFC 1995. 1370 If (and only if) the IXFR server can respond with a single DNS 1371 response packet, the IXFR transaction can be carried out successfully 1372 over UDP, and hence is a "single response mechanism". Otherwise, the 1373 IXFR client has to be redirected to TCP, as described in (RFC 1995 1374 and) the draft. This is independent of whether the IXFR server then 1375 has to fall back to full-zone transfer. 1376 There might be a (very unlikely) corner case, where the IXFR server 1377 wants to fall back to full-zone transfer *and* this transfer can be 1378 performed in a single response packet. Admittedly, that's rather 1379 unlikely, and in this case, IXFR-ONLY behavior would be causing 1380 additional overhead and message exchanges. Therefore, clauses has 1381 been added to Section 2 and Section 3.2 that in this corner case, the 1382 response to IXFR-ONLY MAY be a full-zone transfer over UDP, for the 1383 sake of overall performance. 1384 Otherwise, no significant changes to the text have been performed in 1385 this respect. 1387 {msg11376} ff.: Aborting an IXFR session over TCP likely does not 1388 waste so much resources on the IXFR client side (which initiates the 1389 premature closing of the TCP connection), but it takes much more time 1390 for the IXFR server to be notified of this closure, and up to then, 1391 it will have wasted resources to generate and buffer response packets 1392 that will either never be received or not even sent. Further, if a 1393 persistent TCP connection is desired, e.g. for an IXFR client that 1394 regularly has to update numerous zones from the same (candidate) IXFR 1395 server, re-establishment and subsequent TCP slow-start of a new TCP 1396 connection will be actually detrimental to the overall zone update 1397 performance. 1398 This is another reason why IXFR-ONLY promises substantial performance 1399 improvements that cannot be achieved without protocol enhancements. 1401 Since only modern DNS implementations are expected to implement 1402 IXFR-ONLY (which are expected to support EDNS anyway), because 1403 extended message sizes are very useful for IXFR in general (which 1404 also requires EDNS), and to reduce the pressure on the narrow basic 1405 RCODE namespace (only 5 codepoints still available for assignment), 1406 the draft now assumes that an extended RCODE value for CannotIXFR 1407 will suffice. The running text and IANA Considerations have been 1408 adjusted accordingly. Consequentially, the draft now specifies that 1409 an IXFR-ONLY query without an OPT RR will be rejected by the IXFR 1410 server with FormErr. 1412 Paul V. ({msg13379}) pointed out the detriments of message sizes 1413 above 16k (loss of ability to perform message compression). 1414 Added Note to Section 3 explaining this hint. 1416 A few adjustments regarding use of RFC 2119 language have been 1417 performed. 1419 Appendix B, which sums up the important changes since RFC 1995, has 1420 been added, as needed per IESG policy. 1422 References have been updated. 1424 Numerous editorial changes and enhancements have been applied. 1425 Vertical spacing tweeked to avoid dangling orphan lines at page 1426 breaks. 1428 Authors' Addresses 1430 Alfred Hoenes 1431 TR-Sys 1432 Gerlinger Str. 12 1433 Ditzingen D-71254 1434 Germany 1436 EMail: ah@TR-Sys.de 1438 Ondrej Sury 1439 CZ.NIC 1440 Americka 23 1441 120 00 Praha 2 1442 CZ 1444 Phone: +420 222 745 110 1445 EMail: ondrej.sury@nic.cz