Domain Name System Security Extensions

DNS is implemented by the use of several resource records. To implement DNSSEC, several new DNS record types were created or adapted to use with DNSSEC:

RRSIG (resource record signature)

Contains the DNSSEC signature for a record set. DNS resolvers verify the signature with a public key, stored in a DNSKEY record.

DNSKEY

Contains the public key that a DNS resolver uses to verify DNSSEC signatures in RRSIG records.

DS (delegation signer)

Holds the name of a delegated zone. References a DNSKEY record in the sub-delegated zone. The DS record is placed in the parent zone along with the delegating NS records.

NSEC (next secure record)

Contains a link to the next record name in the zone and lists the record types that exist for the record's name. DNS resolvers use NSEC records to verify the non-existence of a record name and type as part of DNSSEC validation.

NSEC3 (next secure record version 3)

Contains links to the next record name in the zone (in hashed name sorting order) and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 record's own name. These records can be used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation. NSEC3 records are similar to NSEC records, but NSEC3 uses cryptographically hashed record names to avoid the enumeration of the record names in a zone.

NSEC3PARAM (next secure record version 3 parameters)

Authoritative DNS servers use this record to calculate and determine which NSEC3 records to include in responses to DNSSEC requests for non-existing names/types.

When DNSSEC is used, each answer to a DNS lookup contains an RRSIG DNS record, in addition to the record type that was requested. The RRSIG record is a digital signature of the answer DNS resource record set. The digital signature is verified by locating the correct public key found in a DNSKEY record. The NSEC and NSEC3 records are used to provide cryptographic evidence of the non-existence of any Resource Record (RR). The DS record is used in the authentication of DNSKEYs in the lookup procedure using the chain of trust. NSEC and NSEC3 records are used for robust resistance against spoofing.

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 following table defines, as of June 2019, the security algorithms that are or were most often used:[5]

From the results of a DNS lookup, a security-aware DNS resolver can determine whether the authoritative name server for the domain being queried supports DNSSEC, whether the answer it receives is secure, and whether there is some sort of error. 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. Microsoft Windows uses a stub resolver, and Windows Server 2008 R2 and Windows 7 in particular use a non-validating but DNSSEC-aware stub resolver.[6][7]

Using the chain of trust model, a Delegation Signer (DS) record in a parent domain (DNS zone) can be used to verify a DNSKEY record in a subdomain, which can then contain other DS records to verify further subdomains. Say that a recursive resolver such as an ISP name server wants to get the IP addresses (A record and/or AAAA records) of the domain "www.example.com".

1. The process starts when a security-aware resolver sets the "DO" ("DNSSEC OK") flag bit in a DNS query. Since the DO bit is in the extended flag bits defined by Extension Mechanisms for DNS (EDNS), RFC 6891, all DNSSEC transactions must support EDNS. EDNS support is also needed to allow for the much larger packet sizes that DNSSEC transactions require.
2. When the resolver receives an answer via the normal DNS lookup process, it then checks to make sure that the answer is correct. Ideally, the security-aware resolver would start with verifying the DS and DNSKEY records at the DNS root. Then it would use the DS records for the "com" top-level domain found at the root to verify the DNSKEY records in the "com" zone. From there, it would see if there is a DS record for the "example.com" subdomain in the "com" zone, and if there were, it would then use the DS record to verify a DNSKEY record found in the "example.com" zone. Finally, it would verify the RRSIG record found in the answer for the A records for "www.example.com".

There are several exceptions to the above example.

First, if "example.com" does not support DNSSEC, there will be no RRSIG record in the answer and there will not be a DS record for "example.com" in the "com" zone. If there is a DS record for "example.com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC information and modifying the A records. Or, it could be a broken security-oblivious name server along the way that stripped the DO flag bit from the query or the RRSIG record from the answer. Or, it could be a configuration error.

Next, it may be that there is not a domain name named "www.example.com", in which case instead of returning a RRSIG record in the answer, there will be either an NSEC record or an NSEC3 record. These are "next secure" records that allow the resolver to prove that a domain name does not exist. The NSEC/NSEC3 records have RRSIG records, which can be verified as above.

