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 implementation and adoption move forward, we continue to collaborate with the internet technical community and participate in industry organizations.
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 domain name system (DNS) hierarchy). Verisign also enabled DNSSEC on .edu in July 2010 in collaboration with EDUCAUSE and the National Telecommunications and Information Administration (NTIA), for .net in December 2010 and for .com in March 2011. DNSSEC adoption has progressed since 2011, with nearly all top-level domains (TLDs) adopting DNSSEC and with signed delegations published in the root zone.
In addition, we have taken 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 and participating in industry forums.
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 cyberattacks. Our work on DNSSEC is another step in our ongoing fortification of and investment in critical internet infrastructure.
|A major flaw in DNS is discovered and dialog about securing DNS begins.
|DNSSEC becomes a formal topic within the Internet Engineering Task Force (IETF).
|The DNSSEC protocol (RFC2535) is finished and BIND9 is developed as the first DNSSEC capable implementation.
|Key handling creates operational problems that make DNSSEC deployment impossible for large networks. The IETF decides to rewrite the protocol.
|DNSSEC standards are rewritten in several RFCs 4033, 4034 and 4035. In October, Sweden (.se) enables DNSSEC in their zone.
|In July, ccTLD .pr (Puerto Rico) enables DNSSEC, followed by .br (Brazil) in September and .bg (Bulgaria) in October.
|The NSEC3 standard (RFC 5155) is published. In September, ccTLD .cz (Czech Republic) enables DNSSEC.
|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 Zone Signing Key (ZSK) with the Key Signing Key (KSK).
|The first root server begins serving the signed root, following a community evaluation and testing period. ICANN holds first KSK ceremony event. 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.
|In March, Verisign enables DNSSEC for the .com domain, and Verisign’s Managed DNS service is enhanced with full support for DNSSEC compliance. 59 TLDs are signed with delegations in the root zone.
|In January, Comcast announced that its customers are using DNSSEC-validating resolvers. As of March, the number of TLDs signed grew to 90.
|In March, Google announced that its Public DNS service implements DNSSEC validation.
|In October, Verisign strengthened DNSSEC for the root zone by increasing the ZSK size to 2048-bits.
|In October, Verisign, IANA and ICANN performed the first root zone KSK rollover.
|1,390 TLDs are signed with signed delegations in the root zone.