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 <name> <type> <n> <rdata>{n}
REPLACE-RRSIG <name> <type> <n> <rdata>{n}
SOA <serial>
Figure 5: Optimized syntax ideas for MIXFR.
5.3. A more sophisticated grammar
REPLACE-RRSIG name <type> <n> <rdata>+
DEL NSEC3 <nsec3param info> ?
REPLACE NSEC3PARAM
REPLACE-NS <name> <n> <rdata>+
GLUE <name> <type> <n> <rdata>+
SOA <serial>
Figure 6: More optimizations syntax ideas for MIXFR.
Idea: the whole way to RRset
ADD <type> <n> <m> <Rdata>+n <RRSIG>+m
REPLACE <type> <n><m><Rdata>*n <RRSIG>*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 <alg><lables><origTTL><end-time><start-time><key-id><signer>
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, <https://tools.ietf.org/html/
draft-kerr-ixfr-only-01>.
[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]