These instructions assume that you are already running tinydns as a DNS server. If you followed the instructions for upgrading from BIND, you're already answering TCP queries, so you don't need to do anything.
1. As root, create UNIX accounts named Gaxfrdns and Gdnslog.
2. As root, create an /etc/axfrdns service directory, configured with the name of your existing tinydns service directory and the IP address of your DNS server:
axfrdns-conf Gaxfrdns Gdnslog /etc/axfrdns /etc/tinydns 188.8.131.52
3. As root, create /etc/axfrdns/tcp as follows:
echo ':allow,AXFR=""' > /etc/axfrdns/tcp
4. If you want to allow an IP address to transfer a zone from your DNS server, add it to /etc/axfrdns/tcp:
echo '184.108.40.206:allow,AXFR="heaven.af.mil"' >> /etc/axfrdns/tcpHere 220.127.116.11 is the IP address, and heaven.af.mil is the zone to be transferred. You can list several zones separated by slashes:
echo '18.104.22.168:allow,AXFR="heaven.af.mil/panic.mil"' >> /etc/axfrdns/tcpIf you want to allow transfers of all zones, omit the ,AXFR="...":
echo '22.214.171.124:allow' >> /etc/axfrdns/tcp
5. As root, compile /etc/axfrdns/tcp into a hashed database:
cd /etc/axfrdns makeYou will need to repeat this step if you change /etc/axfrdns/tcp.
6. As root, tell svscan about the new service, and use svstat to check that the service is up:
ln -s /etc/axfrdns /service sleep 5 svstat /service/axfrdns
If you aren't in any of those situations, you have no need to provide TCP service, and you should not set it up. DNS-over-TCP is much slower than DNS-over-UDP and is inherently much more vulnerable to denial-of-service attacks. (This applies to BIND too.)
There are several easy-to-use standard tools that copy files. The scp program, part of OpenSSH [www.openssh.com], provides secure, compressed file transfers. You can use rsync [rsync.samba.org] to perform incremental copies, which transmit only a small amount of data through the network for a small change to a large file.
Zone transfers are an archaic alternative mechanism for copying DNS information. Instead of immediately sending new data to the slaves, you run a zone-transfer service that accepts periodic connections from the slaves; your users complain while they're waiting for the slaves to check for new data. The zone-transfer protocol isn't a modular file-transfer system; it is an ad-hoc system tied to the details of DNS. The protocol has terrible compression and no security. Every new zone on the master requires manual reconfiguration of the slaves. Zone transfers lose all information about client differentiation and scheduled record changes.
Zone transfers have one redeeming feature: zone-transfer software is very widespread. You may be forced to use zone transfers if your slaves don't support anything better. (On the other hand, you could choose better slaves.)
There has been some work on improving the zone-transfer protocol: a NOTIFY mechanism that wakes up the slaves (after a delay, and without a failure notice when something goes wrong); an experimental IXFR mechanism for incremental zone transfers (although the BIND implementation doesn't work for zone files modified by hand or by external tools); and several proposed security mechanisms, notably TSIG. BIND's May 2001 IXFR and TSIG implementations are supposedly free of the bugs that caused crashes, data corruption, and root exploits in previous versions of BIND. The BIND company occasionally mumbles about imaginary tools to handle new zones and client differentiation. By combining all these tools, you can finally approach the functionality of a trivial rsync script. Wow.
Here's a table summarizing the situation as of November 2002:
|Zone transfers||rsync over ssh|
|Automatic handling of new zones||No||Yes|
|... and client differentiation||No||Yes|
|... and scheduled record changes||No||Yes|
|... which means now||No; note 1||Yes|
|Success reported locally||No||Yes|
|Errors reported locally||No||Yes|
|... of data added by hand||No; note 2||Yes|
|... or by common web tools||No||Yes|
|Usable for other services||No||Yes|
|Supported by the BIND company||Yes||No|