DNSSEC
Encyclopedia
The Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force
(IETF) specifications for securing certain kinds of information provided by the Domain Name System
(DNS) as used on Internet Protocol
(IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.
(DNS) did not include security; instead it was designed to be a scalable distributed system. The Domain Name System Security Extensions (DNSSEC) attempts to add security, while maintaining backwards compatibility. RFC 3833 attempts to document some of the known threats to the DNS and how DNSSEC responds to those threats.
DNSSEC was designed to protect Internet resolvers (clients) from forged DNS data, such as that created by DNS cache poisoning
. All answers in DNSSEC are digitally signed
. By checking the digital signature, a DNS resolver is able to check if the information is identical (correct and complete) to the information on the authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect other information such as general-purpose cryptographic certificates stored in CERT records in the DNS. RFC 4398 describes how to distribute these certificates, including those for email, making it possible to use DNSSEC as a worldwide public key infrastructure for email.
DNSSEC does not provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted. DNSSEC does not protect against DoS 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
) 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:
Some of these problems are in the process of being resolved, and deployment in various domains is in progress.
these records for DNS lookup using public-key cryptography
. The correct DNSKEY record is authenticated via a chain of trust
, starting with a set of verified public keys for the DNS root zone
which is the trusted third party
.
When DNSSEC is used, each answer to a DNS lookup will contain 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 can be verified by locating the correct public key found in a DNSKEY record. 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.
s, and for stub resolvers such as those included by default in mainstream operating systems.
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
".
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. , 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.
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." Note that this means you have to trust the recursive name server (which is usually controlled by your Internet Service Provider
) to not perform a man-in-the-middle attack
to falsely set the AD bit on a forged result.
A 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 up to the DNSSEC root; the DNSSEC root certificate
must be locally available for this to work. Using such a validating stub resolver gives you end-to-end DNS security for domains implementing DNSSEC, even if you do not trust your Internet Service Provider. The BSD-licensed
Unbound
program is an example of a validating stub resolver. The DNS client found in Windows 7 will not perform validation on its own, though it may be regarded as a “non-validating security-aware stub-resolver”; its behaviour – for example should it set the DO bit or should it require IPSec connection to the DNS server – can be controlled by group policies
.
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 15th July 2010.
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.
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.
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
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. Second, there are 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, but 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.
, TLS
, DTLS) 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,
Mozilla Firefox
's support is underway.
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 to have 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 changes DNSSEC so it is more practical to deploy.
queries; this would reveal registrant data which many registries are under strict legal obligations to protect under various contracts.
It is unclear whether DNSSEC is legal to deploy at all in many countries, unless such lists can be kept private. DENIC
has stated that DNSSEC's zone enumeration issue violates Germany's Federal Data Protection Act, and other European countries have similar privacy laws forbidding the public release of certain kinds of information.
There is an "obvious" solution, called a split-horizon DNS
, which is how DNS without DNSSEC is sometimes deployed — but this approach does not work well with DNSSEC. In the "split-horizon DNS" approach, the DNS server denies the existence of names to some clients, and provides correct information to other clients. However, since DNSSEC information is cryptographically signed as authoritative, an attacker could request the signed "does not exist" record, then retransmit the record to cause a denial of service. DNSSEC fundamentally changes DNS so it can provide authoritative information; thus, it does not work well with methods based on providing false information to some users. Research has produced recommendations to properly combine these two DNS features.
DNSSEC introduced this problem because it must be able to report when a name is not found. DNS servers supporting DNSSEC must be able to sign that not-found report — otherwise a not-found report could be easily spoofed. Yet for security reasons the signing key should not be online. As a result, DNSSEC was designed to report a signed message that reports that a given range of names does not exist, which can be signed ahead-of-time offline. Unfortunately, this information is enough for an attacker to gain much more information than would have been available to them otherwise — it is enough to enable an attacker to quickly gather all the names in a zone, and then through targeted queries on the names to reconstruct all or most of a zone's data.
As noted earlier, DNSSEC could be used as the basis for a worldwide public key infrastructure
for email addresses, by using DNS to serve email certificates and DNSSEC to validate them. However, this DNSSEC issue makes this unlikely for most organizations, at least if used directly. As RFC 4398 states, "If an organization chooses to issue certificates for its employees, placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC) is in use, it is possible for someone to enumerate all employees of the organization. This is usually not considered desirable, for the same reason that enterprise phone listings are not often publicly published and are even marked confidential."
This approach has some disadvantages. It requires a signing key to be kept on-line and accessible to each DNS server. Many zone signing keys are kept on-line anyway to support automatic resigning or dynamic zone updates, but these functions are needed only on a single master DNS server, while to support on-line signing the zone signing key must be kept on each authoritative DNS server. Some authoritative servers must be accessible from the Internet and ideally these will be widely dispersed, making it difficult to keep the keys under control. Care is also required to prevent an attacker flooding the DNS server with requests for bogus names, denying service to legitimate users.
In March 2008, NSEC3 was formally defined in RFC 5155.
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.
Widescale deployment of DNSSEC could resolve many other security problems as well, such as secure key distribution for e-mail addresses.
However, the DNSSEC specification has been challenging to develop. NSEC3, one of its critical pieces, was only formally defined in an RFC in March 2008, and it is not yet widely deployed.
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.
(.br
), Bulgaria
(.bg
), Czech Republic
(.cz
), Puerto Rico
(.pr
) and Sweden
(.se
), who use DNSSEC for their country code top-level domain
s; RIPE NCC
, who have signed all the reverse (in-addr.arpa) that are delegated to it from the Internet Assigned Numbers Authority
(IANA). ARIN
is also signing their reverse zones. TDC was the first ISP to implement this feature in Sweden.
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..
A wide variety of pilot projects and experiments are and have been performed. dnssec.net maintains a list of such projects. There is also a Google Map of World Wide DNSSEC Deployment.
On June 2, 2009, the Public Interest Registry
signed the .org zone. The Public Internet Registry also detailed on September 26, 2008, that the first phase, involving large registrars it has a strong working relationship with ("friends and family") will 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.
Political issues surrounding signing the root have been a continuous concern, primarily about some central issues:
(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
(NIST) announced plans to sign the root by the end of 2009, in conjunction with ICANN, VeriSign
and the NTIA.
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. 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
top-level domain has been signed with DNSSEC in June 2010, followed by .com
, .net
, and .edu
later in 2010 and 2011. Country code top-level domain
s will be able to deposit keys starting in May 2010.
(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 are available from IANA.
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 maintains a central list of trust anchors, instead of each validator repeating the work of maintaining its own list.
To use DLV, you need a validator that supports it, such as BIND
or Unbound
, configured with a trust anchor for a DLV zone. This zone contains DLV records; these have exactly the same format as DS records, but instead of referring to a delegated sub-zone, they refer to a zone elsewhere in the DNS tree. When the validator cannot find a chain of trust from the root to the RRset it is trying to check, it searches for a DLV record that can provide an alternative chain of trust.
DLV continues to be useful after the root has been signed. While there are gaps in the chain of trust, such as unsigned top-level domains, or registrars that do not support DNSSEC delegations, hostmasters of lower-level domains can use DLV to make it easier for their users to validate their DNS data.
(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
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."
(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."
Internet Engineering Task Force
The Internet Engineering Task Force develops and promotes Internet standards, cooperating closely with the W3C and ISO/IEC standards bodies and dealing in particular with standards of the TCP/IP and Internet protocol suite...
(IETF) specifications for securing certain kinds of information provided by the Domain Name System
Domain name system
The Domain Name System is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities...
(DNS) as used on Internet Protocol
Internet Protocol
The Internet Protocol is the principal communications protocol used for relaying datagrams across an internetwork using the Internet Protocol Suite...
(IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.
Overview
The original design of the Domain Name SystemDomain name system
The Domain Name System is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities...
(DNS) did not include security; instead it was designed to be a scalable distributed system. The Domain Name System Security Extensions (DNSSEC) attempts to add security, while maintaining backwards compatibility. RFC 3833 attempts to document some of the known threats to the DNS and how DNSSEC responds to those threats.
DNSSEC was designed to protect Internet resolvers (clients) from forged DNS data, such as that created by DNS cache poisoning
DNS cache poisoning
DNS cache poisoning is a security or data integrity compromise in the Domain Name System . The compromise occurs when data is introduced into a DNS name server's cache database that did not originate from authoritative DNS sources. It may be a deliberate attempt of a maliciously crafted attack on a...
. All answers in DNSSEC are digitally signed
Digital signature
A digital signature or digital signature scheme is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, and that it was not altered in transit...
. By checking the digital signature, a DNS resolver is able to check if the information is identical (correct and complete) to the information on the authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect other information such as general-purpose cryptographic certificates stored in CERT records in the DNS. RFC 4398 describes how to distribute these certificates, including those for email, making it possible to use DNSSEC as a worldwide public key infrastructure for email.
DNSSEC does not provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted. DNSSEC does not protect against DoS 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
DNS zone transfer, also sometimes known by its opcode mnemonic AXFR, is a type of DNS transaction. It is one of the many mechanisms available for administrators to employ for replicating the databases containing the DNS data across a set of DNS servers. Zone transfer comes in two flavors, full ...
) 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" (see below) 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 domainTop-level domainA top-level domain is one of the domains at the highest level in the hierarchical Domain Name System of the Internet. The top-level domain names are installed in the root zone of the name space. For all domains in lower levels, it is the last part of the domain name, that is, the last label of a...
root keys - Overcoming the perceived complexity of DNSSEC and DNSSEC deployment
Some of these problems are in the process of being resolved, and deployment in various domains is in progress.
How it works
DNSSEC works by digitally signingDigital signature
A digital signature or digital signature scheme is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, and that it was not altered in transit...
these records for DNS lookup using public-key cryptography
Public-key cryptography
Public-key cryptography refers to a cryptographic system requiring two separate keys, one to lock or encrypt the plaintext, and one to unlock or decrypt the cyphertext. Neither key will do both functions. One of these keys is published or public and the other is kept private...
. The correct DNSKEY record is authenticated via a chain of trust
Chain of trust
In computer security, a chain of trust is established by validating each component of hardware and software from the bottom up. It is intended to ensure that only trusted software and hardware can be used while still remaining flexible.-Introduction:...
, starting with a set of verified public keys for the DNS root zone
DNS root zone
A DNS root zone is the top-level DNS zone in a Domain Name System hierarchy. Most commonly it refers to the root zone of the largest global DNS, deployed for the Internet. Ultimate authority over the DNS root zone rests with the US Department of Commerce NTIA...
which is the trusted third party
Trusted third party
In cryptography, a trusted third party 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 creating fraudulent digital content. In TTP models, the...
.
Records
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
- DNSKEY
- DS
- NSEC
- NSEC3
- NSEC3PARAM
When DNSSEC is used, each answer to a DNS lookup will contain 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 can be verified by locating the correct public key found in a DNSKEY record. 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 fashion. As of this writing (July 2009), the following security algorithms are defined that are most often used:| Algorithm field | Algorithm | Source |
|---|---|---|
| 0 | Reserved | RFC 4034 |
| 1 | RSA/MD5 MD5 The MD5 Message-Digest Algorithm is a widely used cryptographic hash function that produces a 128-bit hash value. Specified in RFC 1321, MD5 has been employed in a wide variety of security applications, and is also commonly used to check data integrity... |
|
| 3 | DSA Digital Signature Algorithm The Digital Signature Algorithm is a United States Federal Government standard or FIPS for digital signatures. It was proposed by the National Institute of Standards and Technology in August 1991 for use in their Digital Signature Standard , specified in FIPS 186, adopted in 1993. A minor... /SHA-1 |
|
| 5 | RSA/SHA-1 | |
| 7 | RSASHA1-NSEC3-SHA1 | RFC 5155 |
| 8 | RSA/SHA-256 SHA-2 In cryptography, SHA-2 is a set of cryptographic hash functions designed by the National Security Agency and published in 2001 by the NIST as a U.S. Federal Information Processing Standard. SHA stands for Secure Hash Algorithm. SHA-2 includes a significant number of changes from its predecessor,... |
RFC 5702 |
| 10 | RSA/SHA-512 SHA-2 In cryptography, SHA-2 is a set of cryptographic hash functions designed by the National Security Agency and published in 2001 by the NIST as a U.S. Federal Information Processing Standard. SHA stands for Secure Hash Algorithm. SHA-2 includes a significant number of changes from its predecessor,... |
|
| 12 | GOST GOST GOST refers to a set of technical standards maintained by the Euro-Asian Council for Standardization, Metrology and Certification , a regional standards organization operating under the auspices of the Commonwealth of Independent States .All sorts of regulated standards are included, with examples... R 34.10-2001 |
RFC 5933 |
The lookup procedure
From the results of a DNS lookup, a security-aware DNS resolver can determine if the answer it received was secure, or if it was otherwise insecure and the authoritative name server for the domain being queried doesn't support DNSSEC or if there is some sort of error. The lookup procedure is different for recursive name servers such as those of many ISPInternet service provider
An Internet service provider is a company that provides access to the Internet. Access ISPs directly connect customers to the Internet using copper wires, wireless or fiber-optic connections. Hosting ISPs lease server space for smaller businesses and host other people servers...
s, and for stub resolvers such as those included by default in mainstream operating systems.
Recursive name servers
Using the chain of trustChain of trust
In computer security, a chain of trust is established by validating each component of hardware and software from the bottom up. It is intended to ensure that only trusted software and hardware can be used while still remaining flexible.-Introduction:...
model, a Delegation Signer (DS) record in a parent domain (DNS zone
DNS zone
A DNS zone is a portion of the global Domain Name System namespace for which administrative responsibility has been delegated.-Definition:...
) can be used to verify a DNSKEY record in a subdomain
Subdomain
In the Domain Name System hierarchy, a subdomain is a domain that is part of a larger domain.- Overview :The Domain Name System has a tree structure or hierarchy, with each node on the tree being a domain name. A subdomain is a domain that is part of a larger domain, the only domain that is not...
, 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
Example.com
Example.com, example.net, example.org, and example.edu are second-level domain names reserved for documentation purposes and examples of the use of domain names....
".
- The process starts when a security-aware resolver sets the "DO" flag bit in a DNS query. Since the DO bit is in the extended flag bits defined by EDNSEDNSExtension mechanisms for DNS is a specification for expanding the size of several parameters of the Domain Name System protocol which had size restrictions that the Internet engineering community deemed too limited for increasing functionality of the protocol...
, 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 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. , 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." For the stub resolver to place any real reliance on DNSSEC services, the stub resolver must trust both the recursive name servers in question and the communication channels between itself and those name servers, using methods such as SIG(0), TSIG, or IPSec.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." Note that this means you have to trust the recursive name server (which is usually controlled by your Internet Service Provider
Internet service provider
An Internet service provider is a company that provides access to the Internet. Access ISPs directly connect customers to the Internet using copper wires, wireless or fiber-optic connections. Hosting ISPs lease server space for smaller businesses and host other people servers...
) to not perform a man-in-the-middle attack
Man-in-the-middle attack
In cryptography, the man-in-the-middle attack , bucket-brigade attack, or sometimes Janus attack, is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other...
to falsely set the AD bit on a forged result.
A 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 up to the DNSSEC root; the DNSSEC root certificate
Root certificate
In cryptography and computer security, a root certificate is either an unsigned public key certificate or a self-signed certificate that identifies the Root Certificate Authority . A root certificate is part of a public key infrastructure scheme...
must be locally available for this to work. Using such a validating stub resolver gives you end-to-end DNS security for domains implementing DNSSEC, even if you do not trust your Internet Service Provider. The BSD-licensed
BSD licenses
BSD licenses are a family of permissive free software licenses. The original license was used for the Berkeley Software Distribution , a Unix-like operating system after which it is named....
Unbound
Unbound (DNS Server)
Unbound is a validating, recursive, and caching DNS server software product from NLnet Labs, VeriSign Inc., Nominet, and . It is distributed free of charge in open source form under the BSD license....
program is an example of a validating stub resolver. The DNS client found in Windows 7 will not perform validation on its own, though it may be regarded as a “non-validating security-aware stub-resolver”; its behaviour – for example should it set the DO bit or should it require IPSec connection to the DNS server – can be controlled by group policies
Group Policy
Group Policy is a feature of the Microsoft Windows NT family of operating systems. Group Policy is a set of rules that control the working environment of user accounts and computer accounts. Group Policy provides the centralized management and configuration of operating systems, applications, and...
.
Trust anchors and authentication chains
To be able to prove that a DNS answer is correct, you need 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 systemOperating system
An operating system is a set of programs that manage computer hardware resources and provide common services for application software. The operating system is the most important type of system software in a computer 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 15th July 2010.
An authentication
Authentication
Authentication is the act of confirming the truth of an attribute of a datum or entity...
chain is a series of linked DS and DNSKEY records, starting with a trust anchor
Trust Anchor
In cryptography, a trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates and DNSSEC....
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.
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 anchorTrust Anchor
In cryptography, a trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates and DNSSEC....
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
Time to live is a mechanism that limits the lifespan 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 timespan has elapsed, data is discarded. In computer networking, TTL prevents a data...
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. Second, there are 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
DNS zone
A DNS zone is a portion of the global Domain Name System namespace for which administrative responsibility has been delegated.-Definition:...
, 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, but 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
.com
The domain name com is a generic top-level domain in the Domain Name System of the Internet. Its name is derived from commercial, indicating its original intended purpose for domains registered by commercial organizations...
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 (DANE) is an IETF working group with the goal of developing protocols and techniques that allow Internet applications to establish cryptographically secured communications (IPsecIPsec
Internet Protocol Security is a protocol suite for securing Internet Protocol communications by authenticating and encrypting each IP packet of a communication session...
, TLS
TLS
-Computing:* Transport Layer Security, a network protocol and successor to Secure Sockets Layer * Thread-local storage, a mechanism for allocating variables in computer science...
, DTLS) based on DNSSEC.
The new protocols will enable additional assurances and constraints for the traditional model based on Public Key Infrastructure
Public key infrastructure
Public Key Infrastructure is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. In cryptography, a PKI is an arrangement that binds public keys with respective user identities by means of a certificate...
. They will also enable domain holders to assert certificates for themselves, without reference to third-party certificate authorities
Certificate authority
In cryptography, a certificate authority, or certification authority, is an entity that issues digital certificates. The digital certificate certifies the ownership of a public key by the named subject of the certificate...
.
Support for DNSSEC stapled certificates was enabled in Google Chrome
Google Chrome
Google Chrome is a web browser developed by Google that uses the WebKit layout engine. It was first released as a beta version for Microsoft Windows on September 2, 2008, and the public stable release was on December 11, 2008. The name is derived from the graphical user interface frame, or...
14,
Mozilla Firefox
Mozilla Firefox
Mozilla Firefox is a free and open source web browser descended from the Mozilla Application Suite and managed by Mozilla Corporation. , Firefox is the second most widely used browser, with approximately 25% of worldwide usage share of web browsers...
's support is underway.
History
DNS is a critical and fundamental Internet service, yet in 1990 Steve Bellovin discovered serious security flaws in it. Research into securing it began, and dramatically increased 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 to have 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 changes DNSSEC so it is more practical to deploy.
Zone enumeration issue, controversy, and NSEC3
Although the goal of DNSSEC is to increase security, DNSSEC as defined in RFCs 4033 through 4035 introduces a new problem that many believe is a new security vulnerability: the zone enumeration (aka zone walking) issue. DNSSEC forces the exposure of information that by normal DNS best practice is kept private. NSEC3 (RFC 5155) was developed to address this issue; it was released in March 2008. NSEC3 mitigates, but does not eliminate, zone enumeration, since it is possible to exhaustively search the set of all possible names in a zone.Why DNS zone data is normally kept private
When the DNS protocol was designed, it was not intended to be a repository for hidden information. However, since the DNS does house information about the internals of a network related to a given domain, many view the contents of their DNS database as private. In particular, DNS systems are typically configured so that most users are not allowed to retrieve the entire list of names or other information in a zone. Such a list would greatly aid attackers, since that list can give them important information about what machines exist. Some administrators even put system type and configuration information into their DNS databases which is even more valuable to an attacker. The widely used book DNS and BIND (4th edition) by Albitz and Liu explains it this way: In addition, the information from an enumerated zone can be used as a key for multiple WHOISWHOIS
WHOIS is a query and response protocol that is widely used for querying databases that store the registered users or assignees of an Internet resource, such as a domain name, an IP address block, or an autonomous system, but is also used for a wider range of other information. The protocol stores...
queries; this would reveal registrant data which many registries are under strict legal obligations to protect under various contracts.
It is unclear whether DNSSEC is legal to deploy at all in many countries, unless such lists can be kept private. DENIC
DENIC
DENIC Verwaltungs- und Betriebsgesellschaft eG is the manager of the .de domain, the country-code top-level domain for Germany.In 2005, it was one of five bidders seeking to win contract to operate the .net contract offered by ICANN.- Etymology :...
has stated that DNSSEC's zone enumeration issue violates Germany's Federal Data Protection Act, and other European countries have similar privacy laws forbidding the public release of certain kinds of information.
DNSSEC reveals zone data
DNSSEC's original design required that the entire list of zone names be revealed to all. As stated in RFC 4033,There is an "obvious" solution, called a split-horizon DNS
Split-horizon DNS
In computer networking, split-horizon DNS, split-view DNS, or split-brain DNS is the facility of a Domain Name System implementation to provide different sets of DNS information, selected by, usually, the source address of the DNS request....
, which is how DNS without DNSSEC is sometimes deployed — but this approach does not work well with DNSSEC. In the "split-horizon DNS" approach, the DNS server denies the existence of names to some clients, and provides correct information to other clients. However, since DNSSEC information is cryptographically signed as authoritative, an attacker could request the signed "does not exist" record, then retransmit the record to cause a denial of service. DNSSEC fundamentally changes DNS so it can provide authoritative information; thus, it does not work well with methods based on providing false information to some users. Research has produced recommendations to properly combine these two DNS features.
DNSSEC introduced this problem because it must be able to report when a name is not found. DNS servers supporting DNSSEC must be able to sign that not-found report — otherwise a not-found report could be easily spoofed. Yet for security reasons the signing key should not be online. As a result, DNSSEC was designed to report a signed message that reports that a given range of names does not exist, which can be signed ahead-of-time offline. Unfortunately, this information is enough for an attacker to gain much more information than would have been available to them otherwise — it is enough to enable an attacker to quickly gather all the names in a zone, and then through targeted queries on the names to reconstruct all or most of a zone's data.
As noted earlier, DNSSEC could be used as the basis for a worldwide public key infrastructure
Public key infrastructure
Public Key Infrastructure is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. In cryptography, a PKI is an arrangement that binds public keys with respective user identities by means of a certificate...
for email addresses, by using DNS to serve email certificates and DNSSEC to validate them. However, this DNSSEC issue makes this unlikely for most organizations, at least if used directly. As RFC 4398 states, "If an organization chooses to issue certificates for its employees, placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC) is in use, it is possible for someone to enumerate all employees of the organization. This is usually not considered desirable, for the same reason that enterprise phone listings are not often publicly published and are even marked confidential."
Initial reaction
Many of the participants on the IETF DNS Extensions working group originally stated that zone enumeration was not a significant problem, arguing that the DNS data was—or should be—public. However, registrars and many large organizations told the working group members that DNSSEC as currently defined was unacceptable, and that they would not or legally could not deploy it.On-line signing
One approach to preventing zone enumeration was codified in RFC 4470. Instead of signing the not-found responses in advance, a not-found response is generated for each query. For example, if a query is received for 'b.example.com', instead of serving a previously signed response saying there are no names between 'a.example.com' and 'mail.example.com', which reveals the existence of 'mail.example.com', the response might be that 'there are no names between b.example.com and ba.example.com'. If the next query asks about 'ba.example.com', the response might be 'there are no names between ba.example.com and baa.example.com'. This makes enumerating the entire zone impractical.This approach has some disadvantages. It requires a signing key to be kept on-line and accessible to each DNS server. Many zone signing keys are kept on-line anyway to support automatic resigning or dynamic zone updates, but these functions are needed only on a single master DNS server, while to support on-line signing the zone signing key must be kept on each authoritative DNS server. Some authoritative servers must be accessible from the Internet and ideally these will be widely dispersed, making it difficult to keep the keys under control. Care is also required to prevent an attacker flooding the DNS server with requests for bogus names, denying service to legitimate users.
NSEC3
After deliberation, an extension was developed: "DNSSEC Hashed Authenticated Denial of Existence" (informally called "NSEC3"). In this approach, DNSSEC-aware servers can choose to send an "NSEC3" record instead of an NSEC record when a record is not found. The NSEC3 record is signed, but instead of including the name directly (which would enable zone enumeration), the NSEC3 record includes a cryptographically hashed value of the name. The NSEC3 record includes both a hash after a number of iterations and an optional salt, both of which reduce the effectiveness of pre-computed dictionary attacks. Salting increases the number of dictionaries necessary for an attack, while additional hash iterations increase the cost of computing each dictionary.In March 2008, NSEC3 was formally defined in RFC 5155.
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.
Widescale deployment of DNSSEC could resolve many other security problems as well, such as secure key distribution for e-mail addresses.
However, the DNSSEC specification has been challenging to develop. NSEC3, one of its critical pieces, was only formally defined in an RFC in March 2008, and it is not yet widely deployed.
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
TCP Cookie Transactions
In computer networking, TCP Cookie Transactions is an extension of Transmission Control Protocol intended to secure it against denial-of-service attacks, such as resource exhaustion by SYN flooding and malicious connection termination by third parties...
, 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 BrazilBrazil
Brazil , officially the Federative Republic of Brazil , is the largest country in South America. It is the world's fifth largest country, both by geographical area and by population with over 192 million people...
(.br
.br
.br is the Internet country code top-level domain 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 required for any registration...
), Bulgaria
Bulgaria
Bulgaria , officially the Republic of Bulgaria , is a parliamentary democracy within a unitary constitutional republic in Southeast Europe. The country borders Romania to the north, Serbia and Macedonia to the west, Greece and Turkey to the south, as well as the Black Sea to the east...
(.bg
.bg
The domain name .bg is the country code top-level domain in the Domain Name System of the Internet for Bulgaria. It is currently operated by Register.bg....
), Czech Republic
Czech Republic
The Czech Republic is a landlocked country in Central Europe. The country is bordered by Poland to the northeast, Slovakia to the east, Austria to the south, and Germany to the west and northwest....
(.cz
.cz
.cz is the country code top-level domain for the Czech Republic. It is administered by CZ.NIC. Registrations must be ordered via accredited domain name registrars.Before the split in 1993 former Czechoslovakia used domain .cs....
), Puerto Rico
Puerto Rico
Puerto Rico , officially the Commonwealth of Puerto Rico , is an unincorporated territory of the United States, located in the northeastern Caribbean, east of the Dominican Republic and west of both the United States Virgin Islands and the British Virgin Islands.Puerto Rico comprises an...
(.pr
.pr
-About Nic.pr:"Gauss Research Laboratory Inc" is the managing organization of the Puerto Rico's top level domain under the website. They operate the website , which stands for the Network Information Center of Puerto Rico....
) and Sweden
Sweden
Sweden , officially the Kingdom of Sweden , is a Nordic country on the Scandinavian Peninsula in Northern Europe. Sweden borders with Norway and Finland and is connected to Denmark by a bridge-tunnel across the Öresund....
(.se
.se
.se is the Internet country code top-level domain for Sweden . The top domain is operated by .SE , but domains must be registered through one of the approved registrars. .SE is a foundation and is managed on the basis of its charter of foundation and its statutes...
), who use DNSSEC for their country code top-level domain
Country code top-level domain
A country code top-level domain is an Internet top-level domain generally used or reserved for a country, a sovereign state, or a dependent territory....
s; RIPE NCC
RIPE NCC
The Réseaux IP Européens Network Coordination Centre is the Regional Internet Registry for Europe, the Middle East and parts of Central Asia...
, who have signed all the reverse (in-addr.arpa) that are delegated to it from the Internet Assigned Numbers Authority
Internet Assigned Numbers Authority
The Internet Assigned Numbers Authority is the entity that oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System , media types, and other Internet Protocol-related symbols and numbers...
(IANA). ARIN
Arin
Arin may refer to:* American Registry for Internet Numbers* Arin, Armenia - A town in Armenia* Arin language - An extinct Yeniseic language* Arın Soğancıoğlu, Turkish basketball player...
is also signing their reverse zones. TDC was the first ISP to implement this feature in Sweden.
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
Internet Systems Consortium
Internet Systems Consortium, Inc., also known as ISC, is a Delaware-registered, 501 public benefit non-profit corporation dedicated to supporting the infrastructure of the universal connected self-organizing Internet by developing and maintaining core production quality software, protocols, and...
introduced another on March 27 of the same year, while ICANN
ICANN
The Internet Corporation for Assigned Names and Numbers is a non-profit corporation headquartered in Marina del Rey, California, United States, that was created on September 18, 1998, and incorporated on September 30, 1998 to oversee a number of Internet-related tasks previously performed directly...
themselves announced a third on February 17, 2009..
A wide variety of pilot projects and experiments are and have been performed. dnssec.net maintains a list of such projects. There is also a Google Map of World Wide DNSSEC Deployment.
On June 2, 2009, the Public Interest Registry
Public Interest Registry
Public Interest Registry is a not-for-profit corporation created by the Internet Society in 2002 to manage the .org top-level domain. It took over the operation of the domain from VeriSign on 1 January 2003. Afilias manages the technical operations of the .org registry under a contract with the...
signed the .org zone. The Public Internet Registry also detailed on September 26, 2008, that the first phase, involving large registrars it has a strong working relationship with ("friends and family") will 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 AdministrationNational Telecommunications and Information Administration
The National Telecommunications and Information Administration is an agency of the United States Department of Commerce that serves as the President's principal adviser on telecommunications policies pertaining to the United States' economic and technological advancement and to regulation of the...
(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
National Institute of Standards and Technology
The National Institute of Standards and Technology , known between 1901 and 1988 as the National Bureau of Standards , is a measurement standards laboratory, otherwise known as a National Metrological Institute , which is a non-regulatory agency of the United States Department of Commerce...
(NIST) announced plans to sign the root by the end of 2009, in conjunction with ICANN, VeriSign
VeriSign
Verisign, Inc. is an American company based in Dulles, Virginia that operates a diverse array of network infrastructure, including two of the Internet's thirteen root nameservers, the authoritative registry for the .com, .net, and .name generic top-level domains and the .cc and .tv country-code...
and the NTIA.
On October 6, 2009, at the 59th RIPE
RIPE
Réseaux IP Européens 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 coordination necessary to maintain and develop the Internet continues...
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
.org
The domain name org is a generic top-level domain of the Domain Name System used in the Internet. The name is derived from organization....
top-level domain has been signed with DNSSEC in June 2010, followed by .com
.com
The domain name com is a generic top-level domain in the Domain Name System of the Internet. Its name is derived from commercial, indicating its original intended purpose for domains registered by commercial organizations...
, .net
.net
The domain name net is a generic top-level domain used in the Domain Name System of the Internet. The name is derived from network, indicating its originally intended purpose for organizations involved in networking technologies, such as Internet service providers and other infrastructure companies...
, and .edu
.edu
The domain name edu is a sponsored top-level domain in the Domain Name System of the Internet. The "domain is intended for accredited post-secondary educational U.S. institutions" and this intention is strictly enforced....
later in 2010 and 2011. Country code top-level domain
Country code top-level domain
A country code top-level domain is an Internet top-level domain generally used or reserved for a country, a sovereign state, or a dependent territory....
s will be able to deposit keys starting in May 2010.
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-2SHA-2
In cryptography, SHA-2 is a set of cryptographic hash functions designed by the National Security Agency and published in 2001 by the NIST as a U.S. Federal Information Processing Standard. SHA stands for Secure Hash Algorithm. SHA-2 includes a significant number of changes from its predecessor,...
(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 are available from IANA.
DNSSEC Lookaside Validation
In March 2006, the Internet Systems ConsortiumInternet Systems Consortium
Internet Systems Consortium, Inc., also known as ISC, is a Delaware-registered, 501 public benefit non-profit corporation dedicated to supporting the infrastructure of the universal connected self-organizing Internet by developing and maintaining core production quality software, protocols, and...
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 maintains a central list of trust anchors, instead of each validator repeating the work of maintaining its own list.
To use DLV, you need a validator that supports it, such as BIND
BIND
BIND , or named , is the most widely used DNS software on the Internet.On Unix-like operating systems it is the de facto standard.Originally written by four graduate students at the Computer Systems Research Group at the University of California, Berkeley , the name originates as an acronym from...
or Unbound
Unbound (DNS Server)
Unbound is a validating, recursive, and caching DNS server software product from NLnet Labs, VeriSign Inc., Nominet, and . It is distributed free of charge in open source form under the BSD license....
, configured with a trust anchor for a DLV zone. This zone contains DLV records; these have exactly the same format as DS records, but instead of referring to a delegated sub-zone, they refer to a zone elsewhere in the DNS tree. When the validator cannot find a chain of trust from the root to the RRset it is trying to check, it searches for a DLV record that can provide an alternative chain of trust.
DLV continues to be useful after the root has been signed. While there are gaps in the chain of trust, such as unsigned top-level domains, or registrars that do not support DNSSEC delegations, hostmasters of lower-level domains can use DLV to make it easier for their users to validate their DNS data.
DNSSEC deployment initiative by the U.S. federal government
The Science and Technology Directorate of the U.S. Department of Homeland SecurityUnited States Department of Homeland Security
The United States Department of Homeland Security is a cabinet department of the United States federal government, created in response to the September 11 attacks, and with the primary responsibilities of protecting the territory of the United States and protectorates from and responding to...
(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
United States Department of Homeland Security
The United States Department of Homeland Security is a cabinet department of the United States federal government, created in response to the September 11 attacks, and with the primary responsibilities of protecting the territory of the United States and protectorates from and responding to...
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 TechnologyNational Institute of Standards and Technology
The National Institute of Standards and Technology , known between 1901 and 1988 as the National Bureau of Standards , is a measurement standards laboratory, otherwise known as a National Metrological Institute , which is a non-regulatory agency of the United States Department of Commerce...
(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."
DNSSEC deployment by ISPs
Several ISPs have started to deploy DNSSEC-validating DNS recursive resolvers. Comcast became the first major ISP to do so in the United States on October 18, 2010.Tools
DNSSEC deployment requires software on the server and client side. Some of the tools that support DNSSEC include:- Windows 7 and Windows Server 2008 R2 include a "security-aware" stub resolver that is able to differentiate between secure and non-secure responses by a recursive name server.
- BINDBINDBIND , or named , is the most widely used DNS software on the Internet.On Unix-like operating systems it is the de facto standard.Originally written by four graduate students at the Computer Systems Research Group at the University of California, Berkeley , the name originates as an acronym from...
, the most popular DNS name server (which includes digDomain Information GroperDomain Information Groper is a network administration command-line tool for querying Domain Name System name servers for any desired DNS records....
). Version 9.3 implemented the newer DNSSEC-bis (DS records) although it did not support NSEC3 records. BIND 9.6 was released in December 2008 and has full support for NSEC3 records. - Drill is a DNSSEC-enabled digDomain Information GroperDomain Information Groper is a network administration command-line tool for querying Domain Name System name servers for any desired DNS records....
-like tool bundled with ldns. - Drill extension for Firefox adds to Mozilla FirefoxMozilla FirefoxMozilla Firefox is a free and open source web browser descended from the Mozilla Application Suite and managed by Mozilla Corporation. , Firefox is the second most widely used browser, with approximately 25% of worldwide usage share of web browsers...
the ability to determine if a domain can be verified using DNSSEC. - DNSSEC-Tools aims at providing easy to use tools for helping all types of administrators and users make use of DNSSEC. It offers tools for administrators of Authoritative Zones, Authoritative Server, and Recursive Servers as well as a library and tools for Application Developers and existing patches for extending common applications.
- Zone Key Tool is a software designed to ease the maintenance of DNSSEC aware zones. It's primarily designed for environments with a small to medium number of zones and provides a full automatic zone signing key rollover as well as automatic resigning of the zone.
- Unbound is a DNS name server that was written from the ground up to be designed around DNSSEC concepts.
- GbDns is a compact, easy-to-install DNSSEC name server for Microsoft Windows.
- mysqlBindMysqlBindmysqlBind/unxsBind is a DNS management software system. It supports ISC BIND DNS and is distributed as open source software under the GNU General Public License.mysqlBind/unxsBind has been in use since the late 1990s...
The GPL DNS management softwareDNS management softwareDNS management software is computer software that controls Domain Name System server clusters. Its main purpose is to reduce human error when editing complex and repetitive text-based DNS server configuration files. Such files are often deployed on multiple physical servers.DNS service providers...
for DNS ASPs now supports DNSSEC. - OpenDNSSECOpenDNSSECThe OpenDNSSEC is software that manages the security of domain names on the Internet. The project intends to drive adoption of Domain Name System Security Extensions to further enhance Internet security....
is a designated DNSSEC signer tool using PKCS#11PKCS11In cryptography, PKCS #11 is one of the family of standards called Public-Key Cryptography Standards , published by RSA Laboratories, that defines a platform-independent API to cryptographic tokens, such as Hardware Security Modules and smart cards...
to interface with Hardware Security ModuleHardware Security ModuleA hardware security module is a type of secure cryptoprocessor targeted at managing digital keys, accelerating cryptoprocesses in terms of digital signings/second and for providing strong authentication to access critical keys for server applications...
s. - SecSpider tracks DNSSEC deployment, monitors zones, and provides a list of observed public keys.
- DNSViz and DNSSEC Analyzer are Web-based tools to visualize the DNSSEC authentication chain of a domain.
- DNSSEC Validator is a Mozilla FirefoxMozilla FirefoxMozilla Firefox is a free and open source web browser descended from the Mozilla Application Suite and managed by Mozilla Corporation. , Firefox is the second most widely used browser, with approximately 25% of worldwide usage share of web browsers...
addon for visualization of DNSSEC status of the visited domain name. - DNSSHIM or DNS Secure Hidden Master is an open-source tool to automatize DNSSEC supported zones provisioning process.
- Net::DNS::SEC is a DNS resolver implemented in PERLPerlPerl is a high-level, general-purpose, interpreted, dynamic programming language. Perl was originally developed by Larry Wall in 1987 as a general-purpose Unix scripting language to make report processing easier. Since then, it has undergone many changes and revisions and become widely popular...
See also
- EDNSEDNSExtension mechanisms for DNS is a specification for expanding the size of several parameters of the Domain Name System protocol which had size restrictions that the Internet engineering community deemed too limited for increasing functionality of the protocol...
- extension to DNS to allow for the larger packets DNSSEC uses and the DO flag bit - TSIGTSIGTSIG is a computer networking protocol definedin RFC 2845. It is used primarily by the Domain Name System to provide a means of authenticating updates to a Dynamic DNS database, although it can also be used between servers and for regular queries...
- used to securely authenticate transactions between the resolver and name servers - DNSCurveDNSCurveDNSCurve is a proposed new secure protocol for the Domain Name System , designed by Daniel J. Bernstein. The basic idea is to define a secure new transport layer protocol to replace TCP, called CurveCP, using elliptic curve cryptography on top of UDP then doing DNS queries inside CurveCP...
- light-weight encryption/authentication between name servers and resolvers. - RPKI - a similar technology applied to Internet routing registry records
Organizations/websites
- DNSSEC - DNSSEC information site: DNSSEC.net
- DNSEXT DNS Extensions IETF Working Group
- CircleID - News and Opinions on all DNSSEC related issues
- DNSSEC-Tools Project
- DNSSEC Deployment Coordination Initiative
- DNSSEC Deployment Team
- ICANN DNS Operations Team
Standards
- RFC 2535 Domain Name System Security Extensions
- RFC 3833 A Threat Analysis of the Domain Name System
- RFC 4033 DNS Security Introduction and Requirements (DNSSEC-bis)
- RFC 4034 Resource Records for the DNS Security Extensions (DNSSEC-bis)
- RFC 4035 Protocol Modifications for the DNS Security Extensions (DNSSEC-bis)
- RFC 4398 Storing Certificates in the Domain Name System (DNS)
- RFC 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing
- RFC 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
- RFC 4641 DNSSEC Operational Practices
- RFC 5155 DNSSEC Hashed Authenticated Denial of Existence
Other documents
- A Fundamental Look at DNSSEC, Deployment, and DNS Security Extensions by Geoff Huston
- "Using the Domain Name System for System Break-Ins" by Steve Bellovin, 1995
- A short timeline of DNSSEC by Miek Gieben
- Enabling secure name resolution using DNSSEC for various applications
- DNSSEC Howto by Olaf Kolkman (RIPE NCC/NLnet Labs)
- Howto secure your (reverse) Zone by Holger Zuleger
- Easier Email Security is on the Way?
- "DNSSEC and the Zone Enumeration" by Marcos Sanz
- NIST Special Publication (SP) 800-81, Secure Domain Name System (DNS) Deployment Guide, May 2006
- Bootstrapping the Adoption of Internet Security Protocols, Andy Ozment and Stuart E. Schechter, June 26–28, 2006
- DNSSEC BRIEFING and Root Zone Signing (Part I), ccTLD paper on DNSSEC by ccNSO, February 2008
- U.S. National Strategy to Secure Cyberspace, February 2003
- Cybertelecom :: DNS Security & USG Policy
- SecSpider Tool for Tracking DNSSEC Deployment
- Plea to sign the root
- DNSSEC in 6 Minutes by Alan Clegg, Internet Systems Consortium (PDF-Datei; 315 kB)
- Implementing DNSSEC Cisco Internet Protocol Journal
- List of TLD's with DNSSEC implemented
- ICANN's TLD DNSSEC Report (generated daily)