Allow Both TCP and UDP Port 53 to Your DNS Servers

DNS queries are getting bigger so we do not want to accidentally block them

Become An Insider

Sign up now and get FREE access to hundreds of Insider articles, guides, reviews, interviews, blogs, and other premium content. Learn more.

Security practitioners for decades have advised people to limit DNS queries against their DNS servers to only use UDP port 53. The reality is that DNS queries can also use TCP port 53 if UDP port 53 is not accepted. Now with the impending deployment of DNSSEC and the eventual addition of IPv6 we will need to allow our firewalls for forward both TCP and UDP port 53 packets.

DNS can be used by attackers as one of their reconnaissance techniques. Public information contained a target's servers is valuable to an attacker and helps them focus their attacks. Attackers can use a variety of techniques to retrieve DNS information through queries. However, hackers often try to perform a zone transfer from your authoritative DNS servers to gain access to even more information. You can use the dig command to gather information from a server for a specific zone file.

dig @192.168.11.24 example.org -t AXFR

Zone transfers take place over TCP port 53 and in order to prevent our DNS servers from divulging critical information to attackers, TCP port 53 is typically blocked. If the organization's firewall protecting the authoritative DNS server allowed the TCP port 53 packets and the DNS server was configured to allow zone transfers to anyone, then this dig command would be successful. However, most organizations have configured their DNS servers to prevent zone transfers from unintended DNS servers. This can be configured in the BIND zone file using any one of these forms of the allow-transfer command as shown below.

allow-transfer {"none";}; allow-transfer { address_match_list }; allow-transfer {192.168.11.11;};

Furthermore, most organizations have also used firewalls to block TCP port 53 to and from their DNS servers and the Internet. This is double-protection in case the DNS server accidentally allowed transfers.

Configuring your DNS servers to permit zone transfers to only legitimate DNS servers has always been and continues to be a best practice. However, the practice of denying TCP port 53 to and from DNS servers is starting to cause some problems. There are two good reasons that we would want to allow both TCP and UDP port 53 connections to our DNS servers. One is DNSSEC and the second is IPv6.

DNSSEC Creates Larger DNS Responses

I love reading The IP Journal and have read it since the first issue in 1998.

In the recent edition of the IP Journal there was an article by a friend of mine, Stephan Lagerholm, of Secure64 and the Texas IPv6 Task Force, titled "Operational Challenges When Implementing DNSSEC". This article covered many of the caveats that organizations run into as they move to deploy DNSSEC.

One of the key issues mentioned is that DNSSEC can cause DNS replies to be larger than 512 bytes. DNSSEC (Defined in RFC 4033, RFC 4034, and RFC 4035) requires the ability to transmit larger DNS messages because of the extra key information contained in the query responses. TCP port 53 can be used in the cases where the DNS responses greater than 512 bytes. However, using UDP messages are preferable to using TCP for large DNS messages is due to the fact that TCP connections can consume computing resources for each connection. DNS servers get numerous connections per second and using TCP can add too much overhead. To address this issue, the IETF RFC 2671 "Extension Mechanisms for DNS (EDNS0)" defines a method to extend the UDP buffer size to 4096 bytes to allow for DNSSEC and larger query responses. To enable EDNS0 on your BIND 9 configuration you can use the following BIND operations statement

edns-udp-size 4096 ;

Awareness of DNSSEC has increased due to the vulnerabilities disclosed 2 years ago and with recent news about the U.S government striving to implement it. Many organizations have been planning their DNSSEC deployments. DNSSEC is becoming more widely deployed now that key Top Level Domains (TLDs) are being signed. The TLD .org has now been signed. The Internet's root zone was signed just 2 months ago in a ceremony in Virginia. VeriSign has stated their desire to support DNSSEC for .com and .net by 2011. Comcast has created a DNSSEC Information Center site that can help you keep up to date on the latest DNSSEC status.

To continue reading this article register now

Now read: Getting grounded in IoT