A few months ago I published a blog post about Verisign’s plans to increase the strength of the Zone Signing Key (ZSK) for the root zone. I’m pleased to provide this update that we have started the process to pre-publish a 2048-bit ZSK in the root zone for the first time on Sept. 20. Following that, we will publish root zones with the larger key on Oct. 1, 2016.

To help understand how we arrived at this point, let’s take a look back.

Beginning in 2009, Verisign, the Internet Corporation for Assigned Names and Numbers (ICANN), the U.S. Department of Commerce, and the U.S. National Institute of Standards and Technology (NIST) came together and designed the processes and plans for adding Domain Name System Security Extensions (DNSSEC) to the root zone. One of the important design choices discussed at the time was the choice of a cryptographic algorithm and key sizes. Initially, the design team planned on using RSA-SHA1 (algorithm 5). However, somewhat late in the process, RSA-SHA256 (algorithm 8) was selected because that algorithm had recently been standardized, and because it would encourage DNSSEC adopters to run the most recent name server software versions.

One of the big unknowns at the time revolved around the size of Domain Name System (DNS) responses. Until DNSSEC came along, the majority of DNS responses were relatively small in size and could easily fit in the 512-byte size limit imposed by the early standards documents (in order to accommodate some legacy internet infrastructure packet size constraints). With DNSSEC, however, some responses would exceed this limit. DNS operators at the time were certainly aware that some recursive name servers had difficulty receiving large responses, either because of middleboxes (e.g., firewalls) and gateways that (incorrectly) enforced the 512-byte limit, blocked IP fragments or blocked DNS over Transmission Control Protocol (TCP). This uncertainty around legacy system support for large packets is one of the reasons that the design team chose to use a 1024-bit ZSK for the root zone, and also why NIST’s Special Publication 800-57 Part 3 recommended using 1024-bit ZSKs through October 2015.

A number of things have changed since that initial design. 1024-bit RSA keys have fallen out of favor: The CA/Browser forum, for example, deprecated the use of 1024-bit keys for SSL as of 2013. This event caused many in the community to begin the transition away from 1024-bit keys.

Additionally, operational experience over the years has shown that the DNS ecosystem, and perhaps more importantly, the underlying IP network infrastructure, can handle larger responses due to longer key sizes. Furthermore, there is increased awareness that when DNSSEC signature validation is enabled, a recursive name server might need to rely on either fragmentation of large packets, or the transport of DNS messages over TCP.

Today, more than 1,300 top-level domains (TLDs) are signed with DNSSEC. Of these, 97 are already using 2048-bit RSA keys for zone signing. Furthermore, more than 200 TLDs have recently published zones whose DNSKEY response size exceeds 1500 bytes.

For these reasons, now is an appropriate time to strengthen the DNS by increasing the root zone’s ZSK to 2048-bits. Our colleagues at ICANN agree. According to David Conrad, ICANN’s CTO, “ICANN applauds Verisign’s proactive steps in increasing the length of the ZSK, thereby removing any realistic concern of root zone data vulnerability. We see this, along with ICANN’s updating of the Key Signing Key scheduled next year, as critical steps in ensuring the continued trust by the internet community in the root of the DNS.”

To raise awareness among the network and DNS operations communities of this improvement to the security of the internet’s DNS, we presented our plans at the DNS-OARC, NANOG, IETF, RIPE and ICANN meetings; and will continue to post updates on the NANOG, dns-operations, and dnssec-deployment mailing lists, and share updates through the Verisign blog.

Verify Your Network’s Capabilities

It is important to ensure that internet users are able to receive larger responses when they are seen, including signatures from 2048-bit ZSKs. To that end, Verisign has developed a web-based utility that can be used to verify your network and name server’s ability to receive larger, signed responses.

If you’d like to ensure your systems are ready for this security upgrade, visit keysizetest.verisignlabs.com to perform the verification. The page will load a small image file in the background from a number of subdomains, each signed with different ZSK and KSK parameters. The results are displayed on a table, and a successful test should look like this:

Click to Enlarge

If you see different results, you should investigate as described on the web page. If you are unable to solve problems related to resolution of domains signed with large DNSSEC keys, send an email to Verisign at [email protected].

Deployment Schedule

Both Verisign and ICANN have already spent a significant amount of time on development and testing of their systems to support 2048-bit ZSKs. Signatures over the sets of keys have already been generated at two signing ceremonies this year. The next steps are:

• Sept. 20: The first 2048-bit ZSK will be pre-published in the root zone. This follows the normal process for quarterly ZSK rollovers whereby incoming ZSKs are pre-published for a period of approximately 10 days. Should any unforeseen problems arise during this time, Verisign has the ability to “unpublish” the new ZSK and continue using the old (smaller) one.
• Oct. 1: Verisign will publish the first root zone signed with a 2048-bit ZSK. The outgoing 1024-bit ZSK will remain in a post-publish state for approximately 30 days. Similarly, should any unforeseen problems arise during this time, Verisign has the ability to revert to signing with the previous 1024-bit ZSK.

Click to Enlarge

Please take a few moments and verify that your systems are properly provisioned by visiting keysizetest.verisignlabs.com. If you have any concerns that you’d like to make Verisign aware of, please contact us at [email protected].