Blue Folder With Keyhole on digital background

Increasing the Strength of the Zone Signing Key for the Root Zone

One of the most interesting and important changes to the internet’s domain name system (DNS) has been the introduction of the DNS Security Extensions (DNSSEC). These protocol extensions are designed to provide origin authentication for DNS data. In other words, when DNS data is digitally signed using DNSSEC, authenticity can be validated and any modifications detected.

A major milestone was achieved in mid-2010 when Verisign and the Internet Corporation for Assigned Names and Numbers (ICANN), in cooperation with the U.S. Department of Commerce, successfully deployed DNSSEC for the root zone. Following that point in time, it became possible for DNS resolvers and applications to validate signed DNS records using a single root zone trust anchor.

DNSSEC works by forming a chain-of-trust between the root (i.e., the aforementioned trust anchor) and a leaf node. If every node between the root and the leaf is properly signed, the leaf data is validated. However, as is generally the case with digital (and even physical) security, the chain is only as strong as its weakest link.

Resolving a Query with DNSSEC

To strengthen the chain at the top of the DNS, Verisign is working to increase the strength of the root zone’s Zone Signing Key (ZSK), which is currently 1024-bit RSA, and will sign the root zone with 2048-bit RSA keys beginning Oct. 1, 2016.

With this change, the root zone ZSK size will match the size of the KSK: both will be 2048-bits. One difference, however, is that the ZSK is changed (rolled) four times per year, or approximately every 90 days.

The root zone will not be the first to use a 2048-bit ZSK. Approximately 60 top-level domains (TLDs) are known to be using 2048-bit RSA ZSKs already.

Verisign, in its role as the Root Zone Maintainer and root zone ZSK operator, is actively involved in communication and cooperation with other relevant groups and partners, including: ICANN, the U.S. Department of Commerce, the root server operators, and the larger communities of DNS operators and internet users. In 2015, Verisign publicly presented research on the effects of increasing the ZSK. More recently we shared our plan and schedule at the 24th DNS-OARC Workshop in Buenos Aires.

WHY YOU SHOULD CARE

An increase in the size of the root zone ZSK leads to an increase in the size of DNS responses from the root name servers. As DNS responses become larger, we worry more and more about the ability of root server clients to receive them. Sometimes large DNS responses have difficulty reaching their destinations due to IP fragmentation. It is well-known that many types of internet firewalls, routers and middleboxes block IP fragments. Clients behind such devices might never receive fragmented User Datagram Protocol (UDP) DNS responses. They’ll be forced to retry with lower UDP Payload Size values, or perhaps over Transmission Control Protocol (TCP).

Note that even if your recursive name server is not configured for DNSSEC validation, it might be configured to receive DNSSEC signatures. Many name server implementations are configured, by default, to ask for the DNSSEC data with each response.

For the upcoming increase in ZSK size, all normally-occurring DNS responses are still well below the typical size at which fragmentation must happen for Ethernet interfaces: 1472 bytes. With a 2048-bit ZSK, responses exceeding 1300 bytes will rarely be seen. [1]

Nonetheless, 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 anyone can use to test their network and name server’s ability to receive larger, signed responses.

TEST YOUR NETWORK

Visit keysizetest.verisignlabs.com to perform the test. 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:

Test-Page-ZSK

If you see different results, you should investigate as described on the web page. If you seem unable to solve problems related to resolution of domains signed with large DNSSEC keys, send an email to Verisign at info@verisign-grs.com.

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. As part of this process, Verisign has upgraded the Hardware Security Modules (HSMs) used to store private keys and to generate signatures from them. The next steps are:

  • Mid-May: ICANN to sign the transitional ZSKs at its next key signing ceremony.
  • 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 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.

ZSK-length-change-blog-diagram
Please take a few moments to test your systems by visiting keysizetest.verisignlabs.com. If you have any concerns that you’d like to make Verisign aware of, please contact us at info@verisign-grs.com.


1. Exceptions being responses to the SOA and ANY query types.

Share:

Duane Wessels

Principal Research Scientist. Duane Wessels is Principal Research Scientist, with a focus on DNSSEC projects. He is responsible for collecting and analyzing large amounts of data during the initial rollout of the signed root zone. He is working on Verisign’s DNSSEC interoperability lab and other DNSSEC tools for both internal and public use. He is also managing collaborative university research... Read More →

Leave a Reply