The fields of this SOA resource record, in particular the "serial number", determine whether the actual data transfer need to occur at all.
If the serial numbers are identical, the data in the zone are deemed not to have "changed", and the client may continue to use the copy of the database that it already has, if it has one.
Although DNS technically supports AXFR over User Datagram Protocol (UDP), it is considered not acceptable due to the risk of lost, or spoofed packets.
The end of the data is signaled by the server repeating the response containing the SOA resource record for the zone apex.
Some zone transfer clients perform the SOA lookup of the preamble using their system's normal DNS query resolution mechanism.
These clients do not open a TCP connection to the server until they have determined that they need to perform the actual data transfer.
Some DNS server packages have overcome this problem by automatically constructing the serial number from the last modification timestamp of the database file on disk.
This paradigm simply does not match that of a single, central, monotonically increasing number to record changes, and thus is incompatible with zone transfer to a large extent.
[citation needed] Modern DNS server packages with sophisticated database back ends often will create a "shim" serial number, simulating the existence of a single central place where updates are made, but this is at best imperfect.
However, this is inefficient, and some DNS server software implemented optimizations, geared at allowing the response compression mechanism in the DNS protocol to reduce the total bandwidth requirements of data transfers, such as: Some clients were written to expect only the original response format, and would fail to perform data transfer if such optimizations were employed.
Several DNS server packages thus have a configuration setting allowing administrators to specify the use of "single answer format" responses for those clients that require it.