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