idnits 2.17.1 draft-kerr-ixfr-only-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1995, but the abstract doesn't seem to directly say this. It does mention RFC1995 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1995, updated by this document, for RFC5378 checks: 1994-11-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2010) is 5171 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) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSext Working Group O. Sury 3 Internet-Draft CZ.NIC 4 Updates: 1995 (if approved) S. Kerr, Ed. 5 Intended status: Standards Track ISC 6 Expires: August 30, 2010 February 26, 2010 8 IXFR-ONLY to Prevent IXFR Fallback to AXFR 9 draft-kerr-ixfr-only-01 11 Abstract 13 This documents proposes a new QTYPE (Query pseudo RRtype) for the 14 Domain Name System (DNS). IXFR-ONLY is a variant of IXFR (RFC 1995) 15 that allows an authoritative server to incrementally update zone 16 content from another (primary) server without falling back from IXFR 17 to AXFR. This way, alternate peers can be contacted more quickly and 18 convergence of zone content may be achieved much faster in important, 19 resilient operational scenarios. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 30, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 63 2. IXFR Server Side . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. IXFR Client Side . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Applicability of IXFR-ONLY . . . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 68 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 For large DNS zones, RFC 1995 [RFC1995] defines Incremental Zone 74 Transfer (IXFR), which allows only to transfer the changed portion(s) 75 of a zone. 77 In the document, an IXFR client and an IXFR server is defined as in 78 RFC 1995 [RFC1995], a secondary name server which requests IXFR is 79 called an IXFR client and a primary or secondary name server which 80 responds to the request is called an IXFR server. 82 IXFR is an efficient way to transfer changes in zones from IXFR 83 servers to IXFR clients. However, when an IXFR client has multiple 84 IXFR servers for a single zone, it is possible that not all IXFR 85 servers have the zone with same serial number for that zone. In this 86 case, if an IXFR client attempts an IXFR from an IXFR server which 87 does not have zone with the serial number used by the IXFR client, 88 the IXFR server will fall back to a full zone transfer (AXFR) when it 89 has a version of the zone with serial number greater than the serial 90 requested by the IXFR client. 92 For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for 93 a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the 94 same zone. An IXFR client that has the zone with serial number 2 95 which sends an IXFR request to IXFR server NS2 will get a full zone 96 transfer (AXFR) of the zone at serial number 3. This is because NS2 97 does not know the zone with serial number 2, and therefore does not 98 know what the differences are between zone with serial number 2 and 99 3. 101 If the IXFR client in this example had known to send the query to 102 IXFR server NS1, then it could have gotten an incremental transfer 103 (IXFR). But IXFR clients can only know what the latest version of 104 the zone is at a IXFR server (this information is available via an 105 SOA query). 107 The IXFR-ONLY query type provides a way for the IXFR client to ask 108 each IXFR server to return an error instead of sending the current 109 version of the zone via full zone transfer (AXFR). By using this, a 110 IXFR client can check each IXFR server until it finds one able to 111 provide IXFR. 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. IXFR Server Side 121 A IXFR server receiving a DNS message requesting IXFR-ONLY will reply 122 as described in RFC 1995 [RFC1995] if it is able to produce an IXFR 123 for the serial number requested. 125 If the IXFR server is is not able to reply with an IXFR it MUST NOT 126 reply with an AXFR unless AXFR result is smaller than IXFR result. 127 Instead, it MUST reply with RCODE CannotIXFR. (!FIXME) 129 If the IXFR result is larger than an AXFR, then an IXFR server MAY 130 reply with an AXFR result instead. This is an optimization, and IXFR 131 servers MAY only reply with AXFR if they are certain that the reply 132 using AXFR is smaller than an equivalent IXFR reply. 134 3. IXFR Client Side 136 An IXFR client who wishes to use IXFR-ONLY will send a message to one 137 of the IXFR servers. The format is exactly the same as for IXFR, 138 except the IXFR-ONLY QTYPE code is used instead of the IXFR QTYPE 139 code. 141 If the IXFR server replies with IXFR, then the IXFR client is done. 143 If the IXFR server replies with an RCODE of CannotIXFR, then the IXFR 144 client proceeds on to a different IXFR server. In this case the IXFR 145 server implements IXFR-ONLY, but does not have information about zone 146 with the serial number requested. 148 If the IXFR server replies with any RCODE other than CannotIXFR or 149 NoError, then the IXFR client proceeds on to a different IXFR server. 150 In this case the IXFR server does not implement IXFR-ONLY. 152 If the IXFR client attempts IXFR-ONLY to each IXFR server and none of 153 them reply with an incremental transfer (IXFR), then it should 154 attempt an IXFR as described in RFC 1995 [RFC1995] to each of the 155 IXFR servers which replied with an RCODE other than CannotIXFR or 156 NoError. 158 The method described above allows IXFR clients to operate normally in 159 situatians where some of the IXFR servers do support IXFR-ONLY, and 160 some who do not. IXFR clients MAY remember which IXFR servers 161 support IXFR-ONLY and query those IXFR servers first. However since 162 IXFR servers may change software or even run a mix of software, IXFR 163 clients MUST attempt to query each IXFR server periodically when they 164 attempt to get new versions of a zone. 166 Implementations MAY allow IXFR clients to disable IXFR-ONLY for a 167 given IXFR server, if this is known in advance. These IXFR servers 168 are treated as if they replied with an RCODE other than CannotIXFR or 169 NoError, although no query with IXFR-ONLY is actually sent. 171 4. Applicability of IXFR-ONLY 173 Implementations SHOULD allow IXFR clients to disable IXFR-ONLY 174 completely. 176 Implementations MAY allow IXFR clients to disable IXFR-ONLY for a 177 specific zone. This may be useful for small zones, where fallback to 178 AXFR is cheap, or in other cases where IXFR-ONLY is causing problems. 180 Usage of IXFR-ONLY may cause IXFR clients to prefer particular IXFR 181 servers, by shifting load to ones that support IXFR-ONLY. If this a 182 problem, then administrators can disable IXFR-ONLY in implementations 183 that allow it. 185 If a IXFR client has a single IXFR server for a zone, it SHOULD use 186 IXFR rather than IXFR-ONLY. 188 5. IANA Considerations 190 IANA allocates the new IXFR-ONLY QTYPE, which means "incremental 191 transfer only". IANA allocates the CannotIXFR RCODE, which means 192 "Server cannot provide IXFR for zone". 194 6. Security Considerations 196 IXFR-ONLY may be used by someone to get information about the state 197 of IXFR servers by providing a quick and efficient way to check which 198 versions of a zone each IXFR server supports. Zones should be 199 secured via TSIG [RFC2845] to prevent unauthorized information 200 exposure. However, even administrators of IXFR servers may not want 201 this information given to IXFR clients, in which case they will need 202 to disable IXFR-ONLY. 204 7. Normative References 206 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 207 August 1996. 209 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 210 Requirement Levels", BCP 14, RFC 2119, March 1997. 212 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 213 Wellington, "Secret Key Transaction Authentication for DNS 214 (TSIG)", RFC 2845, May 2000. 216 Authors' Addresses 218 Ondrej Sury 219 CZ.NIC 220 Americka 23 221 120 00 Praha 2 222 CZ 224 Phone: +420 222 745 110 225 Email: ondrej.sury@nic.cz 227 Shane Kerr (editor) 228 ISC 229 Bennebrokestraat 17-I 230 1015 PE Amsterdam 231 NL 233 Phone: +31 64 6336297 234 Email: shane@isc.org