DNSSEC

DNSSEC works to protect the internet community from forged 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 can also prove that a domain name does not exist.

DNSSEC benefits many components within the internet infrastructure ecosystem. 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, the user's computer requests the domain name record from a recursive name server, often located at an ISP or within an enterprise network. It also requests the DNSSEC signature for that record. 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 these records, it also requests the public key associated with the zone. The key and the signature allow 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 allows the user to 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 resolve the domain name to an address, which prevents the user from reaching the fraudulent site.

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 other 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 cooperation with IANA and the U.S. Department of Commerce, Verisign completed the deployment of DNSSEC in the root zone—the starting point of the DNS hierarchy—in 2010. That same year, we enabled DNSSEC in the .edu zone, in collaboration with EDUCAUSE and the National Telecommunications and Information Administration (NTIA). Shortly afterward, we deployed DNSSEC in the .net and .com zones. Since then, nearly all top-level domains (TLDs) have adopted DNSSEC, with signed delegations published in the root zone.

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