Incremental zone transfer (IXFR, ) was introduced to efficiently transfer changed portions of a zone. However, when a zone is signed with DNSSEC , , , the transfer can still become very large. For example, when many resource record sets (RRsets) need to be re-signed, or when the NSEC3 salt is changed, an IXFR may become larger than a full zone transfer (AXFR, ). 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, . 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 , 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 server is not able to send an IXFR. However IXFR-ONLY did not reduce the size of an IXFR.
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 .
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.
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.
This works the same as with IXFR, with implicit RRSIG delete logic added.
This works the same as with IXFR, with implicit RRSIG delete logic added.
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.
Note that a record with its CLASS set to ANY does not mean to delete (or change) the record in all available classes: zone transfers are encapsulated in SOA records that determine the zone name and class (see Figure ()[#fig:a-MIXFR-response]). Only changes in the zone matching that name and class will be made.
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.
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).
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 . 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
^[fig:a-MIXFR-request::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. [OG] Can we use a bit from header or OPT record? Or can we just use "Class | 0x8000" to signal that?
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
^[fig:a-MIXFR-response::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.
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 or an out-of-band protocol where the primary server can push changes to the secondary.
The size of the zone transfer can be reduced even more if the syntax on the wire is changed, i.e. the RR wire format is abandoned. A different grammar may add operators, remove duplicate RRset owner names, and use standard compression algorithms.
These kind of improvements will require more drastic changes, and may be covered in a separate, future document.
IANA is requested to assign the RR Type value [TBD] (decimal) for MIXFR, in sub-registry "Resource Record (RR) TYPEs" of registry "Domain Name System (DNS) Parameters".
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 authentication.
Johan Ihren, Tony Finch, Bob Harold, Pieter Lexis.