Network Working Group W. Mekking Internet-Draft NLnet Labs Intended status: Experimental O. Gudmundsson Expires: January 5, 2015 Shinkuro Inc. July 4, 2014 Minimal Incremental Zone Transfer in DNS draft-mekking-mixfr-00 Abstract This document proposes extensions to the DNS protocol to provide an incremental zone transfer (IXFR) mechanism with dynamic update (UPDATE) capabilities, to make zone transfers even smaller. 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 January 5, 2015. Copyright Notice Copyright (c) 2014 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 January 5, 2015 [Page 1] Internet-Draft MIXFR July 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Add an RR . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Delete an RR . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Delete an RRset . . . . . . . . . . . . . . . . . . . . . 3 3.4. Delete All RRsets on a Name . . . . . . . . . . . . . . . 3 3.5. Delete All RRsets of a Type . . . . . . . . . . . . . . . 3 3.6. Replace an RRset . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 4 4.1. Client side . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Server side . . . . . . . . . . . . . . . . . . . . . . . 4 5. Data Minimization . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Implicit RRSIG deletion . . . . . . . . . . . . . . . . . 5 5.2. More optimizations . . . . . . . . . . . . . . . . . . . 6 5.3. A more sophisticated grammar . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Informative References . . . . . . . . . . . . . . . . . 7 10.2. Normative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 9 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 may still become very large. For example, when many resource record sets (RRsets) need a re-sign, 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 update 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. 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 January 5, 2015 [Page 2] Internet-Draft MIXFR July 2014 server is not able to send an IXFR. However IXFR-ONLY does 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 IXFR is a subset of MIXFR. The richer syntax of MIXFR allows to add or delete multiple records with one resource record (RR). 3.1. Add an RR This works the same as with IXFR. 3.2. Delete an RR This works the same as with IXFR. 3.3. 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. 3.4. 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. 3.5. 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. Mekking & Gudmundsson Expires January 5, 2015 [Page 3] Internet-Draft MIXFR July 2014 3.6. 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. 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.": Mekking & Gudmundsson Expires January 5, 2015 [Page 4] Internet-Draft MIXFR July 2014 ;; ->>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. Data Minimization The proposal described in the previous section significantly reduces the size of a zone transfer compared with IXFR. However, when a zone has changed its NSEC3 salt, the impact is less impressive. This is because you need to remove all NSEC3 records and all its corresponding signatures. The first part is achieved with: example. ANY NSEC3 Figure 3: Record to delete all RRsets of type NSEC3. But we can't do the same for part two, because there are other signatures than those covering type NSEC3. However, because RRSIG records are tightly related to its RRset we can introduce some additional data minimization rules. 5.1. Implicit RRSIG deletion When an RR or RRset is deleted or replaced, the MIXFR client MUST also remove all existing RRSIG records on that RRset. This is valid for all RRtypes except RRSIG itself. Mekking & Gudmundsson Expires January 5, 2015 [Page 5] Internet-Draft MIXFR July 2014 5.2. More optimizations We can optimize the transfer even more, because when adding an RRset we duplicate a lot of owner names, class and type fields. For example. we could add an NS RRset of three records like this: ADD example. IN NS 3 ns1.example. ns2.example. ns3.example. Figure 4: Optimized addition of an NS RRset. With such a syntax, we can do more things like REPLACE {n} REPLACE-RRSIG {n} SOA Figure 5: Optimized syntax ideas for MIXFR. 5.3. A more sophisticated grammar REPLACE-RRSIG name + DEL NSEC3 ? REPLACE NSEC3PARAM REPLACE-NS + GLUE + SOA Figure 6: More optimizations syntax ideas for MIXFR. Idea: the whole way to RRset ADD +n +m REPLACE *n *m if only signature then n = 0 Figure 7: 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 need to re real signature. Mekking & Gudmundsson Expires January 5, 2015 [Page 6] Internet-Draft MIXFR July 2014 6. IANA Considerations IANA should assign the RR type value [TBD] (decimal) for MIXFR. 7. Security Considerations This document does not introduce additional security considerations. 8. Acknowledgements Johan Ihren, Tony Finch. 9. Changelog 9.1. 00 o Initial document. 10. References 10.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 January 5, 2015 [Page 7] Internet-Draft MIXFR July 2014 10.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. Mekking & Gudmundsson Expires January 5, 2015 [Page 8] Internet-Draft MIXFR July 2014 Appendix A. Changelog o Initial version Authors' Addresses W. (Matthijs) Mekking NLnet Labs Science Park 400 Amsterdam 1098 XH NL EMail: matthijs@nlnetlabs.nl URI: http://www.nlnetlabs.nl/ Olafur Gudmundsson Shinkuro Inc. 4922 Fairmont Av, Suite 250 Bethesda MD 20814 USA EMail: ogud@ogud.com Mekking & Gudmundsson Expires January 5, 2015 [Page 9]