Innovation

Domain Name System Security Extension (DNSSEC)

Authenticating the Internet from end-to-end.

Developing DNSSEC since the Beginning

Verisign has been involved in DNSSEC development since 2000 and our engineers played a leading role in the development of the DNSSEC Hashed Authenticated Denial of Existence (NSEC3) protocol. As DNSSEC testing, implementation and adoption move forward, we continue to collaborate with the Internet technical community and participate in industry organisations.

Domain Name System Security Extension (DNSSEC) can strengthen trust in the Internet by helping to protect users from redirection to fraudulent websites and unintended addresses.

In July 2010, Verisign—working with the Internet Assigned Numbers Authority (IANA) and the U.S. Department of Commerce (DoC)—completed deployment of DNSSEC in the root zone (the starting point of the DNS hierarchy). Verisign also enabled DNSSEC on .edu in July in collaboration with EDUCAUSE and the DoC, on .net in December 2010 and on .com in March 2011. DNSSEC adoption has progressed since 2011, with a little more than 1/3 of the registries which operate top-level domains (TLDs) now being signed.

In addition, we are taking many steps to help members of the Internet ecosystem take advantage of DNSSEC. These steps include publishing technical resources, providing an Operational Test Environment, leading educational sessions, participating in industry forums and developing tools to simplify DNSSEC management.

Verisign is committed to serving as a trusted steward of the Internet. As the registry for .com and .net and a provider of critical internet infrastructure services, our goal is to enable the Internet’s future innovations while protecting the internet community from new and emerging cyber threats. Our work on DNSSEC is another step in our ongoing fortification of and investment in, critical internet infrastructure.


DNSSEC Timeline

1990 A major flaw in DNS is discovered and dialogue about securing DNS begins.
1995 DNSSEC becomes a formal topic within the IETF.
1999 The DNSSEC protocol (RFC2535) is finished and BIND9 is developed as the first DNSSEC capable implementation.
2001 Key handling creates operational problems that make DNSSEC deployment impossible for large networks. The IETF decides to rewrite the protocol.
2005 DNSSEC standards are rewritten in several RFCs 4033, 4034, 4035. In October, Sweden (.se) enables DNSSEC in their zone.
2007 In July ccTLD .pr (Puerto Rico) enables DNSSEC, followed by .br (Brazil) in September and .bg (Bulgaria) in October.
2008 The NSEC3 standard (RFC 5155) is published. In September ccTLD .cz (Czech Republic) enables DNSSEC.
2009 Verisign and EDUCAUSE host a DNSSEC test bed for selected .edu registrants. Root zone signed for internal use by Verisign and ICANN. ICANN and Verisign exercise signing the ZSK with the KSK.
2010 The first root server begins serving the signed root, utilising the DURZ (deliberately unvalidatable root zone) methodology. All root servers serving the signed root, using the DURZ methodology. ICANN holds first KSK ceremony event in Culpeper, VA, USA. ICANN publishes the root zone trust anchor and root operators begin to serve the signed root zone with actual keys - the signed root zone is available. Verisign and EUDCAUSE enable DNSSEC for the .edu domain. Verisign enables DNSSEC for the .net domain.
2011 In February, DNSSEC enabled .gov registry is transitioned to Verisign. In March, .com is signed and the Verisign Managed DNS service is enhanced with full support for DNSSEC compliance. 59 TLDs are signed with trust anchors in the root zone.
2012 In January, Comcast announced that its customers are using DNSSEC-validating resolvers. From March, the number of TLDs signed grew to 90.