DNSSEC
Authenticating the internet from end-to-end.
DEVELOPING DOMAIN NAME SYSTEM SECURITY EXTENSION (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 organizations.
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 multiple 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 next innovations while protecting the internet community from new and emerging cyber attacks. 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 dialog 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 select .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, utilizing 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 EDUCAUSE 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 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. As of March, the number of TLDs signed grew to 90. |