add site
services
publishers
database
health videos
toolbar
stats
live show
health store
more stuff
JOIN/LOGIN
| advertise add site services publishers database health videos
| | about toolbar stats live show health store more stuff JOIN/LOGIN |
The Domain Name System Security Extensions (DNSSEC) are a suite of 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):
It is widely believed[who?] that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered by the difficulty of:
Some of these problems are in the process of being resolved, and deployments in various domains have begun to take place.
[edit] OverviewThe original design of the Domain Name System (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 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 cure 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), RFC 2535 has become obsolete. [edit] How it worksDNSSEC works by digitally signing answers to DNS lookups using public-key cryptography. To do this, several new DNS record types were created, including the RRSIG, DNSKEY, DS, and NSEC DNS records. When DNSSEC is used, each answer to a DNS lookup will contain an RRSIG DNS record, in addition to the record types that were 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. From the results, a security-aware DNS resolver can then determine if the answer it received was correct (secure), whether the authoritative name server for the domain being queried doesn't support DNSSEC (insecure), or if there is some sort of error. The correct DNSKEY record is found via an Authentication Chain, starting with a known good public key for a Trust Anchor. This public key can then be used to verify a designated signer (DS) record. A DS record in a parent domain (DNS zone) can then be used to verify a DNSKEY record in a subdomain, which can then contain other DS records to verify further subdomains. [edit] The lookup procedureThe lookup procedure is different for recursive name servers, such as those of many ISPs, and for stub resolvers, such as those included by default in mainstream operating systems. Windows 7 will include a "security-aware" stub resolver that will be able to differentiate between secure and non-secure responses by a recursive name server.[1] [edit] Recursive name serversSay that a resolver wants to get the IP addresses (A record and/or AAAA records) of the domain 'www.example.com'. 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 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. In theory, the security-aware resolver would start with verifying the DS and DNSKEY records at the DNS root. Then, in our example, 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 exception cases with the above example. First, if 'example.com' does not support DNSSEC, you will not get a 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 isn't a domain name named 'www.example.com', in which case instead of returning a RRSIG record in the answer, you will get 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 and you have an Island of Security. These islands of security need to be validated some other way. Neither the root nor the 'com' domains are currently signed, though NIST has announced plans to sign the root by the end of 2009.[2] [edit] Stub resolversStub resolvers are "minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution to a recursive name server."[3] 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.[4] 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."[4] It can also potentially perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages.[4] [edit] Trust anchors and authentication chainsTo be able to prove that a DNS answer is correct, you need to know at least one key that is correct from sources other than the DNS. These starting points are known as trust anchors and are typically obtained with the operating system or via some other trusted source. When DNSSEC was originally designed, it was thought that the only trust anchor that would be needed was for the DNS root. As of 2009[update], however, the root has not yet been signed, which has led to the deployment of alternative trust anchors to the DNS root. 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. [edit] Key managementDNSSEC involves many different keys, stored both in DNSKEY records, and from other sources to form trust anchors.
[edit] HistoryDNS 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.[5] 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. [edit] Zone enumeration issue, controversy, and NSEC3Although 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. [edit] Why DNS zone data is normally kept privateWhen 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 WHOIS 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. [edit] DNSSEC reveals zone dataUnfortunately, 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, 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.[7] The reason DNSSEC introduced this problem is because it must be able to report when a name is not found. Most believe 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." [edit] Response and NSEC3Many 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. 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. Salt, where used, increases the number of pre-computed dictionaries that an attacker using a pre-computed dictionary attack would need to create, increasing iteration values raise the computational cost of computing a dictionary. In March 2008, NSEC3 was formally defined in RFC 5155. VeriSign was running an NSEC3 DNSSEC Pilot to provide others with operational experience with NSEC3 at the top-level-domain level and an independent implementation of the authoritative server component. This pilot provided a DNSSEC signed version of .com and .net using the NSEC3 record. The pilot is now defunct. [edit] DeploymentThe Internet is considered to be critical infrastructure by many, 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.[8] 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. In addition, DNSSEC deployment in large-scale networks is also challenging. DNSSEC can be deployed at any level of a DNS hierarchy, but it must be widely available in a zone before many others will 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. 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, it risks remaining undeployed. To address these challenges, significant effort is ongoing to deploy DNSSEC, because the Internet is so vital to so many organizations. [edit] ToolsDNSSEC deployment requires software on the server and client side. Some of the tools that support DNSSEC include:
[edit] Early deploymentsEarly adopters include Brazil (.br), Bulgaria (.bg), Czech Republic (.cz), Puerto Rico (.pr) and Sweden (.se), who use DNSSEC for their country code top-level domains;[10] RIPE NCC, who have signed all the reverse (in-addr.arpa) that are delegated to it from the Internet Assigned Numbers Authority (IANA).[11] ARIN is also signing their reverse zones. [12] TDC was the first ISP to implement this feature in Sweden. IANA has been publicly testing a sample signed root since June 2007. VeriSign was running a pilot project to allow .com and .net domains to register themselves to do DNSSEC NSEC3 experiments, as noted above. 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 February 24, 2009, VeriSign announced that they would deploy DNSSEC across all their top level domains (.com, .net, etc.) within 24 months.[13] On June 2, 2009, .ORG, The Public Interest Registry signed the .ORG zone [14] 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".[15] On November 16, 2009, VeriSign said a significant outstanding Internet security vulnerability will be closed for the .com and .net domains by the first quarter of 2011, after delays caused by technical aspects of the implementation.[16] [edit] Deployment at the DNS rootMany are interested in deploying DNSSEC at the root level. If deployed widely at the root level, DNSSEC could support distribution of public keys associated with any arbitrary domain name, countering many spam and spoof attacks. Having a few DNS root-level DNSSEC public keys would greatly simplify the deployment of DNSSEC resolvers, since those few keys could be the basis for any other key. On June 3, 2009, NIST announced plans to sign the root by the end of 2009, in conjunction with ICANN, VeriSign and the National Telecommunications and Information Administration (NTIA), a part of the U.S. Department of Commerce.[2] 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 [17] instead of actual deployment. . It will be incrementally deployed to one root name server a month, starting on December 1st, 2009. The final root name server will begin serving a DNSSEC signed zone on July 1, 2010. The root zone will be signed with a RSA/SHA256 DNSKEY. During the incremental roll-out period the root zone will contain dummy keys and the final DNSKEY record will not be distributed until July 1st, 2010. Political issues surrounding signing the root have been a continuous concern, primarily about some central issues:
In September 2008, ICANN and VeriSign each published implementation proposals[18] and in October, the National Telecommunications and Information Administration asked the public for comments.[19] It is unclear if the comments received affected the design of the final deployment plan. [edit] Deployment of alternative trust anchors to the DNS rootDue to delays with signing the root, there have been several proposed and deployed alternative trust anchors.
[edit] DNSSEC Deployment InitiativeThe Science and Technology Directorate of the U.S. Department of Homeland Security (DHS) sponsors the "DNSSEC Deployment Initiative". This initiative encourages "all sectors to voluntarily adopt security measures that will improve security of the Internet's naming infrastructure, as part of a global, cooperative effort that involves many nations and organizations in the public and private sectors." DHS also funds efforts to mature DNSSEC and get it deployed inside the U.S. federal government. It was reported[23] 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[24] 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." [edit] DNSSEC deployment in the U.S. federal governmentThe National Institute of Standards and Technology (NIST) published NIST Special Publication 800-81 Secure Domain Name System (DNS) Deployment Guide on May 16, 2006, with guidance on how to deploy DNSSEC. NIST intended to release new DNSSEC Federal Information Security Management Act (FISMA) requirements in NIST SP800-53-R1, referencing this deployment guide. U.S. agencies would then have had one year after final publication of NIST SP800-53-R1 to meet these new FISMA requirements.[25] 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.[26] 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."[27] [edit] See also
[edit] References
[edit] External links[edit] Organizations / Websites
[edit] Standards
[edit] Other documents
| |||||||||||||||||||||
| ↑ top of page ↑ | about thumbshots |
