Zone Transfers

This section examines how changes are propagated from the master to the slave name server. When the slave server restarts, or when it periodically queries the master server and finds updated records, a zone transfer is performed between the master and slave servers.

This is just a transfer of the zone maps or DNS records from the master server to the slave server. Unlike most DNS transactions, this is done using TCP because there is potentially a lot of data and reliable delivery is important. The zone transfer seems like an innocuous process. It usually is between the same domain master and slave servers. Yet, what if a hacker could do a zone transfer of your domain data for your internal hosts? This would give him all the IP addresses and hosts in your domain. This is very valuable data that should not be readily available to anyone.

Obviously, you would like to try to prevent this kind of misuse. You can do this in a couple of ways. In versions of BIND 4.9.3 and later, configuration parameters enable the DNS administrator to specify IP addresses or subnets authorized to do zone transfers. BIND 4.9.x has an xfernets directive, and BIND 8 and 9 have an allow-transfer substatement to control zone transfers.

If your version of BIND does not support this feature, another option is to block inbound traffic to TCP port 53. This block prevents transfers, but might block other legitimate data as well (as discussed in the very next section). If this is your only option, however, it is preferable to

prevent the zone transfer, even at the expense of blocking other legitimate data.

UDP or TCP

As discussed earlier, typically, DNS traffic is sent using UDP because answers are often succinct, and a best-delivery effort can be tolerated because responses to DNS queries not received can be reissued. Because there is more data for zone transfers, and reliable exchange is required, they are an exception to the UDP protocol and are done using TCP.

The maximum allowable size for a UDP DNS payload response is 512 bytes. What happens if the data contained in the DNS message exceeds 512 bytes? First, the response is returned with the truncated bit turned on. This bit is found in the flags field spanning offset bytes 2 and

3 of the DNS message:

dns.my.com.53 > dns.verbose.com.53: 18033 (43) (DF) dns.verbose.com.53 > dns.my.com.53: 18033| 7/0/0 (494)

dns.my.com.37404 > dns.verbose.com.53: S 518696698:518696698(0) win 8760 <mss

1460> (DF)

dns.verbose.com.53 > dns.my.com.37404: S 199578733:199578733(0) ack 518696699

win 8760 <mss 1460> (DF)

In the preceding output, look carefully at the second line of TCPdump output. The response is from dns.verbose.com to dns.my.com. After the DNS identification number, 18033, you see a vertical line, or UNIX pipe symbol. This is the notation that TCPdump uses to alert you that the DNS record has been truncated. The response of seven resource records would have exceeded the 512-byte payload limit. You see that 494 bytes of payload are returned, consisting of complete answers that do not exceed the limit.

Therefore, dns.my. com reissues the DNS query using TCP. You see the attempted SYN connection from dns.my.com to dns.verbose.com. dns.verbose.com responds with a SYN/ACK, indicating that it is listening on port 53. The information is then transferred using TCP as the protocol.

Some sites will block all inbound TCP traffic with either a source or destination port of 53 to prevent unauthorized zone transfers. But, this will also block any queried external DNS server from resolving large responses. That is what happens in the preceding output. The fourth line in the previous output shows the packet with the SYN/ACK from dns.verbose.com that got blocked. Our packet-filtering device in front of dns.my.com blocks a TCP connection from