【My Study Note】DNS and UDP
DNS and UDP
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 is no setup or teardown 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 caching name servers, but it’s also true that if the full resolution needs to be processed, we’re talking about a lot more traffic.
Full DNS lookup to take place via TCP
First, the host that’s making the DNS resolution request would send an 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 an 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.
Let’s use “food.com” as an example. 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 caching 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 of the request, the response, and then the ACK of the response.
Finally, the connection would have to be closed via a four-way handshake (FIN, ACK, Fin, ACK). That’s 11 more packets which are 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 authoritative 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.
A response 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 adds up fast as you can see. Remember that DNS traffic is just a precursor to actual traffic. A computer almost always performs a DNS lookup because it needs to know the IP of the domain name in order to send additional data, not just because it’s curious.
Full DNS lookup to take place via UDP
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 authoritative server. We’re now at five packets.
Next, the recursive name server sends its final request to the authoritative 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.
This is way fewer 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 of why protocols like UDP exist in addition to the more robust TCP.
How error recovery plays?
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.