Domain Name System Security Extensions

The Domain Name System Security Extensions (DNSSEC) is a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks.

DNSSEC does not protect against DoS attacks directly, though it indirectly provides some benefit (because signature checking allows the use of potentially untrustworthy parties).

DNSSEC was designed to be extensible so that as attacks are discovered against existing algorithms, new ones can be introduced in a backward-compatible fashion as described in RFC 8624.

The lookup procedure is different for recursive name servers such as those of many ISPs, and for stub resolvers such as those included by default in mainstream operating systems.

Using such a validating stub resolver gives the client end-to-end DNS security for domains implementing DNSSEC, even if the Internet service provider or the connection to them is not trusted.

[13] An authentication chain is a series of linked DS and DNSKEY records, starting with a trust anchor to the authoritative name server for the domain in question.

These timestamps imply that a zone must regularly be re-signed and re-distributed to secondary servers, or the signatures will be rejected by validating resolvers.

[17] DNS-based Authentication of Named Entities (DANE) is an IETF working group[18] with the goal of developing protocols and techniques that allow Internet applications to establish cryptographically secured communications with TLS, DTLS, SMTP, and S/MIME based on DNSSEC.

The new protocols will enable additional assurances and constraints for the traditional model based on public key infrastructure.

The DNSSEC specification (RFC4033-4035) specifies that a resolver, when receiving a signed packet from the upstream, should try all keys with the correct "tag" on all signatures until one of the combinations successfully verifies.

In response, resolvers began to place limits on the amount of verification errors, key tag collisions, and hash calculations.

Over time, advancements in hashing using GPUs and dedicated hardware meant that NSEC3 responses could be cheaply brute forced using offline dictionary attacks.

[25] Due to the messy evolution of the protocol and a desire to preserve backwards compatibility, online DNSSEC signing servers return a "white lie" instead of authenticating a denial of existence directly.

Thus, there is strong incentive to secure DNS, and deploying DNSSEC is generally considered to be a critical part of that effort.

Early adopters include Brazil (.br), Bulgaria (.bg), Czech Republic (.cz), Namibia (.na)[32] Puerto Rico (.pr) and Sweden (.se), who use DNSSEC for their country code top-level domains;[33] RIPE NCC, who have signed all the reverse lookup records (in-addr.arpa) that are delegated to it from the Internet Assigned Numbers Authority (IANA).

[40] Afilias and PIR also detailed on September 26, 2008, that the first phase, involving large registrars it has a strong working relationship with ("friends and family") would be the first to be able to sign their domains, beginning "early 2009".

within 24 months,[43] and on November 16 of the same year, they said the .com and .net domains would be signed by the first quarter of 2011, after delays caused by technical aspects of the implementation.

On June 3, 2009, the National Institute of Standards and Technology (NIST) announced plans to sign the root by the end of 2009, in conjunction with ICANN, VeriSign and the NTIA.

[53] This means the keys that were used to sign the zone use are deliberately unverifiable; the reason for this deployment was to monitor changes in traffic patterns caused by the larger responses to queries requesting DNSSEC resource records.

[48] Underneath the root there is a large set of top-level domains that must be signed in order to achieve full DNSSEC deployment.

[65] The Science and Technology Directorate of the U.S. Department of Homeland Security (DHS) sponsors the "DNSSEC Deployment Initiative".

It was reported[66] that on March 30, 2007, the U.S. Department of Homeland Security proposed "to have the key to sign the DNS root zone solidly in the hands of the US government."

The draft lays out a series of options for who could be the holder, or "operator," of the Root Zone Key, essentially boiling down to a governmental agency or a contractor.

"Nowhere in the document do we make any proposal about the identity of the Root Key Operator," said Maughan, the cyber-security research and development manager for Homeland Security."

NIST had suggested using split domains, a technique that is known to be possible but is difficult to deploy correctly, and has the security weaknesses noted above.

[70] While the memo focuses on .gov sites, the U.S. Defense Information Systems Agency says it intends to meet OMB DNSSEC requirements in the .mil (U.S. military) domain as well.

NetworkWorld's Carolyn Duffy Marsan stated that DNSSEC "hasn't been widely deployed because it suffers from a classic chicken-and-egg dilemma... with the OMB mandate, it appears the egg is cracking.

[74] According to a study at APNIC, the proportion of clients who exclusively use DNS resolvers that perform DNSSEC validation rose to 8.3% in May 2013.

In September 2015, Verisign announced their free public DNS resolver service,[76] and although unmentioned in their press releases, it also performs DNSSEC validation.

By the beginning of 2016, APNIC's monitoring showed the proportion of clients who exclusively use DNS resolvers that perform DNSSEC validation had increased to about 15%.