Is DNS TCP or UDP port 53?
The answer is DNS is mostly UDP Port 53, but as time progresses, DNS will rely on TCP Port 53 more heavily. DNS has always been designed to use both UDP and TCP port 53 from the start1 , with UDP being the default, and fall back to using TCP when it is unable to communicate on UDP, typically when the packet size is too large to push through in a single UDP packet.
When Does DNS Switch to TCP?
The next natural question is: when will DNS messages exceed 512 bytes? Actually, this happens quite often in today’s environment. When DNS was first implemented, the only thing that would be so large that it exceeded the 512-byte limit was a zone transfer, in which one DNS server sends every single resource record in the zone to another machine, usually another DNS server.
In modern DNS systems though, we are increasingly seeing resource record sets (or RRsets) that have a larger combined size. For example, Figure FAQ-5 illustrates querying for www.example.com may yield results such as this (AAAA are IPv6 records):
Or the same query might return the following TXT records, each providing a specific function such as spam detection or site verification as demonstrated in Figure FAQ-6:
If a zone is signed by DNSSEC, it will routinely return large responses due to the cryptographic keys and signatures as shown in Figure FAQ-7:
As more and more people adopt newer features such as IPv6, spam avoidance, and DNSSEC, DNS is more likely to switch to TCP due to the larger response size.
What Happens If TCP Is Blocked?
Whatever the case, when the message size exceeds 512 bytes, it will trigger the ‘TC’ bit (Truncation) in DNS to be set, informing the client that the message length has exceeded the allowed size. In these situations, the client needs to re-transmit over TCP for which the size limit is 64000 bytes. If DNS servers and network environment cannot support large UDP packets, it will cause retransmission over TCP; if TCP is blocked, the large UDP response will either result in IP fragmentation or be dropped completely. The end symptom to the end client is usually slow DNS resolution, or inability to resolve certain domain names at all.
Size Matters: EDNS
You might be wondering where the size limit of 512 bytes come from. The 512-byte UDP payload size is a dependency on IPv4. The IPv4 standard2 specifies that every host must be able to reassemble packets of 576 bytes or less, take away header and other options, that leaves 512 bytes for payload data. This is the reason why there are precisely 13 DNS root servers3 originally: 13 domain names and 13 IPv4 addresses fit nicely into a single UDP packet.
This size limitation was recognized long ago as a problem. In 1999, Extension Mechanism for DNS (EDNS) was proposed, and it has been updated over the years, increasing the size all the way to 4096 bytes, or 4 kilobytes. So, if you are running a reasonably up to date DNS server, the chances of it switching to TCP should be slim(mer).
However, even though EDNS has been around a long time, its support has not been as universal as it should be4 . Some network equipment, such as firewalls, might still make assumptions about DNS packet size. A firewall may drop or reject a large DNS packet, thinking it is an attack. This behavior may not have caused visible problems in the past (or it did but no one understood why), but as DNS data continues to increase in size, it is important that all network equipment is configured correctly to support large DNS packet sizes. If the network environment does not fully support large DNS messages, it may lead to the DNS message being rejected by network gear, or partially dropped during fragmentation. What this looks like to the end user is that DNS queries are going unanswered, or take a very long time, giving the impression that “DNS/network is really slow.”
While EDNS is necessary for the operation of modern-day DNS, the ability to send larger messages contributed to volumetric attacks such as Amplification and Reflection.
1 RFC 1034, written in 1987, specified the use of TCP for DNS as a requirement.
2 RFC 791, which was published in 1981
3 While there are still only 13 IPv4 addresses for DNS root today, it is actually distributed across many nodes across the world using techniques such as anycast and load balancing.
4 Recognizing this problem, the DNS community held a “DNS Flag Day” event on February 1st, 2019, declaring it the day that EDNS must be fully support going forward.
