imgSubHeaderWhyVerisignAlt
Innovation + Initiatives

As the Internet continues to expand, we are committed to creating and driving advancements that keep the Internet fast, safe, and reliable for all users.

DNSSEC Overview

Why DNSSEC? How It Works Success Pillars History of DNSSEC

The Domain Name System (DNS), the Internet's addressing system, is the most critical component of the Internet infrastructure. Without it, the Internet could not function. However, it was not designed with security in mind. As a result, it is vulnerable to man-in-the-middle (MITM) attacks and cache poisoning These threats use forged data to redirect Internet traffic to fraudulent sites and unintended addresses. Learn more about DNS.

Once an unsuspecting user or device reaches the fraudulent site, cyber criminals can potentially extract credit card data, steal user passwords, eavesdrop on voice over IP (VoIP) communications, plant malicious software, or display images and text that defame the legitimate brand or provide misleading information. Given that a single DNS name server can act as the name-to-address resolution point for thousands of users, the potential impact of a MITM attack or cache poisoning can be considerable.

Domain Name System Security Extension (DNSSEC) adds security to the DNS. It is designed to address MITM attacks and cache poisoning by authenticating the origin of DNS data and verifying its integrity while moving across the Internet.

DNSSEC Benefits for End Users

DNSSEC presents opportunities to all members of the Internet ecosystem. Its most direct and widespread impact is on end users.

  • Trusted activities—Strengthening DNS security, DNSSEC increases trust for a multitude of Internet activities, including e-commerce, online banking, email, VoIP, and online software distribution.
  • Customer and brand protection—DNSSEC mitigates the risk of customers becoming the unwitting victims of cyber crimes when they attempt to access a resource.
  • New types of secure transactions—DNSSEC opens the door to using the DNS system for new types of secure data transactions.

The Internet Engineering Task Force (IETF) has been working for more than 15 years to develop a workable standard for the domain name system security extensions (DNSSEC). DNSSEC protects the Internet community from forged DNS data by using public key cryptography to digitally sign authoritative zone data when it comes into the system and then validate it at its destination. Learn more about public key cryptography.

Digital signing helps assure users that the data originated from the stated source and that it was not modified in transit. DNSSEC can also establish that a domain name does not exist. These capabilities are essential to maintaining trust in the Internet.

In DNSSEC, each zone has a public/private key pair. The zone's public key is published using DNS, while the zone's private key is kept safe and ideally stored offline. A zone's private key signs individual DNS data in that zone, creating digital signatures that are also published with DNS.

DNSSEC uses a rigid trust model and this chain of trust flows from parent zone to child zone. Higher-level (parent) zones sign, or vouch for, the public keys of lower-level (child) zones. The authoritative name servers for these various zones may be managed by registrars, Internet service providers (ISPs), web hosting companies, or website operators (registrants) themselves.

When an end user wants to access a website, a stub resolver on the user's computer requests the website's IP address from a recursive name server. After the server requests this record, it also requests the DNSSEC key associated with the zone. This key allows the server to verify that the IP address record it receives is identical to the record on the authoritative name server.

If the recursive name server determines that the address record has been sent by the authoritative name server and has not been altered in transit, it resolves the domain name and the user can access the site. This process is called validation. If the address record has been modified or is not from the stated source, the recursive name server does not allow the user to reach the fraudulent address. DNSSEC can also prove that a domain name does not exist. As a result of this process, DNS queries and responses are protected from man-in-the-middle (MITM) attacks and the kind of forgeries that could possibly redirect Internet users to phishing and pharming sites.

To ensure the global success of DNSSEC, Verisign advocates a proactive but cautious approach that revolves around three core principles:

  • DNSSEC is a sound solution to a specific Internet vulnerability, but it must be complemented by other layers of security.
  • A controlled, methodical rollout of DNSSEC is safest.
  • The entire Internet ecosystem shares responsibility for DNSSEC.

A Sound Solution to a Specific Vulnerability

Although DNSSEC enhances DNS security, it is only one component of a layered approach to Internet infrastructure security. It does not protect name servers from distributed denial of service (DDoS) attacks, ensure confidentiality of data exchanges, encrypt website data, or prevent IP address spoofing and phishing. Other layers of protection, such as DDoS mitigation, security intelligence, Secure Sockets Layer (SSL) encryption and site validation, and two-factor authentication, are also critical to making the Internet more secure. These mechanisms should be used in conjunction with DNSSEC.

Measured, Controlled Rollout

The broad implementation of DNSSEC introduces a set of complex changes that impacts the entire Internet ecosystem and requires extensive resources, documentation, testing, and industry coordination. Any rollout of DNSSEC must proceed in phases, especially for the reliable operation of globally crucial top-level domains (TLDs) such as .com and .net. Long-term strategy, planning, and collaboration—not only within and across organizations and industries, but also internationally—creates a strong foundation for successful implementation.

Shared Responsibility

Because cache poisoning can occur at any point in the Internet, DNSSEC is most effective when universally implemented—starting at the root zone and top-level domains (TLDs) and moving down to individual domain names. Registries, registrars, registrants, hosting companies, software developers, hardware vendors, government, businesses and agencies with an Internet presence, and Internet technologists and coalitions all have responsibility for the success of this massive effort.

DNSSEC adoption is gaining momentum as governments, financial institutions, Internet service providers (ISPs), businesses, and other organizations become increasingly aware of DNS-related threats.

The Internet root zone, top-level domains (TLDs) such as .net, .com, .gov, .org, .museum, and .edu, and a number of country code TLDs (ccTLDs) have completed full DNSSEC deployment. These TLDs have begun accepting second-level DNSSEC-signed domain names. Some ISPs have announced their intention to activate validation on the recursive name servers that answer user queries, and some registrars have included DNSSEC implementation on their roadmap. In addition, ICANN has opened applications for new TLDs, and it is likely that ICANN will require successful new TLD applicants to have plans for DNSSEC implementation.

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 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 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.

Verisign's Role

Verisign has been involved in DNSSEC development since 2000, and our engineers played a leading role in the development of the NSEC3 protocol. We continue to collaborate with the Internet technical community as DNSSEC testing, implementation, and adoption move forward. For example, we were an active member of the DNSSEC Coalition, an industry organization dedicated to facilitating DNSSEC adoption. Also, to ensure that we are using the best practices, we share what we have learned in our DNSSEC deployments, and support a consistent DNSSEC approach across registries.

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. In addition, a number of top-level domains (TLDs) have been signed by other registries, including .gov, .org, and country code TLD names for Brazil, Bulgaria, Czech Republic, Puerto Rico, and Sweden.

We have also 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, participating in industry forums, developing tools to simplify DNSSEC management, and assisting the community with an interoperability lab.

Need more info?

Call +1-703-925-6999
Email or Chat with Customer Support.