Finally, it may be that the "example.com" zone implements DNSSEC, but either the "com" zone or the root zone do not, creating an "island of security" which needs to be validated in some other way. As of 15 July 2010, deployment of DNSSEC to root is completed.[8] The .com domain was signed with valid security keys and the secure delegation was added to the root zone on 1 April 2011.[9]

Stub resolvers are "minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution to a recursive name server."[10] A stub resolver will simply forward a request to a recursive name server, and use the Authenticated Data (AD) bit in the response as a "hint to find out whether the recursive name server was able to validate signatures for all of the data in the Answer and Authority sections of the response."[11] Microsoft Windows uses a stub resolver, and Windows Server 2008 R2 and Windows 7 in particular use a non-validating but AD-bit-aware stub resolver.[6][7]

A validating stub resolver can also potentially perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages.[11] A validating stub resolver uses the CD bit to perform its own recursive authentication. 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.

Non-validating stub resolvers must rely on external DNSSEC validation services, such as those controlled by the user's Internet service provider or a public recursive name server, and the communication channels between itself and those name servers, using methods such as DNS over TLS.[11][12]

To be able to prove that a DNS answer is correct, one needs to know at least one key or DS record that is correct from sources other than the DNS. These starting points are known as trust anchors and are typically obtained with the operating system or via some other trusted source. When DNSSEC was originally designed, it was thought that the only trust anchor that would be needed was for the DNS root. The root anchors were first published on 15 July 2010.[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. Without a complete authentication chain, an answer to a DNS lookup cannot be securely authenticated.

To limit replay attacks, there are not only the normal DNS TTL values for caching purposes, but additional timestamps in RRSIG records to limit the validity of a signature. Unlike TTL values which are relative to when the records were sent, the timestamps are absolute. This means that all security-aware DNS resolvers must have clocks that are fairly closely in sync, say to within a few minutes.

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.

DNSSEC involves many different keys, stored both in DNSKEY records, and from other sources to form trust anchors.

In order to allow for replacement keys, a key rollover scheme is required. Typically, this involves first rolling out new keys in new DNSKEY records, in addition to the existing old keys. Then, when it is safe to assume that the time to live values have caused the caching of old keys to have passed, these new keys can be used. Finally, when it is safe to assume that the caching of records using the old keys have expired, the old DNSKEY records can be deleted. This process is more complicated for things such as the keys to trust anchors, such as at the root, which may require an update of the operating system.

Keys in DNSKEY records can be used for two different things and typically different DNSKEY records are used for each. First, there are key signing keys (KSK) which are used to sign other DNSKEY records containing zone signing keys (ZSK), which are used to sign other records. Since the ZSKs are under complete control and use by one particular DNS zone, they can be switched more easily and more often. As a result, ZSKs can be much shorter than KSKs and still offer the same level of protection while reducing the size of the RRSIG/DNSKEY records.

When a new KSK is created, the DS record must be transferred to the parent zone and published there. The DS records use a message digest of the KSK instead of the complete key in order to keep the size of the records small. This is helpful for zones such as the .com domain, which are very large. The procedure to update DS keys in the parent zone is also simpler than earlier DNSSEC versions that required DNSKEY records to be in the parent zone.

DNS-based Authentication of Named Entities (DANE) is an IETF working group[14] 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. They will also enable domain holders to assert certificates for themselves, without reference to third-party certificate authorities.

Support for DNSSEC stapled certificates was enabled in Google Chrome 14,[15] but was later removed.[16] For Mozilla Firefox, support was provided by an add-on[17] while native support is currently awaiting someone to start working on it.[18]

The NSEC3 records (RFC 5155) were created as an alternative which hashes the name instead of listing them directly. Over time, advancements in hashing using GPUs and dedicated hardware meant that NSEC3 responses could be cheaply brute forced using offline dictionary attacks. NSEC5 has been proposed to allow authoritative servers to sign NSEC responses without having to keep a private key that can be used to modify the zone. Thus stealing an NSEC5KEY would only result in the ability to more easily enumerate a zone.[20]

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. The technique outlined in RFC 4470 returns a NSEC record in which the pairs of domains lexically surrounding the requested domain. For example, request for k.example.com would thus result in an NSEC record proving that nothing exists between the (fictitious) domains j.example.com and l.example.com. This is also possible with NSEC3 records.[21]

CloudFlare pioneered a pair of alternative approaches, which manage to achieve the same result in one third of the response size.[22] The first is a variation on the "white lies" approach, called "black lies", which exploits common DNS client behavior to state the nonexistence more compactly.[23] The second approach instead chooses to prove that "the record exists but the requested record type does not", which they call "DNS shotgun".[24][22]

Early adopters include Brazil (.br), Bulgaria (.bg), Czech Republic (.cz), Namibia (.na)[27] Puerto Rico (.pr) and Sweden (.se), who use DNSSEC for their country code top-level domains;[28] 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).[29] ARIN is also signing their reverse zones.[30] In February 2007, TDC became the first Swedish ISP to start offering this feature to its customers.[31]

