Optimize DNS Performance with TCPWave

Elevate user experience with TCP Port 53

TCPWAVE

Embrace the shift to TCP Port 53 for enhanced network stability.

The Domain Name System (DNS) predominantly uses UDP Port 53, but the progression of time and technology necessitates a heavier reliance on TCP Port 53. From its inception, DNS has been designed to utilize both UDP and TCP port 53. UDP serves as the default protocol, with TCP being utilized when communication via UDP is impracticable, usually due to packet size constraints.

Increased DNS Performance

Increased DNS Performance

  • Understanding the shift from UDP Port 53 to TCP Port 53 allows organizations to optimize their DNS infrastructure to handle larger resource record sets and DNSSEC-signed zones.
Improved Network Reliability

Improved Network Reliability

  • Configuring network equipment to support large DNS packet sizes and embracing the switch to TCP Port 53 ensures a reliable DNS infrastructure.
Mitigation of Fragmentation Challenges

Mitigation of Fragmentation Challenges

  • Blocking TCP can result in IP-level fragmentation or dropped UDP responses, and adapting to TCP Port 53 helps prevent fragmentation challenges, ensuring smooth DNS operations.
Enhanced Security

Enhanced Security

  • Adapting to the use of TCP Port 53 in DNS, along with the adoption of EDNS, enhances security measures. It ensures that larger DNS messages can be transmitted securely.
The Switch to TCP in DNS

In today's digital landscape, it's not uncommon for DNS messages to surpass 512 bytes, necessitating a switch to TCP. When does this transition occur? Initially, the only instances exceeding the 512-byte limit were zone transfers, where one DNS server transmits all resource records in a zone to another machine, often another DNS server. However, contemporary DNS systems are frequently dealing with larger resource record sets (RRsets). As a case in point, querying for www.example.com might produce results such as AAAA (IPv6 records) or TXT records for spam detection or site verification. DNSSEC-signed zones regularly return large responses due to cryptographic keys and signatures. With the widespread adoption of features such as IPv6, spam prevention, and DNSSEC, it's becoming increasingly common for DNS to switch to TCP, given the larger response sizes.

The Switch to TCP in DNS
Consequences of Blocking TCP
Consequences of Blocking TCP

If a DNS message size exceeds 512 bytes, it sets the 'TC' bit (Truncation) in DNS, informing the client that the message length has surpassed the permitted size. Subsequently, the client must re-transmit over TCP, where the size limit extends to 64000 bytes. If the network environment and DNS servers are unable to support large UDP packets, it results in retransmission over TCP. If TCP is blocked, the large UDP response may either fragment at the IP level or be dropped altogether. The user typically experiences slow DNS resolution or inability to resolve certain domain names.

EDNS: Addressing the Size Limitation

The 512-byte UDP payload size is an inherent requirement of IPv4. In 1999, to address this size limitation, the Extension Mechanism for DNS (EDNS) was proposed. EDNS has undergone various updates, increasing the size to 4096 bytes or 4 kilobytes. Therefore, with an up-to-date DNS server, the switch to TCP should be less frequent. However, the adoption of EDNS is not as universal as it should be. Some network equipment such as firewalls might have assumptions about DNS packet sizes, causing them to drop or reject larger DNS packets. This can lead to the DNS messages being rejected or partially dropped during fragmentation, manifesting as unanswered DNS queries or slower response times to the end-user. Furthermore, the ability to send larger messages via EDNS has also contributed to volumetric attacks like Amplification and Reflection.

EDNS: Addressing the Size Limitation
Conclusion

In conclusion, the shift towards TCP Port 53 in DNS is an ongoing process shaped by the evolution of digital systems. It's imperative that network equipment be correctly configured to support large DNS packet sizes. The DNS community, recognizing the challenges posed by the non-universal adoption of EDNS, held a "DNS Flag Day" on February 1st, 2019, declaring it the day that EDNS must be fully supported moving forward. Ensuring compatibility with these changes is vital for the reliable operation of DNS, as well as for optimal user experience and network performance.

References
  • RFC 1034 (1987) - Specifies the use of TCP for DNS as a requirement.
  • RFC 791 (1981) - Specifies the IPv4 standard.
  • DNS Root Servers - 13 IPv4 addresses distributed across various nodes worldwide using techniques like anycast and load balancing.
  • RFC 6891 (1991) - Specifies an extension to the DNS protocol.