Traditional DNS responses are typically small in size (less than 512 bytes) and fit nicely into a small UDP packet. Extension mechanism for DNS (EDNS, or EDNS(0)) gives us a mechanism to send DNS data in larger packets over UDP. In order to support EDNS, both the DNS server and the network need to be properly prepared to support the larger packet size and multiple fragments.

This is important for DNSSEC, since the +do bit that signals DNSSEC-awareness is carried within EDNS, and DNSSEC responses are larger than traditional DNS. If DNS servers and network environment cannot support large UDP packets, it will cause retransmission over TCP, or the larger UDP responses will be discarded. Users will likely experience slow DNS resolution or unable to resolve certain names at all.

Note that EDNS applies whether or not you are validating DNSSEC because BIND has DNSSEC enabled by default.

Please see the section called “Network Requirements” for more information on what DNSSEC expects from the network environment.

BIND has been shipped with EDNS enabled by default for over a decade, and the UDP packet size is set to a maximum of 4096 bytes. So as the DNS administrator, there should not be any re-configuration needed. You can use dig to verify that your server supports EDNS and the UDP packet size it is allowing as follows:

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline

; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63266
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.isc.org.		IN A

;; ANSWER SECTION:
www.isc.org.		23 IN A	149.20.64.69
www.isc.org.		23 IN RRSIG A 5 3 60 (
				20141029233238 20140929233238 4521 isc.org.
				DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
				5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
				E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
				jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

;; Query time: 7 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 03 16:31:33 CST 2014
;; MSG SIZE  rcvd: 223

There is a helpful testing tool available (provided by DNS-OARC) that you can use to verify resolver behavior regarding EDNS support: https://www.dns-oarc.net/oarc/services/replysizetest/

So you made sure your name servers have EDNS enabled. That should be the end of the story, right? Unfortunately, EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is negotiated between each pair of hosts in a DNS resolution process, which in turn means if one of your upstream name servers (for instance, your ISP's recursive name server that you forward to) does not support EDNS, you may experience DNS lookup failures or be unable to perform DNSSEC validation.

Okay, so both your recursive name server and your ISP's name servers support EDNS, we are all good here, right? Not so fast. As these large packets have to traverse through the network, the network infrastructure itself must allow them to pass.

When data is physically transmitted over a network, it has to be broken down into chunks. The size of the data chunk is known as Maximum Transmission Units (MTU), and it can be different from network to network. IP fragmentation occurs when a large data packet needs to be broken down into smaller chunks so that each chunk is smaller than the MTU, and these smaller chunks need to be reassembled back into the large data packet. IP fragmentation is not necessarily a bad thing, it most likely occurs on your network today.

Some network equipment, such as firewalls, may make assumptions about DNS traffic. One of these assumptions may be how large each DNS packet is. When a firewall sees a larger DNS packet than it expects, it either rejects the large packet or drops its fragments because the firewall thinks it's an attack. This configuration probably didn't cause problems in the past since traditional DNS packets are usually pretty small in size. However, with DNSSEC, these configurations need to be updated, since DNSSEC traffic regularly exceeds 1500 bytes (a common MTU value). If the configuration is not updated to support larger DNS packet size, it will often result in the larger packets being rejected, and to the end user it looks like the queries go un-answered. Or in the case of fragmentation, only a part of the answer made it to the validating resolver, and your validating resolver may need to re-ask the question again and again, creating the appearance "DNS/network is really slow" for the end users.

And while you're updating configuration on your network equipment, make sure TCP port 53 is also allowed for DNS traffic.

Yes. DNS uses TCP port 53 as a fallback mechanism, when it cannot use UDP to transmit data. This has always been the case even long before DNSSEC arrived at the scene. Traditional DNS relies on TCP 53 for operations such as zone transfer. The use of DNSSEC, or DNS with IPv6 records such as AAAA, increases the chance that DNS data will be transmitted on TCP.

Due to the increased packet size, DNSSEC may fall back to TCP more often then traditional (insecure) DNS. If your network is blocking or filtering TCP port 53 today, you may already experience instability with DNS resolution before deploying DNSSEC.