DNS Vuln.

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

By Scott Hogg on Sun, 08/22/10 - 7:44pm.

• 1 Comment
• Print

. What's this?

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.

So as the world transitions to DNSSEC, your organization may not necessarily be using it yourself for your own authoritative DNS servers. However, your name servers may be requesting DNSSEC information even though it is not configured to serve up DNSSEC records. You may encounter problems if your resolvers are starting to encounter DNSSEC information and only able to receive UDP packets of 512 bytes or smaller. If your firewall is blocking TCP port 53 DNS messages or UDP port 53 messages using EDNS0, then you may encounter problems even if you haven't deployed DNSSEC yourself.

IPv6 DNS Lookups May be Larger Than 512 Bytes
We all know that IPv6 addresses are four times larger than IPv4 addresses. A standard A-record query response easily fits within the 512 byte UDP limit and so does a standard AAAA-record query response. A standard AAAA-record query response is about 100 bytes. However, it is conceivable that with CNAMEs, glue records, and other data that may accompany a DNS response that it could exceed the UDP 512 byte limit. Therefore, allowing TCP port 53 or enabling EDNS0 is also a requirement for IPv6 communications. This is also the case if you are doing DNS queries for IPv6 names and addresses using the IPv4 protocol to communicate with the DNS servers.

One advantage of using IPv6 is that the vast majority of systems will use aggregatable global unicast addresses. Therefore, there will not be any needs for NAT. DNSSEC has not been compatible with NAT so IPv6 offers an opportunity to use DNSSEC as it was intended to be used. One of the transition mechanisms originally developed was Network Address Translation - Protocol Translation (NAT-PT) (RFC 2766). This technique offered a rudimentary method to translate IPv4 and IPv6 packets between IPv4-only hosts and IPv6-only hosts. However, there were many reasons why NAT-PT was deprecated (RFC 4966) in the summer of 2007. One of those reasons to deprecate NAT-PT was the fact that it broke the usage of DNSSEC.

Firewalls
If a UDP port 53 response is larger than 512 bytes then it may be truncated or then DNS falls back to using TCP. However, if TCP is blocked on the firewall then the lookup can fail altogether. Your firewall may also be preventing you from using EDNS0. Therefore, you should configure your firewall to allow both TCP and UDP port 53 to and from your DNS servers as well as allow your firewall to pass larger EDNS0 packets. To accomplish this change you will have to modify your firewall's configuration parameters to enable EDNS0.

Cisco publishes a nice guide on DNS best practices that includes how to secure your DNS server configurations as well as allow for DNSSEC communications.

If you have a Cisco PIX firewall (6.3 and earlier) you may need to add this command to your configuration.
fixup protocol dns maximum-length 4096
This command will increase the firewall's DNS message length limit and allow EDNS0 messages to be forwarded.

If you have a newer software version running on your PIX or ASA then the traffic policy commands will look like this.
policy-map type inspect dns preset_dns_map
parameters
dns-guard
id-randomization
message-length maximum 4096
id-mismatch count 10 duration 2 action log
exit
match header-flag RD
drop
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
service-policy global_policy global

In order to increase the response length you need to enter these commands:
policy-map global_policy
class inspection_default
inspect dns maximum-length 4096

To view the settings use the following command:
show service-policy inspect dns

Juniper ScreenOS also allows for the increase in DNS message size using the following command.
set di service dns udp_message_limit 512 - 4096

If your firewall doesn't have a visible setting to enable EDNS0 then you may want to check with the firewall manufacturer to see if it can even support this setting. If you are concerned about how your home router/firewall may fare with the introduction of DNSSEC you can check out the test results from Nominet and Core Competence.

Testing
Once you have permitted TCP and UDP port 53 and believe that your systems are EDNS0-capable, then you must test that it is working as expected. There are several methods that you can use to test your configuration and validate if your systems are capable of handling larger DNS packets.
Domain Name System Operations Analysis and Research Center (OARC) provides tools for testing your reply size limits.

They offer a Validating Resolver.
You can use the dig utility to test your configuration.
dig +nodnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
dig +dnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
dig +dnssec +norec +vc any . @L.ROOT-SERVERS.NET

You can also use dig to test against the OARC DNS servers.
dig @208.67.222.222 +short rs.dns-oarc.net txt
dig @158.43.128.1 +short rs.dns-oarc.net txt

RIPE NCC also provides a method for testing your DNS query reply size. RIPE also offers a Java reply size test utility that you may find useful.

When you are testing DNS it is often helpful to have a protocol analyzer running so that you can inspect the queries and the responses. If you are using Wireshark then you can set a display filter for your captured traffic to only look at the DNS packets. This filter will look something like this.
tcp.port == 53 || udp.port == 53

You also need to check that DNS servers on the Internet can receive larger TCP DNS responses from your servers. Eventually, your DNS servers will use DNSSEC and you want those DNS resolvers in other organizations to be able to get all your DNSSEC information. Therefore, you must test your UDP and TCP port 53 traffic in both directions.

Other Issues
If you have permitted both TCP and UDP port 53 to traverse to and from your DNS servers and are still not having any luck, you may have an issue with your DNS implementation. It is conceivable that your DNS vendor has incorrectly interpreted the IETF RFCs and don't support TCP communications for DNS. There is an IETF draft called "DNS Transport over TCP - Implementation Requirements" which clarifies that "DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP". If this is the case then you should educate your vendor and then possibly consider switching to a new version of BIND, djdbns, or Secure64.

I wish you good luck deploying DNSSEC and IPv6 while using DNS over UDP and TCP port 53 with EDNS0.

Scott