IANA publicly tested a sample signed root since June 2007. During this period prior to the production signing of the root, there were also several alternative trust anchors. The IKS Jena introduced one on January 19, 2006,[32] the Internet Systems Consortium introduced another on March 27 of the same year,[33] while ICANN themselves announced a third on February 17, 2009.[34]

On June 2, 2009, Afilias, the registry service provider for Public Interest Registry's .org zone signed the .org TLD.[35] 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".[36] On June 23, 2010, 13 registrars were listed as offering DNSSEC records for .ORG domains.[37]

VeriSign ran a pilot project to allow .com and .net domains to register themselves for the purpose of NSEC3 experimentation. On February 24, 2009, they announced that they would deploy DNSSEC across all their top-level domains (.com, .net, etc.) within 24 months,[38] 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.[39] This goal was achieved on-schedule[40] and Verisign's DNSSEC VP, Matt Larson, won InfoWorld's Technology Leadership Award for 2011 for his role in advancing DNSSEC.[41][42]

DNSSEC was first deployed at the root level on July 15, 2010.[43] This is expected to greatly simplify the deployment of DNSSEC resolvers, since the root trust anchor can be used to validate any DNSSEC zone that has a complete chain of trust from the root. Since the chain of trust must be traced back to a trusted root without interruption in order to validate, trust anchors must still be configured for secure zones if any of the zones above them are not secure. For example, if the zone "signed.example.org" was secured but the "example.org" zone was not, then, even though the ".org" zone and the root are signed, a trust anchor has to be deployed in order to validate the zone.

Political issues surrounding signing the root have been a continuous concern, primarily about some central issues:

• Other countries are concerned about U.S. control over the Internet, and may reject any centralized keying for this reason.
• Some governments might try to ban DNSSEC-backed encryption key distribution.

In September 2008, ICANN and VeriSign each published implementation proposals[44] and in October, the National Telecommunications and Information Administration (NTIA) asked the public for comments.[45] It is unclear if the comments received affected the design of the final deployment plan.

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.[46]

On October 6, 2009, at the 59th RIPE Conference meeting, ICANN and VeriSign announced the planned deployment timeline for deploying DNSSEC within the root zone.[47] At the meeting it was announced that it would be incrementally deployed to one root name server a month, starting on December 1, 2009, with the final root name server serving a DNSSEC signed zone on July 1, 2010, and the root zone will be signed with a RSA/SHA256 DNSKEY.[47] During the incremental roll-out period the root zone will serve a Deliberately Unvalidatable Root Zone (DURZ) that uses dummy keys, with the final DNSKEY record not being distributed until July 1, 2010.[48] 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.

The .org top-level domain was signed with DNSSEC in June 2010, followed by .com, .net, and .edu later in 2010 and 2011.[49][50] Country code top-level domains were able to deposit keys starting in May 2010.[51] As of November 2011 more than 25% of top-level domains are signed with DNSSEC.[52]

On January 25, 2010, the L (ell) root server began serving a Deliberately Unvalidatable Root Zone (DURZ). The zone uses signatures of a SHA-2 (SHA-256) hash created using the RSA algorithm, as defined in RFC 5702. As of May 2010, all thirteen root servers began serving the DURZ.[48] On July 15, 2010, the first root full production DNSSEC root zone was signed, with the SOA serial 2010071501. Root trust anchors are available from IANA.[43]

