Last Updated on
Zone transfers are an important part of distributing changes between name servers. Every domain on the internet (and within private networks for that matter) much have a master server which contains the definitive records of names and addresses for that domain. Zone transfers are the system which allows any changes on the master server be distributed out to the slave name servers which could be spread far and wide. It’s important that these are done regularly even if changes are not frequent if only to ensure the validity of the current name space.
For example when a slave name server restarts, or a periodic intervals it will contact the master server if possible and check for updated records. If the server finds updates then it will requests a zone transfer from the master server. This is simply a transfer of zone maps and DNS records from the master to the slave name server, it performs the core function for keeping a DNS service up to date. What is different from the majority of DNS transaction, the protocol used in this instance is TCP. The main reason is that a Zone transfer will potentially contain a huge amount of data in many instances and to ensure reliable delivery TCP is the best transport mechanism that is usually available.
The Zone transfer is obviously a huge target for any hacker who wants to attempt to compromise a domain or specific server. Being able to intercept or even modify zone transfers gives an attacker the potential to take over any system. Obviously modifying addresses will be difficult for any attacker but even intercepting these transfers can be very dangerous. A zone file includes the details of every device on a specific network or domain, all ip addresses assigned to every device. Some of these hosts will typically be non-internet facing for security reasons, so it’s important that zone transfers are secured. This relies on configuration of the name servers themselves, and in particular how zone transfers are accomplished. In versions of BIND 4.9.4 and later for example you can modify parameters to specify only certain ip addresses or subnets to be authorised to both send and receive transfers. There are other useful security features implemented in later versions of BIND too.
For older systems, you should ideally look to update, however blocking traffic to port 53 which is the standard port for the transfer of DNS traffic could be viable. However these port blocking solutions can often cause other difficulties with specific applications and internal devices, you may very well end up blocking legitimate traffic and breaking applications. Like breaking the vice director’s international VPN which he uses to watch ITV in Spain, this sounds an unlikely scenario for DNS security measures but one that’s happened to me !!