Zone transfer
In the Domain Name System (DNS), zone transfer refers to the transfer of zones to another server. This procedure is abbreviated to AXFR ( Asynchronous Full Transfer Zone or Asynchronous Xfer Full Range ). Since a DNS failure usually has serious consequences for a company, the DNS data - i.e. the zone files - are kept identically on several name servers almost without exception. In the event of changes, it must be ensured that all servers have the same database. The synchronization between the servers involved is realized through the zone transfer . The zone transfer not only includes the mere transfer of files or records, but also the detection of deviations in the databases of the servers involved.
The original data of a zone are stored on a DNS server, which is referred to as the primary name server (short: Primary) for this zone. To increase the reliability, to implement a simple load distribution or to protect the primary from attacks (see also: Hidden Primary ), one or more additional servers are installed in practice in almost all cases, which act as secondary name servers (for short: Secondary) for them Zone. With some top level domains (e.g. de. ) It is even a requirement to make zone files for the second level domains accessible on at least two servers.
A DNS server cannot be generally referred to as primary or secondary. This function must always be viewed in relation to a zone . A DNS server can be primary for one zone and secondary for another zone.
The DNS information of a primary and a secondary are considered to be qualitatively equivalent. Both primary and secondary are authoritative for a zone; H. their data can be trusted absolutely (in contrast, data from DNS caches, for example, are considered non-authoritative because they can be out of date).
DNS entries are generally only created, changed or deleted on the primary. This can be done by manually editing the relevant zone file or automatically by means of a dynamic update from a database. Microsoft's DNS server is an exception. With this, data can be entered in an Active Directory-integrated zone in both the primary and the secondary zone.
A DNS server that serves as the direct source for synchronizing a zone file is called a master . A DNS server that receives the zone data from a master is called a slave . A primary is always the master, while a secondary can be both slave and master. It is a slave if it receives the zone data from a master; it is the master if it itself serves as a source for further secondary servers. This nesting of secondary servers is often used to reduce the load on the primary server from the zone transfer.
This procedure was introduced in the original DNS specification and used for the first time with the DNS server BIND. In addition to AXFR, there is also the newer IXFR ( RFC 1995 ), which only transfers changed records and not the entire zone. There are two methods for synchronization between master and slave:
Notify procedure
The master notifies all slaves in a zone as soon as something has changed in the zone. The slave then either requests the complete zone or - better - only the changed resource records via incremental zone transfer . The information about who is the slave is derived indirectly from the NS resource records of a zone. The master is listed in the SOA resource record . All other servers listed in NS-RRs are automatically considered slaves.
Slave fetch method
The slave fetches the SOA resource record of the zone in question from the master at certain intervals (the so-called refresh time , which is typically one hour) and compares the serial numbers . If the serial number of the master's SOA-RR is greater than that of the slave, the data stocks no longer match. The slave then either requests the complete zone or - better - only the changed resource records via incremental zone transfer. The relevant parameters (e.g. serial number and refresh timer) are located in the SOA-RR. The master defines these values and forces them on the slaves.
The notify procedure is clearly superior to the slave fetch procedure, since changes are transmitted to the slaves more quickly. It's standard today. For zone transfer, TCP is always used and not, as with DNS requests, UDP .
safety
The servers use a secret key ( called rndc-key in BIND ) to ensure that they really communicate with their master / slave.