A zone starts as a storage database for a single DNS domain name. If other domains are added below the domain used to create the zone, these domains can either be part of the same zone or belong to another zone. Once a subdomain is added, it can then either be
1) Managed and included as part of the original zone records, or 2) Delegated away to another zone created to support the subdomain
Because of the important role that zones play in DNS, zone should be available from more than one DNS server on the network to provide availability and fault tolerance when resolving name queries. Otherwise, if a single server is used and that server is not responding, queries for names in the zone can fail. For additional servers to host a zone, zone transfers are required to replicate and synchronize all copies of the zone used at each server configured to host the zone.
A primary server has the “master copy” of a zone, and secondary servers keep copies of the zone for redundancy.When changes are made to zone data on the primary DNS server, these changes must be distributed to the secondary DNS servers for the zone.This is done through zone transfers.
1) During new configuration, the destination server sends an initial “all zone” transfer (AXFR) request to the master DNS server configured as its source for the zone.
2) The master (source) server responds and fully transfers the zone to the secondary (destination) server.
3) The zone is delivered to the destination server requesting the transfer with its version established by use of a Serial number field in the properties for the start of authority (SOA) resource record (RR). The SOA RR also contains a stated refresh interval in seconds (by default, 900 seconds or 15 minutes) to indicate when the destination server should next request to renew the zone with the source server.
4) When the refresh interval expires, an SOA query is used by the destination server to request renewal of the zone from the source server.
5) The source server answers the query for its SOA record.
6) This response contains the serial number for the zone in its current state at the source server.
7) The destination server checks the serial number of the SOA record in the response and determines how to renew the zone.
8) If the value of the serial number in the SOA response is equal to its current local serial number, it concludes that the zone is the same at both servers and that a zone transfer is not needed. The destination server then renews the zone by resetting its refresh interval based on the value of this field in the SOA response from its source server.
9) If the value of the serial number in the SOA response is higher than its current local serial number, it concludes that the zone has been updated and that a transfer is needed.
10) If the destination server concludes that the zone has changed, it sends an IXFR query to the source server, containing its current local value for the serial number in the SOA record for the zone.
11) The source server responds with either an incremental or full transfer of the zone.
12) If the source server supports incremental transfer by maintaining a history of recent incremental zone changes for modified resource records, it can answer with an incremental zone transfer (IXFR) of the zone.
13) If the source server does not support incremental transfer, or does not have a history of zone changes, it can answer with a full (AXFR) transfer of the zone instead.
Most DNS servers automatically notifies secondary servers whenever changes are made through a NOTIFY request, and most DNS servers will request a Zone Transfer whenever such a notification is received.