Underneath the root there is a large set of top-level domains that must be signed in order to achieve full DNSSEC deployment. The List of Internet top-level domains provides details about which of the existing top-level domains have been signed and linked to the root.

In March 2006, the Internet Systems Consortium introduced the DNSSEC Lookaside Validation registry.[53] DLV was intended to make DNSSEC easier to deploy in the absence of a root trust anchor. At the time it was imagined that a validator might have to maintain large numbers of trust anchors corresponding to signed subtrees of the DNS.[54] The purpose of DLV was to allow validators to offload the effort of managing a trust anchor repository to a trusted third party. The DLV registry maintained a central list of trust anchors, instead of each validator repeating the work of maintaining its own list.

To use DLV, a validator that supports it was needed, such as BIND or Unbound, configured with a trust anchor for a DLV zone. This zone contained DLV records;[55] these had exactly the same format as DS records, but instead of referring to a delegated sub-zone, they referred to a zone elsewhere in the DNS tree. When the validator could not find a chain of trust from the root to the RRset it is trying to check, it searched for a DLV record that could provide an alternative chain of trust.[56]

Gaps in the chain of trust, such as unsigned top-level domains or registrars that did not support DNSSEC delegations, meant administrators of lower-level domains could use DLV to allow their DNS data to be validated by resolvers which had been configured to use DLV. This may have hindered DNSSEC deployment by taking pressure off registrars and TLD registries to properly support DNSSEC. DLV also added complexity by adding more actors and code paths for DNSSEC validation.

ISC decommissioned its DLV registry in 2017.[57] DLV support was deprecated in BIND 9.12 and completely removed from BIND 9.16.[58] Unbound version 1.5.4 (July 2015) marked DLV as decommissioned in the example configuration and manual page.[59] Knot Resolver and PowerDNS Recursor never implemented DLV.

In March 2020, the IETF published RFC 8749, retiring DLV as a standard and moving RFC 4432 and RFC 5074 to "Historic" status.[60]

The Science and Technology Directorate of the U.S. Department of Homeland Security (DHS) sponsors the "DNSSEC Deployment Initiative". This initiative encourages "all sectors to voluntarily adopt security measures that will improve security of the Internet's naming infrastructure, as part of a global, cooperative effort that involves many nations and organizations in the public and private sectors." DHS also funds efforts to mature DNSSEC and get it deployed inside the U.S. federal government.

It was reported[61] 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." However no U.S. Government officials were present in the meeting room and the comment that sparked the article was made by another party. DHS later commented[62][63] on why they believe others jumped to the false conclusion that the U.S. Government had made such a proposal: "The U.S. Department of Homeland Security is funding the development of a technical plan for implementing DNSSec, and last October distributed an initial draft of it to a long list of international experts for comments. 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."

The National Institute of Standards and Technology (NIST) published NIST Special Publication 800-81 Secure Domain Name System (DNS) Deployment Guide on May 16, 2006, with guidance on how to deploy DNSSEC. NIST intended to release new DNSSEC Federal Information Security Management Act (FISMA) requirements in NIST SP800-53-R1, referencing this deployment guide. U.S. agencies would then have had one year after final publication of NIST SP800-53-R1 to meet these new FISMA requirements.[64] However, at the time NSEC3 had not been completed. 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.

On 22 August 2008, the Office of Management and Budget (OMB) released a memorandum requiring U.S. Federal Agencies to deploy DNSSEC across .gov sites; the .gov root must be signed by January 2009, and all subdomains under .gov must be signed by December 2009.[65] 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."[66]

Several ISPs have started to deploy DNSSEC-validating DNS recursive resolvers. Comcast became the first major ISP to do so in the United States, announcing their intentions on October 18, 2010[67][68] and completing deployment on January 11, 2012.[69]

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.[70] About half of these clients were using Google's public DNS resolver.

In September 2015, Verisign announced their free public DNS resolver service,[71] 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%.[72]

Google's public recursive DNS server enabled DNSSEC validation on May 6, 2013.[73]

BIND, the most popular DNS management software, enables DNSSEC support by default since version 9.5.

The Quad9 public recursive DNS has performed DNSSEC validation on its main 9.9.9.9 address since it was established on May 11, 2016. Quad9 also provides an alternate service which does not perform DNSSEC validation, principally for debugging.[74]