D. J. Bernstein
Internet publication
djbdns

How to answer TCP queries

Here is how to configure your DNS server to answer TCP queries. Note that most DNS servers do not need 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
Here 131.193.178.160 is the IP address, and heaven.af.mil is the zone to be transferred. You can list several zones separated by slashes:
     echo '131.193.178.160:allow,AXFR="heaven.af.mil/panic.mil"' >> /etc/axfrdns/tcp
If you want to allow transfers of all zones, omit the ,AXFR="...":
     echo '131.193.178.160:allow' >> /etc/axfrdns/tcp

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

     cd /etc/axfrdns
     make
You 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

When are TCP queries sent?

If you're in one of the following situations, you need to configure your DNS server to answer TCP queries:

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?

When you edit the host information on one of your DNS servers (the ``master'' or ``primary''), you have to copy it to the other DNS servers (the ``slaves'' or ``secondaries'').

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 transfersrsync over ssh
Automatic handling of new zonesNoYes
... and client differentiationNoYes
... and scheduled record changesNoYes
Replication soonYesYes
... which means nowNo; note 1Yes
Success reported locallyNoYes
Errors reported locallyNoYes
Compressed transfersNoYes
Incremental transfersYesYes
... of data added by handNo; note 2Yes
... or by common web toolsNoYes
Encrypted transfersNoYes
Authenticated transfersYesYes
Usable for other servicesNoYes
Supported by the BIND companyYesNo
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.