Tor can only handle TCP connections, but DNS is a UDP protocol. How does Tor route DNS requests over its TCP based network? Why can the same approach not be used to route all UDP traffic over Tor?
Short answer: Tor transports the hostname (inside the Tor protocol) to the exit relay, which resolves it for you.
Tor clients do not, in general, directly do DNS requests. When you open a connection through the tor network you usually ask your client (on its socks ports) to connect you to a hostname and port, say www.example.com:80.
Your tor client, once it has created a circuit, will send that hostname and port to the exit node in its RELAY_BEGIN cell.
The exit node will then do a DNS resolve and open a TCP connection to the target. Once that's established it will tell your client that the connection is open, and for informational purposes will also tell your client what address that hostname resolved to.
Tor, in addition to that, has some sort of "remote DNS resolve" protocol built in. This support allows clients to query for certain resource types, like IPv4 or IPv6 addresses. Here too, the exit node does the actual DNS packet sending and receiving and just relays the answer to the client.
No UDP packets are actually ever routed from the client.
There's also a proposal to add more full featured DNS support to Tor. So far it hasn't been implemented.
Tor Protocol Specification references
You have to remember, that Tor is a PROXY. Proxies act on behalf of another, and therefore, theoretically you would only need to "resolve" the address of the first node of the circuit. But you don't have to do that, because Tor already has that information in its configuration files.
What happens is that the exit node "handles" everything, including DNS, for the nodes behind it, because of the nature of being a proxy server. It then transmits the DNS information backwards through a Tor circuit. Given that Tor circuits for a specific machine change every few minutes, this is what makes it difficult and next to impossible for anyone to track a machine through the nodes, because ALL of the traffic though Tor is encrypted, with the exception of the exit node's handling of the original request which it will then encrypt on its way backwards through the Tor. This is because it takes, even in a simple hypothetical case, at least several attempts and a good few minutes to decrypt anything without having direct knowledge of BOTH keys required for decyrption, and this depends largely on the encryption method.
The exception to this is the .onion domain, i.e. the hidden services. Wherein Tor itself handles the DNS issue in a manner that, while is in fact DNS request in CONCEPT, tor does not follow the conventional "Rules" for DNS when it comes to hidden services. Because of the rendezvous server, which is a random Tor server, in a way "fakes" being the real host of the .onion site, for the purposes of concealing the IP of the machine the .onion server is running on.
TOR is not capable of routing UDP traffic as far as I know. But for DNS it makes an exception. This can be done because of the way SOCKS5 works.
When establishing a SOCKS5 connection the client sends either the IP address or a DNS. When TOR receives the DNS it uses the backend to resolve it (I don't really know exactly how it does it but I guess it's really similar to TCP and an endpoint resolves it for you) and then it can continue using the regular TCP/IP tor connection.
This way TOR is able to provide hidden services as .onion DNS, as it is receiving DNS connections over SOCKS5. This is the reason why you leak DNS (and it is not possible to use .onion DNS) over SOCKS4 (it does not support DNS resolution).