The Domain Name System Security Extensions (DNSSEC) are a suite of extension specifications by the
Internet Engineering Task Force
The Internet Engineering Task Force (IETF) is a standards organization for the Internet and is responsible for the technical standards that make up the Internet protocol suite (TCP/IP). It has no formal membership roster or requirements and a ...
(IETF) for securing data exchanged in the
Domain Name System
The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned t ...
(DNS) in
Internet Protocol
The Internet Protocol (IP) is the network layer communications protocol in the Internet protocol suite for relaying datagrams across network boundaries. Its routing function enables internetworking, and essentially establishes the Internet.
...
(IP) networks. The protocol provides
cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.
Overview
The original design of the Domain Name System did not include any security features. It was conceived only as a scalable distributed system. The Domain Name System Security Extensions (DNSSEC) attempt to add security, while maintaining
backward compatibility
Backward compatibility (sometimes known as backwards compatibility) is a property of an operating system, product, or technology that allows for interoperability with an older legacy system, or with input designed for such a system, especiall ...
. Request for Comments 3833 documents some of the known threats to the DNS, and their solutions in DNSSEC.
DNSSEC was designed to protect applications using DNS from accepting forged or manipulated DNS data, such as that created by
DNS cache poisoning
DNS spoofing, also referred to as DNS cache poisoning, is a form of computer security hacking in which corrupt Domain Name System data is introduced into the DNS resolver's cache, causing the name server to return an incorrect result record, e.g ...
. All answers from DNSSEC protected zones are
digitally signed. By checking the digital signature, a DNS resolver is able to check if the information is identical (i.e. unmodified and complete) to the information published by the zone owner and served on an authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect any data published in the DNS, including text records (TXT) and mail exchange records (MX), and can be used to bootstrap other security systems that publish references to cryptographic certificates stored in the DNS such as Certificate Records (
CERT records, RFC 4398),
SSH
The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.
SSH applications are based on ...
fingerprints (
SSHFP, RFC 4255),
IPSec
In computing, Internet Protocol Security (IPsec) is a secure network protocol suite that authenticates and encrypts packets of data to provide secure encrypted communication between two computers over an Internet Protocol network. It is used in ...
public keys (IPSECKEY, RFC 4025),
TLS Trust Anchors (TLSA, RFC 6698), or Encrypted Client Hello (SVCB/HTTPS records for ECH, ).
DNSSEC ''does not'' provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted. DNSSEC ''does not'' protect against
DoS
DOS is shorthand for the MS-DOS and IBM PC DOS family of operating systems.
DOS may also refer to:
Computing
* Data over signalling (DoS), multiplexing data onto a signalling channel
* Denial-of-service attack (DoS), an attack on a communicat ...
attacks directly, though it indirectly provides some benefit (because signature checking allows the use of potentially untrustworthy parties).
Other standards (not DNSSEC) are used to secure bulk data (such as a
DNS zone transfer
DNS zone transfer, also sometimes known by the inducing DNS query type AXFR, is a type of DNS transaction. It is one of the many mechanisms available for administrators to replicate DNS databases across a set of DNS servers.
A zone transfer us ...
) sent between DNS servers. As documented in IETF RFC 4367, some users and developers make false assumptions about DNS names, such as assuming that a company's common name plus ".com" is always its domain name. DNSSEC cannot protect against false assumptions; it can only authenticate that the data is truly from or not available from the domain owner.
The DNSSEC specifications (called ''DNSSEC-bis'') describe the current DNSSEC protocol in great detail. See RFC 4033, RFC 4034, and RFC 4035. With the publication of these new RFCs (March 2005), an earlier RFC, RFC 2535 has become obsolete.
It is widely believed that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered () by several difficulties:
* The need to design a backward-compatible standard that can scale to the size of the Internet
* Prevention of "zone enumeration" where desired
* Deployment of DNSSEC implementations across a wide variety of DNS servers and resolvers (clients)
* Disagreement among implementers over who should own the
top-level domain
A top-level domain (TLD) is one of the domains at the highest level in the hierarchical Domain Name System of the Internet after the root domain. The top-level domain names are installed in the root zone of the name space. For all domains in ...
root keys
* Overcoming the perceived complexity of DNSSEC and DNSSEC deployment
Operation
DNSSEC works by
digitally signing records for DNS lookup using
public-key cryptography
Public-key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related keys. Each key pair consists of a public key and a corresponding private key. Key pairs are generated with cryptographic alg ...
. The correct DNSKEY record is authenticated via a
chain of trust
In computer security, a chain of trust is established by validating each component of hardware and software from the end entity up to the root certificate. It is intended to ensure that only trusted software and hardware can be used while still ...
, starting with a set of verified public keys for the
DNS root zone
The DNS root zone is the top-level DNS zone in the hierarchical namespace of the Domain Name System (DNS) of the Internet.
Before October 1, 2016, the root zone had been overseen by the Internet Corporation for Assigned Names and Numbers (ICANN ...
which is the
trusted third party
In cryptography, a trusted third party (TTP) is an entity which facilitates interactions between two parties who both trust the third party; the Third Party reviews all critical transaction communications between the parties, based on the ease of c ...
. Domain owners generate their own keys, and upload them using their DNS control panel at their domain-name registrar, which in turn pushes the keys via secDNS to the zone operator (e.g., Verisign for .com) who signs and publishes them in DNS.
Resource records
DNS is implemented by the use of several resource records. To implement DNSSEC, several new
DNS record types
This list of DNS record types is an overview of resource records (RRs) permissible in zone files of the Domain Name System
The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resou ...
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.
Algorithms
DNSSEC was designed to be extensible so that as attacks are discovered against existing algorithms, new ones can be introduced in a
backward-compatible
Backward compatibility (sometimes known as backwards compatibility) is a property of an operating system, product, or technology that allows for interoperability with an older legacy system, or with input designed for such a system, especially in ...
fashion. The following table defines, as of June 2019, the security algorithms that are most often used:
The lookup procedure
From the results of a DNS lookup, a security-aware
DNS resolver
The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned t ...
can determine whether the
authoritative name server
A name server refers to the server component of the Domain Name System (DNS), one of the two principal namespaces of the Internet. The most important function of DNS servers is the translation (resolution) of human-memorable domain names (example. ...
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
ISP
An Internet service provider (ISP) is an organization that provides services for accessing, using, or participating in the Internet. ISPs can be organized in various forms, such as commercial, community-owned, non-profit, or otherwise private ...
s, 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.
Recursive name servers
Using the
chain of trust
In computer security, a chain of trust is established by validating each component of hardware and software from the end entity up to the root certificate. It is intended to ensure that only trusted software and hardware can be used while still ...
model, a Delegation Signer (DS) record in a parent domain (
DNS zone
A DNS zone is a specific portion of the DNS namespace in the Domain Name System (DNS), which is managed by a specific organization or administrator. A DNS zone is an administrative space that allows for more granular control of the DNS componen ...
) 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
This list of DNS record types is an overview of resource records (RRs) permissible in zone files of the Domain Name System
The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other reso ...
and/or
AAAA record
This list of DNS record types is an overview of resource records (RRs) permissible in zone files of the Domain Name System
The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resour ...
s) of the domain "www.
example.com
The domain names example.com, example.net, example.org, and example.edu are second-level domain names in the Domain Name System of the Internet. They are reserved by the Internet Assigned Numbers Authority (IANA) at the direction of the Internet ...
".
# 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), all DNSSEC transactions must support EDNS. EDNS support is also needed to allow for the much larger packet sizes that DNSSEC transactions require.
# 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
A top-level domain (TLD) is one of the domains at the highest level in the hierarchical Domain Name System of the Internet after the root domain. The top-level domain names are installed in the root zone of the name space. For all domains in ...
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
In cryptography and computer security, a man-in-the-middle, monster-in-the-middle, machine-in-the-middle, monkey-in-the-middle, meddler-in-the-middle, manipulator-in-the-middle (MITM), person-in-the-middle (PITM) or adversary-in-the-middle (AiTM) ...
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. , deployment of DNSSEC to root is completed. The .com domain was signed with valid security keys and the secure delegation was added to the root zone on 1 April 2011.
Stub resolvers
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."
[
An earlier definition was given in an earlier RFC:
] 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."
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.
A ''validating stub resolver'' can also potentially perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages.
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
An Internet service provider (ISP) is an organization that provides services for accessing, using, or participating in the Internet. ISPs can be organized in various forms, such as commercial, community-owned, non-profit, or otherwise privat ...
or a
public recursive name server
A public recursive name server (also called public DNS resolver) is a name server service that networked computers may use to query the Domain Name System (DNS), the decentralized Internet naming system, in place of (or in addition to) name servers ...
, and the communication channels between itself and those name servers, using methods such as
DNS over TLS
DNS over TLS (DoT) is a network security protocol for encrypting and wrapping Domain Name System (DNS) queries and answers via the Transport Layer Security (TLS) protocol. The goal of the method is to increase user privacy and security by prevent ...
.
Trust anchors and authentication chains
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
An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs.
Time-sharing operating systems schedule tasks for efficient use of the system and may also i ...
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.
An ''
authentication
Authentication (from ''authentikos'', "real, genuine", from αὐθέντης ''authentes'', "author") is the act of proving an assertion, such as the identity of a computer system user. In contrast with identification, the act of indicatin ...
chain'' is a series of linked DS and DNSKEY records, starting with a
trust anchor
In cryptographic systems with hierarchical structure, a trust anchor is an authoritative entity for which trust is assumed and not derived.
In the X.509 architecture, a root certificate would be the trust anchor from which the whole chain of trus ...
to the
authoritative name server
A name server refers to the server component of the Domain Name System (DNS), one of the two principal namespaces of the Internet. The most important function of DNS servers is the translation (resolution) of human-memorable domain names (example. ...
for the domain in question. Without a complete authentication chain, an answer to a DNS lookup cannot be securely authenticated.
Signatures and zone signing
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.
Key management
DNSSEC involves many different keys, stored both in DNSKEY records, and from other sources to form
trust anchor
In cryptographic systems with hierarchical structure, a trust anchor is an authoritative entity for which trust is assumed and not derived.
In the X.509 architecture, a root certificate would be the trust anchor from which the whole chain of trus ...
s.
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
Time to live (TTL) or hop limit is a mechanism which limits the lifespan or lifetime of data in a computer or network. TTL may be implemented as a counter or timestamp attached to or embedded in the data. Once the prescribed event count or times ...
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
A DNS zone is a specific portion of the DNS namespace in the Domain Name System (DNS), which is managed by a specific organization or administrator. A DNS zone is an administrative space that allows for more granular control of the DNS componen ...
, 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
A cryptographic hash function (CHF) is a hash algorithm (a map of an arbitrary binary string to a binary string with fixed size of n bits) that has special properties desirable for cryptography:
* the probability of a particular n-bit output ...
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
The domain name .com is a top-level domain (TLD) in the Domain Name System (DNS) of the Internet. Added at the beginning of 1985, its name is derived from the word ''commercial'', indicating its original intended purpose for domains registere ...
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.
DANE Working Group
DNS-based Authentication of Named Entities
DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DN ...
(DANE) is an IETF working group with the goal of developing protocols and techniques that allow Internet applications to establish cryptographically secured communications with
TLS,
DTLS
Datagram Transport Layer Security (DTLS) is a communications protocol providing security to datagram-based applications by allowing them to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol i ...
,
SMTP
The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients ty ...
, and
S/MIME S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly . It was originally developed by R ...
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, but was later removed. For
Mozilla Firefox, support was provided by an add-on while native support is currently awaiting someone to start working on it.
History
DNS is a critical and fundamental Internet service, yet in 1990
Steve Bellovin
Steven M. Bellovin is a researcher on computer networking and security. He has been a professor in the Computer Science department at Columbia University since 2005. Previously, Bellovin was a Fellow at AT&T Labs Research in Florham Park, New Jer ...
discovered serious security flaws in it. Research into securing it began, and progressed dramatically when his paper was made public in 1995. The initial RFC 2065 was published by the IETF in 1997, and initial attempts to implement that specification led to a revised (and believed fully workable) specification in 1999 as IETF RFC 2535. Plans were made to deploy DNSSEC based on RFC 2535.
Unfortunately, the IETF RFC 2535 specification had very significant problems scaling up to the full Internet; by 2001 it became clear that this specification was unusable for large networks. In normal operation DNS servers often get out of sync with their parents. This isn't usually a problem, but when DNSSEC is enabled, this out-of-sync data could have the effect of a serious self-created denial of service. The original DNSSEC required a complex six-message protocol and a lot of data transfers to perform key changes for a child (DNS child zones had to send all of their data up to the parent, have the parent sign each record, and then send those signatures back to the child for the child to store in a SIG record). Also, public key changes could have absurd effects; for example, if the ".com" zone changed its public key, it would have to send 22 million records (because it would need to update all of the signatures in all of its children). Thus, DNSSEC as defined in RFC 2535 could not scale up to the Internet.
The IETF fundamentally modified DNSSEC, which is called ''DNSSEC-bis'' when necessary to distinguish it from the original DNSSEC approach of RFC 2535. This new version uses "delegation signer (DS) resource records" to provide an additional level of indirection at delegation points between a parent and child zone. In the new approach, when a child's master public key changes, instead of having six messages for every record in the child, there is one simple message: the child sends the new public key to its parent (signed, of course). Parents simply store one master public key for each child; this is much more practical. This means that a little data is pushed to the parent, instead of massive amounts of data being exchanged between the parent and children. This does mean that clients have to do a little more work when verifying keys. More specifically, verifying a DNS zone's KEY RRset requires two signature verification operations instead of the one required by RFC 2535 (there is no impact on the number of signatures verified for other types of RRsets). Most view this as a small price to pay, since it makes DNSSEC deployment more practical.
Authenticating NXDOMAIN responses and NSEC
Cryptographically proving the absence of a domain requires signing the response to every query for a non-existent domain. This is not a problem for online signing servers, which keep their keys available online. However, DNSSEC was designed around using offline computers to sign records so that zone-signing-keys could be kept in cold storage. This represents a problem when trying to authenticate responses to queries for non-existent domains since it is impossible to pre-generate a response to every possible hostname query.
The initial solution was to create NSEC records for every pair of domains in a zone. Thus if a client queried for a record at the non-existent
k.example.com
, the server would respond with an NSEC record stating that nothing exists between
a.example.com
and
z.example.com
. However, this leaks more information about the zone than traditional unauthenticated NXDOMAIN errors because it exposes the existence of real domains.
Preventing domain walking
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.
NSEC5has 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.
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.
CloudFlare pioneered a pair of alternative approaches, which manage to achieve the same result in one third of the response size.
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. The second approach instead chooses to prove that "the record exists but the requested record type does not", which they call "DNS shotgun".
Deployment
The Internet is critical infrastructure, yet its operation depends on the fundamentally insecure DNS.
Thus, there is strong incentive to secure DNS, and deploying DNSSEC is generally considered to be a critical part of that effort.
For example, the U.S. ''National Strategy to Secure Cyberspace'' specifically identified the need to secure DNS.
Wide-scale deployment of DNSSEC could resolve many other security problems as well, such as secure key distribution for e-mail addresses.
DNSSEC deployment in large-scale networks is also challenging. Ozment and Schechter observe that DNSSEC (and other technologies) has a "bootstrap problem": users typically only deploy a technology if they receive an immediate benefit, but if a minimal level of deployment is required before ''any'' users receive a benefit greater than their costs (as is true for DNSSEC), it is difficult to deploy. DNSSEC can be deployed at any level of a DNS hierarchy, but it must be widely available in a zone before many others will want to adopt it. DNS servers must be updated with software that supports DNSSEC, and DNSSEC data must be created and added to the DNS zone data. A TCP/IP-using client must have their DNS resolver (client) updated before it can use DNSSEC's capabilities. What is more, any resolver must have, or have a way to acquire, at least one public key that it can trust before it can start using DNSSEC.
DNSSEC implementation can add significant load to some DNS servers. Common DNSSEC-signed responses are far larger than the default UDP size of 512 bytes. In theory, this can be handled through multiple IP fragments, but many "middleboxes" in the field do not handle these correctly. This leads to the use of TCP instead. Yet many current TCP implementations store a great deal of data for each TCP connection; heavily loaded servers can run out of resources simply trying to respond to a larger number of (possibly bogus) DNSSEC requests. Some protocol extensions, such as
TCP Cookie Transactions, have been developed to reduce this loading. To address these challenges, significant effort is ongoing to deploy DNSSEC, because the Internet is so vital to so many organizations.
Early deployments
Early adopters include
Brazil
Brazil ( pt, Brasil; ), officially the Federative Republic of Brazil (Portuguese: ), is the largest country in both South America and Latin America. At and with over 217 million people, Brazil is the world's fifth-largest country by area ...
(
.br
.br is the Internet country code top-level domain (ccTLD) for Brazil. It was administered by the Brazilian Internet Steering Committee until 2005 when it started being administered by Brazilian Network Information Center. A local contact is r ...
),
Bulgaria
Bulgaria (; bg, България, Bǎlgariya), officially the Republic of Bulgaria,, ) is a country in Southeast Europe. It is situated on the eastern flank of the Balkans, and is bordered by Romania to the north, Serbia and North Macedo ...
(
.bg
.bg is the country code top-level domain (ccTLD) in the Domain Name System of the Internet for Bulgaria. It is currently operated by Register.BG.
.bg domains can be registered by European Union citizens, companies or foreign companies that have ...
),
Czech Republic
The Czech Republic, or simply Czechia, is a landlocked country in Central Europe. Historically known as Bohemia, it is bordered by Austria to the south, Germany to the west, Poland to the northeast, and Slovakia to the southeast. The ...
(
.cz
.cz is the country code top-level domain (ccTLD) for the Czech Republic. It is administered by CZ.NIC. Registrations must be ordered via accredited domain name registrars.
Until Czechoslovakia was dissolved in 1993, it used the domain '' .cs''. ...
),
Namibia
Namibia (, ), officially the Republic of Namibia, is a country in Southern Africa. Its western border is the Atlantic Ocean. It shares land borders with Zambia and Angola to the north, Botswana to the east and South Africa to the south and ea ...
(
.na
.na is the Internet country code top-level domain (ccTLD) for Namibia corresponding to the two letter code from the ISO-3166 standard.
The registry accredits both Namibian and foreign registrars. Registrars access the Registry and register domai ...
)
Puerto Rico
Puerto Rico (; abbreviated PR; tnq, Boriken, ''Borinquen''), officially the Commonwealth of Puerto Rico ( es, link=yes, Estado Libre Asociado de Puerto Rico, lit=Free Associated State of Puerto Rico), is a Caribbean island and unincorporated ...
(
.pr
.pr is the Internet country code top-level domain (ccTLD) for Puerto Rico.
A .pr.us second-level domain has been reserved for Puerto Rico under the .us locality namespace, but it is unused. Agencies of the government of Puerto Rico use either ...
) and
Sweden (
.se
.se, formerly branded as .SE, is the Internet country code top-level domain ( ccTLD) for Sweden
Sweden, formally the Kingdom of Sweden,The United Nations Group of Experts on Geographical Names states that the country's formal name is ...
), who use DNSSEC for their
country code top-level domain
A country code top-level domain (ccTLD) is an Internet top-level domain generally used or reserved for a country, sovereign state, or dependent territory identified with a country code. All ASCII ccTLD identifiers are two letters long, and all ...
s;
[Electronic Privacy Information Center (EPIC) (May 27, 2008)]
DNSSEC
!--access-date=2008-06-13--> RIPE NCC
RIPE NCC (''Réseaux IP Européens'' Network Coordination Centre) is the regional Internet registry (RIR) for Europe, the Middle East and parts of Central Asia. Its headquarters are in Amsterdam, Netherlands, with a branch office in Dubai, UAE.
...
, who have signed all the reverse lookup records (in-addr.arpa) that are delegated to it from the
Internet Assigned Numbers Authority
The Internet Assigned Numbers Authority (IANA) is a standards organization that oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System (DNS), media types, and other Inte ...
(IANA).
ARIN is also signing their reverse zones. In February 2007,
TDC became the first Swedish ISP to start offering this feature to its customers.
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, the
Internet Systems Consortium introduced another on March 27 of the same year, while
ICANN themselves announced a third on February 17, 2009.
On June 2, 2009,
Afilias
Afilias, Inc. is a US corporation that is the registry operator of the .info, .mobi and .pro top-level domain, service provider for registry operators of .org, .ngo, .lgbt, .asia, .aero, and a provider of domain name registry services for countri ...
, the registry service provider for
Public Interest Registry
Public Interest Registry is a not-for-profit based in Reston, Virginia, created by the Internet Society in 2002 to manage the .ORG top-level domain. It took over operation of .ORG in January 2003 and launched the .NGO and .ONG top-level domains in ...
's .org zone signed the .org TLD. 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". On June 23, 2010, 13 registrars were listed as offering DNSSEC records for .ORG domains.
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, 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. This goal was achieved on-schedule and Verisign's DNSSEC VP, Matt Larson, won InfoWorld's Technology Leadership Award for 2011 for his role in advancing DNSSEC.
Deployment at the DNS root
DNSSEC was first deployed at the root level on July 15, 2010.
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.
Planning
In September 2008, ICANN and VeriSign each published implementation proposals and in October, the
National Telecommunications and Information Administration (NTIA) asked the public for comments. 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
The National Institute of Standards and Technology (NIST) is an agency of the United States Department of Commerce whose mission is to promote American innovation and industrial competitiveness. NIST's activities are organized into physical s ...
(NIST) announced plans to sign the root by the end of 2009, in conjunction with ICANN,
VeriSign
Verisign Inc. is an American company based in Reston, Virginia, United States that operates a diverse array of network infrastructure, including two of the Internet's thirteen root nameservers, the authoritative registry for the , , and gene ...
and the NTIA.
On October 6, 2009, at the 59th
RIPE
Réseaux IP Européens (RIPE, French for "European IP Networks") is a forum open to all parties with an interest in the technical development of the Internet. The RIPE community's objective is to ensure that the administrative and technical coor ...
Conference meeting, ICANN and VeriSign announced the planned deployment timeline for deploying DNSSEC within the root zone.
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.
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.
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
The domain name .org is a generic top-level domain (gTLD) of the Domain Name System (DNS) used on the Internet. The name is truncated from ''organization''. It was one of the original domains established in 1985, and has been operated by th ...
top-level domain has been signed with DNSSEC in June 2010, followed by
.com
The domain name .com is a top-level domain (TLD) in the Domain Name System (DNS) of the Internet. Added at the beginning of 1985, its name is derived from the word ''commercial'', indicating its original intended purpose for domains registere ...
,
.net, and
.edu
The domain name .edu is a sponsored top-level domain (sTLD) in the Domain Name System of the Internet. The domain was implemented in 1985 for the purpose of creating a domain name hierarchy for organizations with a focus on education, even abl ...
later in 2010 and 2011.
Country code top-level domain
A country code top-level domain (ccTLD) is an Internet top-level domain generally used or reserved for a country, sovereign state, or dependent territory identified with a country code. All ASCII ccTLD identifiers are two letters long, and all ...
s were able to deposit keys starting in May 2010.
[More security for root DNS servers](_blank)
Heise Online, 24 March 2010 more than 25% of top-level domains are signed with DNSSEC.
Implementation
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-2 (Secure Hash Algorithm 2) is a set of cryptographic hash functions designed by the United States National Security Agency (NSA) and first published in 2001. They are built using the Merkle–Damgård construction, from a one-way compression ...
(SHA-256) hash created using the
RSA algorithm, as defined in RFC 5702. As of May 2010, all thirteen root servers have begun serving the DURZ.
On July 15, 2010, the first root full production DNSSEC root zone was signed, with the SOA serial 2010071501. Root trust anchors ar
available from IANA
Deployment at the TLD level
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
This list of Internet top-level domains (TLD) contains top-level domains, which are those domains in the DNS root zone of the Domain Name System of the Internet. A list of the top-level domains by the Internet Assigned Numbers Authority (IANA) ...
provides details about which of the existing top-level domains have been signed and linked to the root.
DNSSEC Lookaside Validation - historical
In March 2006, the
Internet Systems Consortium introduced the DNSSEC Lookaside Validation registry. 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. 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
BIND () is a suite of software for interacting with the Domain Name System (DNS). Its most prominent component, named (pronounced ''name-dee'': , short for ''name daemon''), performs both of the main DNS server roles, acting as an authoritative ...
or
Unbound, configured with a trust anchor for a DLV zone. This zone contained DLV records; 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.
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. DLV support was deprecated in BIND 9.12 and completely removed from BIND 9.16. Unbound version 1.5.4 (July 2015) marked DLV as decommissioned in the example configuration and manual page. Knot Resolver and PowerDNS Recursor never implemented DLV.
In March 2020, the
IETF
The Internet Engineering Task Force (IETF) is a standards organization for the Internet and is responsible for the technical standards that make up the Internet protocol suite (TCP/IP). It has no formal membership roster or requirements and a ...
published RFC 8749, retiring DLV as a standard and moving RFC 4432 and RFC 5074 to "Historic" status.
DNSSEC deployment initiative by the U.S. federal government
The Science and Technology Directorate of the
U.S. Department of Homeland Security
The United States Department of Homeland Security (DHS) is the U.S. federal executive department responsible for public security, roughly comparable to the interior or home ministries of other countries. Its stated missions involve anti-terr ...
(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 that on March 30, 2007, the
U.S. Department of Homeland Security
The United States Department of Homeland Security (DHS) is the U.S. federal executive department responsible for public security, roughly comparable to the interior or home ministries of other countries. Its stated missions involve anti-terr ...
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 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."
DNSSEC deployment in the U.S. federal government
The
National Institute of Standards and Technology
The National Institute of Standards and Technology (NIST) is an agency of the United States Department of Commerce whose mission is to promote American innovation and industrial competitiveness. NIST's activities are organized into physical s ...
(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. 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. 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."
Deployment in resolvers
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 and completing deployment on January 11, 2012.
According to a study at
APNIC
APNIC (the Asia Pacific Network Information Centre) is the regional Internet address registry ( RIR) for the Asia-Pacific region. It is one of the world's five RIRs and is part of the Number Resource Organization ( NRO).
APNIC provides numb ...
, the proportion of clients who exclusively use DNS resolvers that perform DNSSEC validation rose to 8.3% in May 2013.
[Geoff Huston: DNS, DNSSEC and Google's Public DNS Service (CircleID)](_blank)
/ref> About half of these clients were using Google's public DNS resolver.
In September 2015, Verisign announced their free public DNS resolver service,[Introducing Verisign Public DNS](_blank)
/ref> 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%.[Use of DNSSEC Validation for World (XA)](_blank)
/ref>
DNSSEC support
Google's public recursive DNS server enabled DNSSEC validation on May 6, 2013.
BIND
BIND () is a suite of software for interacting with the Domain Name System (DNS). Its most prominent component, named (pronounced ''name-dee'': , short for ''name daemon''), performs both of the main DNS server roles, acting as an authoritative ...
, 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.
IETF publications
* Domain Name System Security Extensions
* Indicating Resolver Support of DNSSEC
* DNSSEC and IPv6 A6 Aware Server/Resolver Message Size Requirements
* A Threat Analysis of the Domain Name System
* DNS Security Introduction and Requirements (''DNSSEC-bis'')
* Resource Records for the DNS Security Extensions (''DNSSEC-bis'')
* Protocol Modifications for the DNS Security Extensions (''DNSSEC-bis'')
* Storing Certificates in the Domain Name System (DNS)
* The DNSSEC Lookaside Validation (DLV) DNS Resource Record
* Minimally Covering NSEC Records and DNSSEC On-line Signing
* Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
* DNSSEC Operational Practices
* DNS Security (DNSSEC) Experiments
* Automated Updates of DNS Security (DNSSEC) Trust Anchors
* DNSSEC Hashed Authenticated Denial of Existence
* Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
* Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
* DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates
* DNSSEC Operational Practices, Version 2
* Clarifications and Implementation Notes for DNS Security (DNSSEC)
* Authenticated Denial of Existence in the DNS
* Automating DNSSEC Delegation Trust Maintenance
* DNSSEC Key Rollover Timing Considerations
* Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC
* Algorithm Implementation Requirements and Usage Guidance for DNSSEC
* Moving DNSSEC Lookaside Validation (DLV) to Historic Status
* Guidance for NSEC3 Parameter Settings
Tools
DNSSEC deployment requires software on the server and client side. Some of the tools that support DNSSEC include:
* Windows 7
Windows 7 is a major release of the Windows NT operating system developed by Microsoft. It was released to manufacturing on July 22, 2009, and became generally available on October 22, 2009. It is the successor to Windows Vista, released nearly ...
and Windows Server 2008 R2
Windows Server 2008 R2 is the fifth version of the Windows Server operating system produced by Microsoft and released as part of the Windows NT family of operating systems. It was released to manufacturing on July 22, 2009, and became generall ...
include a "security-aware" stub resolver that is able to differentiate between secure and non-secure responses by a recursive name server. Windows Server 2012 DNSSEC is compatible with secure dynamic updates with Active Directory-integrated zones, plus Active Directory replication of anchor keys to other such servers.DNSSEC in Windows Server
/ref>
* BIND
BIND () is a suite of software for interacting with the Domain Name System (DNS). Its most prominent component, named (pronounced ''name-dee'': , short for ''name daemon''), performs both of the main DNS server roles, acting as an authoritative ...
, the most popular DNS name server (which includes dig), incorporates the newer ''DNSSEC-bis'' (DS records) protocol as well as support for NSEC3 records.
* Unbound is a DNS name server that was written from the ground up to be designed around DNSSEC concepts.
* mysqlBind The GPL DNS management software for DNS ASPs now supports DNSSEC.
* OpenDNSSEC
OpenDNSSEC is a computer program that manages the security of domain names on the Internet. The project intends to drive adoption of Domain Name System Security Extensions (DNSSEC) to further enhance Internet security.
OpenDNSSEC was created as ...
is a designated DNSSEC signer tool using PKCS#11 to interface with hardware security module
A hardware security module (HSM) is a physical computing device that safeguards and manages secrets (most importantly digital keys), performs encryption and decryption functions for digital signatures, strong authentication and other cryptogr ...
s.
* Knot DNS
Knot DNS is an open-source authoritative-only server for the Domain Name System. It was created from scratch and is actively developed by CZ.NIC, the .CZ domain registry. The purpose of this project is to supply an alternative open-source impl ...
has added support for automatic DNSSEC signing in version 1.4.0.
* PowerDNS
PowerDNS is a DNS server program, written in C++ and licensed under the GPL. It runs on most Unix derivatives. PowerDNS features a large number of different ''backends'' ranging from simple BIND style zonefiles to relational databases and lo ...
fully supports DNSSEC as of version 3.0 in pre-signed and live-signed modes.
* DNSSEC
The Domain Name System Security Extensions (DNSSEC) are 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. The protoc ...
What is it and why is it important to implement it for a long time?
Check itInitiative of the Internet community and the Dutch government
See also
*DNSCrypt
DNSCrypt is a network protocol that authenticates and encrypts Domain Name System (DNS) traffic between the user's computer and recursive name servers. It was originally designed by Frank Denis and Yecheng Fu.
Although multiple free and open s ...
*DNSCurve
DNSCurve is a proposed secure protocol for the Domain Name System (DNS), designed by Daniel J. Bernstein.
Description
DNSCurve uses Curve25519 elliptic curve cryptography to establish keys used by Salsa20, paired with the message authentication ...
* Extension Mechanisms for DNS (EDNS)
*TSIG TSIG (transaction signature) is a computer-networking protocol defined
in RFC 2845. Primarily it enables the Domain Name System (DNS) to authenticate updates to a DNS database. It is most commonly used to update Dynamic DNS or a secondary/slave D ...
* Resource Public Key Infrastructure (RPKI)
References
Further reading
*
External links
DNSSEC
- DNSSEC information site: DNSSEC.net
DNS Extensions IETF Working Group
The Internet Engineering Task Force (IETF) is a standards organization for the Internet and is responsible for the technical standards that make up the Internet protocol suite (TCP/IP). It has no formal membership roster or requirements and a ...
DNSSEC-Tools Project
{{Authority control
Internet Standards
Domain Name System
Domain name system extensions
Public-key cryptography
Key management
sv:DNS#DNSSEC