Editing DNS zone transfer (section)

==Operational problems==
{{Multiple issues|{{More citations needed section|date=July 2021}}{{Essay-like|section|date=July 2021}}|section=yes}}

===Serial number changes===
The preamble portion of zone transfer relies on the serial number, and ''only'' the serial number, to determine whether a zone's data have changed, and thus whether the actual data transfer is required. For some DNS server packages, the serial numbers of SOA resource records are maintained by administrators by hand. Every edit to the database involves making two changes, one to the record being changed and the other to the zone serial number. The process requires accuracy: the administrator may forget to change the serial number or change it incorrectly (reduce it). RFC 1912 (section 2.2 SOA records) recommends using the value YYYYMMDDnn as the number (YYYY=year, MM=month, DD=day, nn=revision number). This won't overflow until the year 4294.

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 is the case for [[djbdns]], for example. The operating system ensures that the last modification timestamp is updated whenever an administrator edits the database file, effectively automatically updating the serial number, and thus relieving administrators of the need to make two edits (in two different places) for every single change.

Furthermore, the paradigm of database replication for which the serial number check (and indeed zone transfer itself) is designed, which involves a single central DNS server holding the primary version of the database with all other DNS servers merely holding copies, simply does not match that of many modern DNS server packages.{{Citation needed|date=July 2021}} Modern DNS server packages with sophisticated database back ends such as [[SQL]] servers and [[Active Directory]] allow administrators to make updates to the database in multiple places (such systems employ [[multi-master replication]]), with the database back end's own replication mechanism handling the replication to all other servers. 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|date=July 2021}} 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.

Fortunately, for this and several reasons outlined later, DNS servers that use such sophisticated database back ends in general rarely use zone transfer as their database replication mechanism in the first place, and usually instead employ the vastly superior distributed database replication mechanisms that the back ends themselves provide.{{Citation needed|date=July 2021}}

===Serial number comparisons===
Serial number comparisons are intended to use [[Serial Number Arithmetic]] as defined in RFC 1982.  However, this was not clearly specified in RFC 1034, resulting in not all clients perform the serial number check, in the preamble, in the same way. Some clients check merely that the serial number supplied by the server is different from that known by the client, or non-zero. Other clients check that the serial number supplied by the server is within a given range of the serial number already known by the client. Yet other clients still perform the latter check and additionally check that the serial number supplied by the server is not zero.

===Multiple resource records===
Originally, in the actual data transfer each set of resource records for a single domain name and type was transferred in a separate response message from the server to the client. 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:
* performing "additional section processing" to include any "glue" resource record sets in the same response as an NS, SRV, or MX resource record set
* collecting all of the resource record sets relating to a single domain name together and sending them, if they fit, in a single response

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.

===Exposure of data===
The data contained in a DNS zone may be sensitive from an operational security aspect. This is because information such as server hostnames may become public knowledge, which can be used to discover information about an organization and even provide a larger [[attack surface]]. In June 2017 the registrar responsible for Russian top-level-domains accidentally enabled DNS zone transfers via AXFR which led to 5.6 million records being accidentally exposed.<ref>{{Cite news|url=https://securitytrails.com/blog/russian-tlds|title=Wrong Bind Configuration Exposes the Complete List of Russian TLD's to the Internet|date=2018-03-14|work=SecurityTrails Blog|access-date=2018-04-10|language=en}}</ref>

In 2008 a court in North Dakota, USA, ruled that performing a zone transfer as an unauthorized outsider to obtain information that was not publicly accessible constitutes a violation of North Dakota law.<ref>{{cite news|title=Anti-spammer fined for accessing DNS records of private network|url=http://www.h-online.com/security/news/item/Anti-spammer-fined-for-accessing-DNS-records-of-private-network-735841.html|newspaper=The H|date=18 January 2008}}</ref>