DNS zone transfer

Zone transfer referred to in the Domain Name System (DNS ) is the transfer of zones to another server. This method is abbreviated AXFR (Asynchronous Full Transfer Zone) or (Asynchronous Xfer full range). Since a DNS failure for a company usually has serious consequences, the DNS data - ie the zone files - held almost without exception identical to multiple name servers. If changes must be ensured that all servers have the same data. The synchronization between the servers involved is realized by the zone transfer. The zone transfer includes not only the mere transfer files or records, but also the detection of variations in the data held by the servers involved.

The original data of a zone are on a DNS server (in short: Primary) as a primary name server is known for this zone. To increase the reliability, implement a simple load balancing or to the Primary to protect against attacks (see also: Hidden Primary) are in practice in almost all cases or installed several additional servers as secondary name server (short: Secondary) for this zone are recorded. Some top level domains ( eg, de. ), It is even required to make zone files for the Second Level Domains on at least two servers to access.

A DNS server can not be referred to collectively as Primary or Secondary. This function is always to be considered with respect to a zone. It may make for another zone a Primary DNS server for a zone and Secondary.

The DNS information of a Primary and a Secondary are considered of equivalent quality. Both Primary and Secondary are authoritative for a zone, ie, their data can be trusted absolutely (as opposed to data from DNS caches for example, regarded as non- authoritative, since they may be out of date).

DNS entries are generally created, modified or deleted only on the Primary. This can be done by manually editing the relevant zone file or automatically by dynamic update of a database. An exception is the DNS server from Microsoft. In this zone data can be entered in an Active Directory-integrated zone both in the primary and in the secondary.

A DNS server, which is used as a direct source of the synchronization file of a zone is called a master. A DNS server that refers to the zone data from a master, called the slave. A Primary is always the master while a Secondary both the slave and master can be. He is a slave if he obtains the zone data from a master; he is the master, if he himself is the source for more secondaries. This nesting of secondaries is often used to reduce the load on the primarys through the zone transfer.

This procedure was introduced in the original DNS specification and first used by the BIND DNS server. Besides AXFR there is the newer IXFR (RFC 1995), the only transfers changed record and not the entire zone. For the synchronization between master and slave are two methods:

Notify methods

The master notifies all slaves of a zone once in the zone something has changed. The slave then calls either the complete zone or - better - by incremental zone transfer only the changed resource records. 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 slave.

Slave - fetching system

The slave brings in certain intervals ( the so-called refresh time, which is typically one hour) the SOA resource record of the zone from the master and compares the serial numbers. If the serial number of the SOA RRs greater than that of the master of the slave, the data sets are out of sync. The slave then calls either the complete zone or - better - by incremental zone transfer only the changed resource records. The relevant parameters (such as serial number and refresh timer ) are located in the SOA RR. The master sets the values ​​and forces them to the slaves.

The Notify method is superior to the slave - fetching system significantly, since changes are delivered faster to the slaves. It is standard today. For zone transfer TCP is generally used, and not, as in DNS requests, UDP.

Security

By means of a secret key ( for BIND rndc -key called ) ensure the servers that they really communicate with her ​​master / slave.