WHAT IS DNSSEC?

DNSSEC works to protect the internet community from forged Domain Name System (DNS) data by using public key cryptography to digitally sign authoritative zone data. DNSSEC validation helps to assure users that the data originated from the stated source and that it was not modified in transit. DNSSEC also can prove that a domain name does not exist.

Although DNSSEC enhances DNS security, it's not a comprehensive solution. It does not protect against distributed denial of service (DDoS) attacks, ensure confidentiality of data exchanges, encrypt website data, or prevent IP address spoofing or phishing. Other layers of protection, such as DDoS mitigation, security intelligence, site validation, Secure Sockets Layer (SSL) encryption, and two-factor authentication, are also critical to help make the internet more secure. These mechanisms can be used in conjunction with DNSSEC.

DNSSEC benefits many components within the internet infrastructure ecosystem. Its effective deployment requires the involvement of many stakeholders within the internet community. Registries, registrars, domain name registrants, hardware and software vendors, internet service providers (ISPs), government entities, and ordinary internet users all have roles to play to ensure success and bring vital improvements to internet security. DNSSEC is designed to provide the following benefits to:

• The internet community by improving security in the zones that are signed.
• Registrars by allowing them to offer domain signing services to their customers.
• ISPs by enhancing the security of the data returned to their customers.
• Users by guarding them from DNS vulnerabilities such as cache poisoning and "man-in-the-middle" attacks.

In DNSSEC, each zone has at least one 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 the public keys of lower-level (child) zones. The authoritative name servers for these zones may be managed by registrars, ISPs, hosting/cloud providers or registrants.

When an end user wants to access an internet resource, a stub resolver within the user's operating system requests the domain name record from a recursive name server, often located at an ISP or within an enterprise network. If the requested information is not currently cached, the recursive name server makes the request to the appropriate authoritative name server. After the server requests this record, it also requests the DNSSEC public key associated with the zone. This key allows the recursive server to verify that the information 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.

There are many pieces to the overall puzzle of internet security. DNSSEC may mitigate the security concerns generated by “man-in-the-middle” attacks and cache poisoning, but it is not an overall security solution. DNSSEC does not solve many of the most common threats to internet security, like spoofing or phishing. For this reason, other layers of protection, such as SSL certificates and two-factor authentication, are critical to making the internet secure for everyone.

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 2010 in collaboration with EDUCAUSE and the DoC on .net in December 2010, and on .com in March 2011.

The successful deployment of DNSSEC has far-reaching benefits for the global internet community by increasing trust for a multitude of internet activities, including e-commerce, online banking, email, VoIP and online software distribution. However, the entire internet community shares the responsibility for making DNSSEC successful. Success requires the active, coordinated participation of registries, registrars, registrants, hosting companies, software developers, hardware vendors, government and internet technologists and coalitions.

The internet root zone, TLDs such as .gov, .org, .museum, and a number of country-code TLDs (ccTLDs), have signed the zones that they manage. Other TLDs such as .edu, .net and .com implemented DNSSEC in 2010 and 2011. These TLDs have started accepting second-level DNSSEC-signed domain names. Large ISPs such as Comcast, and public recursive resolvers from Verisign, Google, Quad9 and Cloudflare have validation for their users. Additionally, some registrars have included DNSSEC implementation in their security solutions. In addition, the Internet Corporation for Assigned Names and Numbers (ICANN) has required that registry operators implement DNSSEC for all new generic TLDs.

Although both DNSSEC and SSL rely on public key cryptography, they each perform very different functions that complement, rather than replace, one another.

In a very simplistic model, DNSSEC deals with "where," and SSL deals with "who" and "how."

• Where—DNSSEC uses digital signatures to verify DNS data integrity, thereby ensuring that users reach the intended IP address. Its job is done once the user reaches the address. DNSSEC does not ensure the identity of the entity at the address, and it does not encrypt interactions between the user and the site.
• Who—SSL uses digital certificates to validate the identity of a site. When these certificates are issued by reputable, third-party certificate authorities (CAs), SSL assures users of the identity of the website owner. However, SSL does nothing to ensure that a user reaches the right site, so it is not applicable against attacks that redirect users. In other words, SSL site validation is effective, but only if a user reaches the correct destination first.
• How—SSL also uses digital certificates to encrypt data exchanges between a user and a site, thereby protecting the confidentiality of financial transactions, communications, e-commerce, and other sensitive interactions.

When woven together, DNSSEC and SSL increase security and trust on the internet: Users can reliably ascertain where they are going, who they are interacting with, and how confidential their interactions are.

1994: First draft of possible standard published
1997: RFC 2065 published (DNSSEC is an IETF standard) 

1999: RFC 2535 published (DNSSEC standard is revised) 

2005: Full rewrite of standards published 
RFC 4033 (Introduction and Requirements), 
RFC 4034 (New Resource Records) 
and RFC 4035 (Protocol Changes) 

July 2010: Root zone signed 

July 2010: .edu signed 

December 2010: .net signed 

March 2011: .com signed 

January 2012: Comcast announces that its customers are using DNSSEC-validating resolvers 

2019: 1,390 TLDs are signed with signed delegations in the root zone.