No, they aren't. TCP DNS is 10-20ms slower than UDP DNS against large DNS servers, and probably much worse against slower DNS servers.
I don't know what Dan did to generate this result, but whatever it was, it appears to have been wrong.
(Heading off a silly argument: the test I just did to confirm this did not make new connections for each query; the 3WH was amortized over all the requests).
* Dan wrote this DNS proxy thing for DNSSEC (which, don't use DNSSEC, it's evil) called "phreebird".
* Phreebird uses libevent, which tends to produce zippy fast servers, so Dan benchmarked it and found TCP was faster than UDP.
* But Dan made a bunch of mistakes with libevent and, in fairness, BSD sockets in general; in particular, he only events the read side of the conversation --- his writes block. Since the socket buffers on the TCP side are spread out across a bunch of sockets, and there's only one UDP socket buffer, the UDP socket blocks a lot.
Dan says that when he says TCP is "faster", he means "it gets better throughput, even though it may not get better latency". Now, I think "latency vs. throughput" is a refuge for scoundrel arguments, but just to make sure, I checked, and if you wail on Google DNS with a TCP connection, you cannot in fact clear 1000 queries faster than if you firehose it with UDP. This just makes sense, since TCP has congestion control overhead and strict in-order delivery and UDP doesn't.
I don't know what Dan did to generate this result, but whatever it was, it appears to have been wrong.
(Heading off a silly argument: the test I just did to confirm this did not make new connections for each query; the 3WH was amortized over all the requests).