How to answer TCP queries

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 1.8.7.200

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 '131.193.178.160:allow,AXFR="heaven.af.mil"' >> /etc/axfrdns/tcp

     echo '131.193.178.160:allow,AXFR="heaven.af.mil/panic.mil"' >> /etc/axfrdns/tcp

     echo '131.193.178.160:allow' >> /etc/axfrdns/tcp

5. As root, compile /etc/axfrdns/tcp into a hashed database:

     cd /etc/axfrdns
     make

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

When are TCP queries sent?

• You want to publish record sets larger than 512 bytes. (This is almost always a mistake.)
• You want to allow outgoing zone transfers, for example to a third-party server.
• A parent server refuses to delegate a name to you until you set up TCP service.

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.)

What are zone transfers?

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
Replication soon	Yes	Yes
... which means now	No; note 1	Yes
Success reported locally	No	Yes
Errors reported locally	No	Yes
Compressed transfers	No	Yes
Incremental transfers	Yes	Yes
... of data added by hand	No; note 2	Yes
... or by common web tools	No	Yes
Encrypted transfers	No	Yes
Authenticated transfers	Yes	Yes
Usable for other services	No	Yes
Supported by the BIND company	Yes	No

Note 1: NOTIFY is delayed. This isn't just a BIND problem; see RFC 1996, section 4.3. Note 2: The BIND 9 manual says that ``manually maintained'' zone files are not IXFR-capable. In theory, IXFR can transmit changes in manually maintained zone files; in reality, nobody has written software to figure out the changes.