DNSSEC is coming!

The public sigining key does exist in the DNS zone that is being signed, and it is in turn signed by a second key, which is known as a trust-anchor or key-signing-key (KSK). The KSK or a digest thereof is placed in the parent zone and signed by the parent; the KSK itself can also be distributed out-of-band, such as via a secure website. For example, the digest of isc.org's KSK is placed in the .org DNS zone and signed by the .org nameserver. In this way, a chain of trust is maintained.

In order for the chain of trust to remain unbroken, every zone in the hierarchy must be signed and the appropriate key digests must be in their respective places. In order for net.berkeley.edu to be secure and trusted, berkeley.edu must be signed and a KSK digest (called a DS record) is placed in berkeley.edu. edu must also be signed and must have a DS record for berkeley.edu. Finally, the root zone (".") must be signed and have a DS record for edu. Much of the DNSSEC adoption effort throughout the Internet has been on hold pending a schedule for the signing of the root zone.

berkeley.edu and EDU

IST staff have been working with staff at EDUCAUSE, the organization that maintains the records for the .edu domain, and Verisign, who runs the DNS service for EDU, to participate in a testbed for the signing of the EDU zone. Simultaneously, this has allowed IST staff to create and maintain a testbed for a signed berkeley.edu zone. All subdomains of berkeley.edu that are maintained by IST (except for dynamic DNS zones at this time) are also signed in the testbed. The EDU testbed has recently concluded and the EDU zone was signed in August 2010.

IST staff began signing berkeley.edu in limited production beginning during the mandatory furlough period of the 2009-2010 holiday season. This had very little operational impact because we have not been attempting to validate the signed zones. To minimize issues, the signed version of berkeley.edu were rolled out gradually.

A similar schedule was applied to the root zone. In January 2010, a non-validatable signed version of the root zone was placed on one of the 13 root nameserver instances, with the unvalidatable signed data appearing on all of the root instances in May 2010. As is the case with the signed version of berkeley.edu, when a nameserver requests DNSSEC records, the root server will add signatures to the response. To compare, here is the response from a nameserver without the DNSSEC records:

sonic.net.berkeley.edu. 10801   IN      A       128.32.155.9

sonic.net.berkeley.edu. 10801   IN      A       128.32.155.9
sonic.net.berkeley.edu. 10801   IN      RRSIG   A 5 4 10801 20091221121838 20091215121838 19760
                   net.berkeley.edu. VarS4+QL+XVcP0LDXslOaPSWZCi6JutrzEM1JJ0H0hk5rTxmT1rtLskT 
                                     1JOTxd64VeQtChSUxgTEB5hBKs16PSvTGiWYoFrSBN9tQ4DFTMQYaMNI 
                                     NNUDM51ny5KtOvdjW78Ogv9lRfe8Pg+ESpwYgtFUjzG80fKiZsf4qYpO 
                                     u1c=

[lines wrapped to improve readability]

Throughout the first half of 2010, additional root nameserver instances were begin to give out signed data. On July 15, 2010, all root servers began giving out signed data and it then became possible to validate the signed root and establish a chain of trust from the root downward.

It may come as a surprise to know that many nameservers ask for DNSSEC records even if they are not configured to do DNSSEC validation. Two of the major open-source DNS server implementations, BIND and unbound, both request DNSSEC records by default by setting the "DNSSEC Okay" (DO) flag on their queries. It is also possible to configure Windows 7 clients to request DNSSEC records. That means that a lot of answers will have potentially lots of big signatures in them, just as the example above shows.

This presents a potential problem when a zone becomes signed. In the past, it was specified that a normal DNS response, using UDP, could only be 512-bytes long. DNS responses normally use UDP packets instead of TCP to minimize overhead. However, if a DNS response exceeded 512 bytes, it was mandated that the querier had to revert to TCP and establish a full-blown tcp connection to make the query. Instead of two UDP packets for a query and response, a TCP query would take at least 7 packets to complete (and probably more).

Knowing that DNSSEC and other technologies would eventually require bigger DNS responses, the standards community set out to provide an alternative to TCP-fallback that would allow for larger DNS responses. In 1999, the standards-track RFC 2671 was published, specifying EDNS0, which, among other things, allowed for much larger DNS response sizes (usually up to 4096 bytes in most implementations--although the protocol allows much larger). Problem solved, right?

