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.
Adding of Subdomain
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.
The zone should be available from more than one DNS server on the network. This is 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.
Zone Transfer
1) During the new configuration, the destination server sends an initial “all zone” transfer (AXFR) request. This is 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. It is the one established by the use of a Serial number field in the properties. This is made 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). This is to indicate when the destination server should next request to renew the zone with the source server.
SOA RR
4) When the refresh interval expires, an SOA query is used by the destination server. This is to request the 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. Further,
it determines how to renew the zone.
8) When 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. Also that a zone transfer is not needed. The destination server then renews the zone by resetting its refresh interval. This is 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.
At the Source Server end
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 notify secondary servers whenever changes are made through a NOTIFY request. Most DNS servers will request a Zone Transfer whenever such a notification is received.
