wiki:Rfc1995DetailedRequirements

RFC 1995

Incremental transfer of zone information (IXFR) is described in this standard. Rather than transfer the entire zone between a master and slave when the zone is updated, this RFC describes a protocol whereby only differences between the information in the master and slave is transferred.

This document is a breakdown of the RFC and itemises the requirements detailed in that RFC. Each requirement has the following information:

  • The number of the requirement. (This is the location within the document of the requirement in the form section/paragraph/sequence. The optional /paragraph is the number of the paragraph in the section and the /sequence (also optional) distinguishes multiple requirements in the same paragraph.
  • The requirement itself.
  • Whether BIND 10 implements the requirement.
  • Any qualifications or notes.
Number Requirement Implemented Notes
2/3 When the client is updated with an IXFR, the updated zone should be saved to stable storage before the client serves queries.
2/4 If the server receives an IXFR query with the same or newer serial number as its own, it should reply with a single SOA record:
* Opcode is query, QR bit is 1 (response)
* QNAME is the name of the zone, QTYPE is IXFR
* Answer section comprises SOA record of the zone
* Authority and Additional sections are empty
2/5/a The server should support IXFR over both TCP and UDP
2/5/b If the server receives a UDP IXFR query, and the response (format described in requirements 4/2 and 4/3) fits in a UDP packet, it should return the response via UDP.
2/5/c If the server receives a UDP IXFR query, and the response (format described in requirements 4/1, 4/2 and 4/3) does not fit in a UDP packet, it should return the single SOA record response (format described in requirement 2/4) via UDP.
2/6/a The client must first query the server by sending out an IXFR query over UDP in the format specified in requirement 3/1.
2/6/b If the response to the IXFR query indicates that the server does not recognise IXFR, the client should try an AXFR request (preceded with a query for the SOA).
2/6/c If the response to the IXFR query is a packet containing the entire zone, the transfer is complete.
2/6/d If the response to the IXFR query is a UDP packet containing an SOA (format described in requirement 2/4) whose serial number is equal to or less than the serial number of the client, the server does not have a newer zone than the client, and the client should stop the transaction.
2/6/e If the response to the IXFR query is a UDP packet containing an SOA (format described in requirement 2/4) whose serial number is greater that the serial number of the client, the client should retry the IXFR query using TCP.
2/7/a The server should enable UDP checksums for all responses.
2/7/b A client that receives an IXFR UDP packet is a checksum of 0 should retry the IXFR using TCP.
3/1 The transfer must be initiated by the client sending out a query:
* Opcode is query, QR bit is 0 (query)
* QNAME is the name of the zone, QTYPE is IXFR
* The Authority section contains the SOA of the client
* The Answer and Additional sections are empty
4/1 If incremental zone transfer is not available, the entire zone is returned:
* Opcode is query, QR bit is 1 (response)
* QNAME is the name of the zone, QTYPE is IXFR
* Answer section comprises:
-- 1. SOA record of the zone
-- 2. All other records in the zone
-- 3. SOA record of the zone
* Authority and Additional sections are empty
Note that by requirement 2/5/c, if the response does not fit within a UDP packet, an SOA record must be returned indicating that the IXFR should be retried over TCP.
4/2 If incremental zone transfer is available, the server returns a message comprising one or more difference sequences:
* Opcode is query, QR bit is 1 (response)
* QNAME is the name of the zone, QTYPE is IXFR
* Answer section comprises:
-- 1. SOA record of the zone
-- 2. Difference sequences
-- 3. SOA record of the zone
* Authority and Additional sections are empty
4/3 Each difference sequence represents one update to the zone and comprises:
* The SOA of the older version of the zone
* A list of RRs that should be deleted from the client's copy of that version of the zone. (Note: the SOA is one of the records that should be deleted.)
* The SOA of the newer version of the zone.
* A list of RRs that should be added to the client's copy of that version of the zone. (Note: the SOA is one of the records that should be added.)
If an RR is part of an RRset, only the RR is question is changed - the rest of the RRset remains untouched. (Clarification from paragraph 4/6.)
4/4 When processing difference sequences, the server must remove the RRs to be deleted before adding the new RRs.
4/5 Difference sequences in the response must be ordered in order of ascending SOA.
4/7 The application of the IXFR received by the client should be atomic. Either all differences specified in an IXFR must be applied to the zone or none of them must be applied.
5/1 The server should hold information about previous versions of the zone. This requirement is optional: the number of versions is not specified, so the server may respond with an AXFR if it doesn't hold the required difference.
5/2/a The server should not send an IXFR if the total length of an IXFR response would be greater than the length of an AXFR.
5/2/b The server should remove old versions of the zone if the total length of an IXFR response (from that version of the zone) would be greater than the length of an AXFR.
5/3 The server may get rid of versions of the zone older than the SOA expire time. This requirement is optional.
6/1 The server may condense multiple difference sequences into a single difference sequence. This requirement is optional.
6/5 If a server receives a request containing an SOA for which it holds no difference information, it should attempt to perform an AXFR (i.e. return the entire zone in a packet if possible, or return a single SOA to indicate that an AXFR over TCP should be tried (as in requirement 2/6/e)).

The following requirements are not directly stated in RFC 1995 but can be reasonably inferred from a reading of the text.

Number Requirement Implemented Notes
A/1 When the SOA refresh time is reached and IXFR is enabled, the client should send an IXFR request to the server.
A/2 If an IXFR packet is received that includes one or more deletions of records that are not in the zone, the entire IXFR update should be rejected. Such a situation would imply that the version of the zone in the IXFR client is not the same as the same version of that zone in the IXFR server. As a result, applying the IXFR could corrupt the zone further.
Last modified 6 years ago Last modified on Nov 16, 2011, 3:49:37 PM