DNSSEC & Middleboxes

General Information

It has been officially announced that on July 15th, the global root DNS name servers will start serving their zones in a secure manner (providing DNSSEC signed material). This will result in larger DNS packet sizes, due to the security-related additional payload that will be carried within the protocol packets. This is orthogonal to the deployment of DNSSEC within LSU.
 

Technical Protocol Details

The effects of the inflated DNS responses on the protocol itself will be the following:

• DNS responses that do not fit in the usual 512 bytes packet will be attached to the same packet via an DNS protocol extension mechanism called EDNS0. This enables DNS packets to contain "answer" sections larger than the traditional 512B-bounded design.
   
• Communication between name servers where at least one of them does not support the EDNS0 extension, will result a truncated response which will trigger a TCP fallback channel. The rest of the communication will continue as required over TCP port 53 until the query that triggered the inflated response is answered.
   
• Similar cases may cause the creation of UDP fragments that will carry portions of the larger, inflated DNS response over a sequence of packets with a maximum of 512B data gram in-flight.
   

What Do I Need To Ensure?

• Your device permits DNS communication on port 53 over *BOTH* TCP and UDP transports. It is a common feature of several appliances to discard DNS packets over TCP, although this is clearly a bad practice and will possibly result in breaking DNS resolution.
   
• Your device does *NOT* limit DNS packets (either over TCP/UDP or port 53) to a maximum of 512 bytes. Again, this is an outdated practice, as the protocol has been extended long ago to accommodate larger packets.
   
• Your device does *NOT* block DNS packets with "unknown" DNS packet header options. Some of these fields have been used for the various protocol extensions. Several security appliances are known to break the standards by doing protocol inspection/fix up and dropping packets that carry "unknown" options.
   
• Your device does *NOT* drop UDP fragments for DNS traffic on transport/port UDP/53.
   

Am I Affected?

You should ideally have a good idea of any Middlebox device configuration that you are operating. Note that some devices apply default settings/configuration that might be implicitly enabled. You should always refer to your vendor's manual and review any section that mentions if/how the device affects the DNS protocol.

Some starting pointers for Cisco and Juniper devices can be found on the following sites:

• http://www.cisco.com/web/about/security/intelligence/dns-bcp.html#5
   
• https://supportforums.cisco.com/discussion/10880076/cisco-pix-asa-and-dnssec-problem-approaching-may-5th
   
• https://community.juniper.net/home
   

Vendor Information

Most device vendors are well aware of the potential issues that might be presented with DNSSEC deployment. It should be straightforward to work out any issues that you might have with your devices' vendor.

You can test the various path and protocol characteristics that are required via numerous methods:

• http://labs.ripe.net/content/ testing-your-resolver-dns- reply-size-issues
   
• http://labs.ripe.net/content/ preparing-k-root-signed-root- zone#diy

Note: Bear in mind that these tests are only meaningful if tested between your network/subnet and the "outside world". i.e. having any intervening Middlebox in-path.

Referenced from: labs.ripe.net