DNS is a great example of an application layer service that uses UDP for the transport layer instead of TCP, this can be broken down into a few simple reasons. Remember that the biggest difference between TCP and UDP is that UDP is connectionless this means there's no set up or tear down of a connection. So much less traffic needs to be transmitted overall. A single DNS request and its response can usually fit inside of a single UDP datagram, making it an ideal candidate for a connectionless protocol, it's also worth calling out that DNS can generate a lot of traffic. It's true that caches of DNS entries are stored both on local machines and cashing name servers, but it's also true that if the full resolution needs to be processed, we're talking about a lot more traffic. Let's see what it would look like for a full DNS look up to take place via TCP. First, the host that's making the DNS resolution request would send a SYN packet to the local name server on port 53 which is the port that DNS listens on. This name server would then need to respond with a SYN- ACK packet. That means the original host would have to respond with an ACK in order to complete the three way handshake, that's three packets. Now that the connection has been established, the original host would have to send the actual request. I'd like the IP address for food.com please, when it receives this request, the name server would have to respond with another ACK. I got your request for food.com, we're up to five packets sent now. In our scenario, the first cashing name server doesn't have anything cached for food.com. So it needs to talk to a root name server, to find out who's responsible for the .com TLD. This would require a three way handshake, the actual request, the ACK or the request, the response and then the ACK of the response. Oof, finally, the connection would have to be closed via a four way handshake. That's 11 more packets or 16 total. Now that the recursive name server has the correct TLD name server, it needs to repeat that entire process to discover the proper authority of name server. That's 11 more packets bringing us up to 27 so far. Finally, the recursive name server would have to repeat the entire process one more time while talking to the authoritative name server in order to actually get the IP of food.com. This is 11 more packets for a running total of 38. Now that the local name server finally has the IP address of food.com, it can finally respond to the initial request. It responds to the DNS resolver that originally made the request and then this computer sends an ACK back to confirm that it received the response. That's two more packets, putting us at 40. Finally, the TCP connection needs to be closed via a four way handshake. This brings us to a grand total of 44 packets at the minimum in order for a fully recursive DNS request to be fulfilled via TCP. 44 packets isn't really a huge number in terms of how fast modern networks operate, but it heads up fast as you can see, remember that DNS traffic is just a precursor to actual traffic. A computer almost always performs a DNS look up because it needs to know the IP of a domain name in order to send it additional data, not just because it's curious. Now, let's check out how this would look with UDP, spoiler alert, it doesn't take as many packets. The original computer sends a UDP packet to its local name server on port 53 asking for the IP for food.com, that's one packet. The local name server acts as a recursive server and sends up a UDP packet to the root server which sends a response containing the proper TLD name server, that's three packets. The recursive name server sends a packet to the TLD server and receives back a response containing the correct authority server, we're now at five packets. Next, the recursive name server sends its final request to the authority of name server which sends a response containing the IP for food.com, that's seven packets. Finally, the local name server responds to the DNS resolver that made the request in the first place with the IP for food.com. That brings us to a grand total of eight packets. See way less packets, you can see now how much overhead TCP really requires and for something as simple as DNS, it's just not needed. It's the perfect example for why protocols like UDP exist in addition to the more robust TCP, you might be wondering how error recovery plays into this since UDP doesn't have any. The answer is pretty simple. The DNS resolver just asks again if it doesn't get a response, basically the same functionality that TCP provides at the transport layer is provided by DNS at the application layer, in the most simple manner. A DNS server never needs to care about doing anything but responding to incoming lookups and a DNS resolver simply needs to perform lookups and repeat them if they don't succeed. A real showcase of the simplicity of both DNS and UDP, I should call out that DNS over TCP does in fact exist and is also in use all over. As the web has gotten more complex, it's no longer the case that all DNS lookup responses can fit in a single UDP datagram. In these situations, a DNS name server would respond with a packet explaining that the response is too large. The DNS client would then establish a TCP connection in order to perform the lookup.
