Network Working Group W. Mekking Internet-Draft Dynamic Network Services Inc Intended status: Experimental O. Gudmundsson Expires: July 19, 2015 CloudFlare January 15, 2015 Minimal Incremental Zone Transfer in DNS draft-mekking-mixfr-01 Abstract This document proposes extensions to the DNS protocol to provide an incremental zone transfer (IXFR) mechanism with dynamic update (UPDATE) capabilities, to keep IXFRs that deal with DNSSEC small. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 19, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Mekking & Gudmundsson Expires July 19, 2015 [Page 1] Internet-Draft MIXFR January 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Implicit RRSIG deletion . . . . . . . . . . . . . . . . . 3 3.2. Add an RR . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Delete an RR . . . . . . . . . . . . . . . . . . . . . . 3 3.4. Delete an RRset . . . . . . . . . . . . . . . . . . . . . 3 3.5. Delete All RRsets on a Name . . . . . . . . . . . . . . . 3 3.6. Delete All RRsets of a Type . . . . . . . . . . . . . . . 4 3.7. Replace an RRset . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 4 4.1. Client side . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Server side . . . . . . . . . . . . . . . . . . . . . . . 5 5. IXFR Gone Wild: Even more optimized transfers . . . . . . . . 5 5.1. A more sophisticated grammar . . . . . . . . . . . . . . 6 5.2. Other approaches . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Informative References . . . . . . . . . . . . . . . . . 7 9.2. Normative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Incremental zone transfer (IXFR, [RFC1995]) was introduced to efficiently transfer changed portions of a zone. However, when a zone is signed with DNSSEC [RFC4033], [RFC4034], [RFC4035], the transfer can still become very large. For example, when many resource record sets (RRsets) need to be re-signed, or when the NSEC3 [RFC5155] salt is changed, an IXFR may become larger than a full zone transfer (AXFR, [RFC5936]). This is because the IXFR includes complete copies of both the deleted and replacement RRSIG records. To keep the deltas small in zone transfers, we need to have a richer change syntax, for example like in Dynamic Update (DNS UPDATE, [RFC2136]. This document introduces a new query type MIXFR (minimal incremental zone transfer) that is able to express this richer syntax. The goal of this proposal is to allow small changes to be communicated over UDP, and remove as much redundant information from the zone transfer as possible. An earlier proposal to keep the zone transfers small is IXFR-ONLY [IXFR-ONLY], by giving the client an oppurtunity to signal the server that it prefers an error above a fall back to an AXFR in case the Mekking & Gudmundsson Expires July 19, 2015 [Page 2] Internet-Draft MIXFR January 2015 server is not able to send an IXFR. However IXFR-ONLY did not reduce the size of an IXFR. 2. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Syntax The syntax for MIXFR is a superset of IXFR. The richer syntax of MIXFR allows to add or delete multiple records with one resource record (RR). MIXFR is DNSSEC aware thus if there is a change to RRset it knows to delete the covering RRISG(s), this saves the transmission of old RRsigs. 3.1. Implicit RRSIG deletion When an RRset is modified, the MIXFR client MUST also remove all existing RRSIG records on that RRset. This is valid for all RRtypes except RRSIG itself. 3.2. Add an RR This works the same as with IXFR, with implicit RRSIG delete logic added. 3.3. Delete an RR This works the same as with IXFR, with implicit RRSIG delete logic added. 3.4. Delete an RRset Similar to DNS UPDATE. To delete an RRset, the MIXFR deletion list includes an RR whose NAME and TYPE are those of the RRset to be deleted. CLASS must be specified as ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty. This also deletes the covering RRSIGs. 3.5. Delete All RRsets on a Name Similar to DNS UPDATE. To delete all RRSets at a name, the MIXFR deletion list includes an RR at that NAME, whose TYPE must be specified as ANY and CLASS must be specified as ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty. Mekking & Gudmundsson Expires July 19, 2015 [Page 3] Internet-Draft MIXFR January 2015 3.6. Delete All RRsets of a Type The MIXFR deletion list includes an RR whose NAME is that of the apex of the zone. TYPE must be specified as the TYPE of the RRsets to be deleted. CLASS must be specified as ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty. 3.7. Replace an RRset The MIXFR addition list includes an RR whose NAME and TYPE are those of the RRset to be replaced. CLASS must be specified as ANY. RDLENGTH must be non-zero and the RDATA is that of the first replacement record. If an RRset is to be replaced with multiple records, the second and subsequent records MUST use the syntax for adding an RR. The same syntax is used to delete an RRset and to replace an RRset with an RR whose RDLENGTH is zero. This is not ambiguous because the former appears in the deletion list (before the new SOA RR) and the latter appears in the addition list (after the new SOA RR). 4. Protocol Description 4.1. Client side The client can send a MIXFR request. Just like with IXFR, it places a SOA RR in the authority section to signal the version of the zone it holds now. If the client does not want the server to fall back to AXFR, it MAY add another SOA RR in the additional section. This achieves MIXFR-only behavior, similar to IXFR-ONLY [IXFR-ONLY]. For example: ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 1337 ;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;; example. IN MIXFR ;; AUTHORITY SECTION: example. IN SOA serial=1 ;; ADDITIONAL SECTION: example. IN SOA serial=1 Figure 1: A MIXFR request for the "example." zone. [MM] Adding a whole record is quite some overhead in bits while we only signal one bit of information: to fall back or not to fall back. Mekking & Gudmundsson Expires July 19, 2015 [Page 4] Internet-Draft MIXFR January 2015 [OG] Can we use a bit from header or OPT record? Or can we just use "Class | 0x8000" to signal that? 4.2. Server side A server receiving a minimal incremental zone transfer (MIXFR) request will reply with a MIXFR. A MIXFR looks exactly like an IXFR, except there may be zero or more of the new introduced syntax RRs that can add or delete more records. For the zone "example.", the following zone transfer can be sent that will replace all signatures in the zone with new signatures for the names "example.", "a.example.", "b.example." and "c.example.": ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 1337 ;; flags: qr ; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; example. IN MIXFR ;; ANSWER SECTION: example. IN SOA serial=3 example. IN SOA serial=1 example. ANY RRSIG example. IN SOA serial=3 example. IN RRSIG rdata a.example. IN RRSIG rdata b.example. IN RRSIG rdata c.example. IN RRSIG rdata example. IN SOA serial=3 Figure 2: A MIXFR response for the "example." zone. The server MAY reply with an IXFR or AXFR instead. If the server does not implement MIXFR it MUST return a response with NOTIMPL rcode. The client MUST fallback to request IXFR or AXFR. 5. IXFR Gone Wild: Even more optimized transfers This section is about how to accomplish similar behavior but by doing more radical change in syntax on the wire thus more changes in implementations. This is here for people to discuss the merits of different approaches to the overall goal: Smaller incremental transfers with DNSSEC. We can optimize the transfer even more, because when adding an RRset we duplicate a lot of owner names, class and type fields. Instead of falling back to UPDATE syntax, we can invent a new zone transfer syntax. For example. we could add an NS RRset of three records like this: Mekking & Gudmundsson Expires July 19, 2015 [Page 5] Internet-Draft MIXFR January 2015 ADD example. IN NS 3 ns1.example. ns2.example. ns3.example. Figure 3: Optimized addition of an NS RRset. With such a syntax, we can do more things like REPLACE {n} REPLACE-RRSIG {n} SOA Figure 4: Optimized syntax ideas for MIXFR. 5.1. A more sophisticated grammar DEL NSEC3 ? REPLACE NSEC3PARAM REPLACE-NS + GLUE + SOA Figure 5: More optimizations syntax ideas for MIXFR. Another idea: the whole way to present the complete RRset ADD {n} {m} REPLACE {n} {m} if only signatures then n = 0 Figure 6: And more optimizations syntax ideas for MIXFR. Strictly speaking we can save a few bytes by doing the following in RRSIG: KEY now the RRSIG parts only needs the real crypto signature. 5.2. Other approaches In many cases DNS servers have many zones in common, and there are many changes in the zones each hour, in this case having a long lived TCP connection where the primary server can push changes to the secondary. This kind of protocol will require more drastic changes, thus it will be covered by a separate, future document. 6. IANA Considerations Mekking & Gudmundsson Expires July 19, 2015 [Page 6] Internet-Draft MIXFR January 2015 IANA is requested to assign the OPCODE value [TBD] (decimal) for MIXFR, in sub-registry "DNS OpCodes" of registry "Domain Name System (DNS) Parameters". 7. Security Considerations This document does not introduce additional security considerations. Or does it? Should we explain what the security implications are, because descriptions from old RFC's are not good enough? Any MIXFR transactions should use secure channels such as IPSEC or SSH tunnel, and use TSIG for authenticaion. 8. Acknowledgements Johan Ihren, Tony Finch. 9. References 9.1. Informative References [IXFR-ONLY] Sury, O. and S. Kerr, "IXFR-ONLY to Prevent IXFR Fallback to AXFR", February 2010, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol (AXFR)", RFC 5936, June 2010. Mekking & Gudmundsson Expires July 19, 2015 [Page 7] Internet-Draft MIXFR January 2015 9.2. Normative References [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. Appendix A. Changelog o Initial version Authors' Addresses W. (Matthijs) Mekking Dynamic Network Services Inc 150 Dow Street Manchester NH 03101 US EMail: mmekking@dyn.com URI: https://www.dyn.com Olafur Gudmundsson CloudFlare San Francisco, CA 94107 USA EMail: olafur@cloudflare.com Mekking & Gudmundsson Expires July 19, 2015 [Page 8]