Well, the EDNS solution raises two issues that are of no fault to EDNS itself. Many firewall vendors and security gurus had been recommending that people block DNS responses larger than 512 bytes. Although there are few, if any, actual vulnerabilities relating to too-big DNS packets, the prevailing security view that "paranioa is a good thing" seemed to make it a best practice to block anything that seemed to violate the original specification, regardless of actual security risk. Some firewall operators took matters into their own hands and blocked both UDP responses larger than 512 bytes and TCP responses! While it is understandable, if somewhat heavy-handed, to block responses that violate the specification, it is utterly wrong-headed to block TCP responses, since they are required by the original DNS specification. [*]

Although the newer EDNS specification has been around for more than a decade, many in the security community have not yet caught up to the fact that DNS responses are now permitted to be larger than 512 bytes using UDP. IST's own firewall service, which uses Cisco Systems Firewall Services Modules (FWSMs) defaults to restricting DNS responses to 512 bytes. (It also, by default, intercepts email SMTP exchanges and prevents TLS from being used, so that external scanning can be done on email.) It's important that users of the service who manage their own rules on the FWSM service disable these restrictions as DNSSEC takes hold in the global Internet.

Fragments and firewalls...uh-oh!

Because EDNS allows large responses, usually up to 4096 bytes, DNS responses may not only exceed 512 bytes, they may exceed the typical maximum frame size of ethernet (generically referred to as "MTU" and typically 1500 bytes) and other data-link protocols. This will cause the response to become fragmented over several packets. Fragments are a core part of the IP specifications, but they do pose some small security risks. First, the packets which follow the first packet in a fragmented message do not have the same header information. In theory, fragments can be used to encapsulate and/or obscurify information that bad guys (or even good guys) don't want IDSes or firewalls to see and/or block. Of course, traffic can be obscurified in many different ways. Second, fragments can be used as part of a denial-of-service attack. However, virtually any packet can be used in this manner to deny service to a host.

The bad news is that many firewalls--even host-based firewalls--block UDP fragments by default. This will break DNSSEC traffic, and it may cause problems with DNS resolution even if the hosts behind the firewall are not performing DNSSEC validation. The good news is that firewalls can be made to reassemble fragments themselves, check the traffic to make sure that it doesn't violate any of the firewall's rules, and pass it on. For host-based firewalls, this is a fairly simple process, while for network firewalls, the large packet may have to be re-fragmented on the wire after passing through the firewall. Even so, the firewall is still able to properly match the traffic to its rules, so that evasion becomes much more difficult. It is however possible to increase the load on network firewalls when having them reassemble fragments, so proceed with care as you change rules. Given the benefits of DNSSEC and the small (and generally mitigable) risks of fragments, it is important for firewalls to allow (and ideally reassemble) fragments, even if only for UDP DNS (UDP/53) traffic.

This is not a UC Berkeley problem!

It's very important to note that the issues we face with the DNSSEC roll-out, especially with respect to firewalls, will occur regardless of whether UC Berkeley rolls out DNSSEC! With the signed root zone roll-out having been completed on July 15, 2010, EDU now signed, and COM and NET potentially being signed in the fall of 2010, DNSSEC data (and the large DNS packets necessary to carry the data) have already started flowing on the global Internet irrespective of the fact that Berkeley's DNS zones are now signed. If you have a device on your network that requests DNSSEC data (as many are beginning to do by default, and others like Windows 7 can easily be configured to do) you will run into the same potential firewall problems with DNS resolution regardless of any actions that IST does or does not take. While we believe in the benefits of DNSSEC for UC Berkeley, we know that at least some of the costs of DNSSEC deployment will be borne regardless of whether UC Berkeley decides to enjoy the benefits. That's why it is important to review your firewall rules now.

How to test?

Because some DNS zones already have signed data, you can test to see if you can receive the necessarily large DNS messages. If you have access to the dig utility (bundled with most unix-like systems and available for Windows by downloading the latest BIND distribution for Windows from www.isc.org), you can try various commands to see if you can receive large packets. For example, you can try to get the DNSSEC keys for the signed DNS zone SE (Sweden's country-code top-level domain):

dig +dnssec SE

You can also try OARC's reply-size tool (information at ) to test the reply-size capabilities of your local nameserver(s):

dig +short rs.dns-oarc.net txt

The latter command will only test the capabilities of the nameserver you are using to do DNS resolution. If, for some reason, clients request DNSSEC data, the tool will not be able to determine if they can correctly receive it. Testing with the former command ('dig +dnssec SE') will determine if clients can receive the proper DNSSEC information.

Other resources

General information on DNSSEC: