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?

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