Usuario:Pabluk/DNSSEC

El Domain Name System Security Extensions (DNSSEC) es un conjunto de especificaciones del IETF para asegurar cierto tipo de información propocionada por el Domain Name System (DNS) usado sobre las redes Internet Protocol (IP). Se trata de un conjunto de extensiones de DNS que proveen a los clientes DNS (resolvers):

• Autenticación de origen de los datos DNS
• Integridad de los datos (pero no disponibilidad o confiabilidad)
• Authenticated denial of existence

Se cree que asegurar el DNS es sumamente importante para asegurar toda Internet, pero la implementación de DNSSEC se ha visto obtaculizada principalemente por la dificultad de:

1. Devising a backward-compatible standard that can scale to the size of the Internet
2. Preventing "zone enumeration" (see below) where desired
3. Deploying DNSSEC implementations across a wide variety of DNS servers and resolvers (clients)
4. Disagreement among key players over who should own the .com (etc) root keys
5. Overcoming the perceived complexity of DNSSEC and DNSSEC deployment

Algunos de estos problemas están en proceso de ser resueltos, y se ha comenzado a realizar el desarrollo de varios dominios^{[cita requerida]}.

Overview

IP-based networks, including the Internet, route information between computers based on their IP address, a multi-byte number (four bytes in IP version 4, sixteen bytes in IP version 6). Directly using these numbers would cause many problems, so DNS is a critical service of such networks. DNS accepts a domain name (such as example.com) and responds with information about that name, such as its matching IP address. DNS can also perform reverse look-ups (given an IP address, return the corresponding name). DNS is implemented as a distributed system, for scalability. (For more information, see Domain Name System.) Unfortunately, DNS was not designed to be secure.

There are several distinct classes of threats to the DNS, most of which are DNS-related instances of more general problems, but a few of which are specific to peculiarities of the DNS protocol. A Request for Comments document, RFC 3833, attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent DNSSEC is a useful tool in defending against these 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 world-wide 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.

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.

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:

Arguably even more important than controlling who can query your name server is ensuring that only your real slave name servers can transfer zones from your name server. Users on remote hosts... can only look up records (e.g., addresses) for domain names they already know, one at a time... It's the difference between letting random folks call your company's switchboard and ask for John Q. Cubicle's phone number [versus] sending them a copy of your corporate phone directory.​

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.

DNSSEC reveals zone data

Unfortunately, DNSSEC's original design required that the entire list of zone names be revealed to all. As stated in RFC 4033,

DNSSEC introduces the ability for a hostile party to enumerate all the names in a zone by following the NSEC chain. NSEC RRs assert which names do not exist in a zone by linking from existing name to existing name along a canonical ordering of all the names within a zone. Thus, an attacker can query these NSEC RRs in sequence to obtain all the names in a zone. Although this is not an attack on the DNS itself, it could allow an attacker to map network hosts or other resources by enumerating the contents of a zone.

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.

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."

Response and NSEC3

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.

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.

Deployment

The Internet is considered a critical infrastructure by many, yet it was originally based 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.

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.

Tools

DNSSEC deployment requires software on the server and client side. Some of the tools that support DNSSEC include:

• BIND, the most popular DNS name server. Version 9.3 implemented the newer DNSSEC-bis (DS records) although it did not support NSEC3 records. BIND 9.6 implements full support for NSEC3 records​; an alpha version of BIND 9.6 became available in October 2008​.
• Drill is a DNSSEC-enabled dig-like tool bundled with ldns.
• Drill extension for Firefox adds to Mozilla Firefox the ability to determine if a domain can be verified using DNSSEC.
• DNSSEC-Tools is a SourceForge project aimed 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.
• DNSSEC support is being introduced in Windows 7 and Windows Server 2008 R2, and may be introduced in Windows Server 2008 Service Pack 2 as well.​
• mysqlBind The GPL OSS for DNS ASPs now supports DNSSEC.

Early deployments

Early 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,​, the Public Interest Registry which registers domains in the .org top-level domain,​ RIPE NCC,who have signed all the reverse (in-addr.arpa) that are delegated to it from IANA ​, and VeriSign. TDC was the first ISP to implement this feature in Sweden.

IANA has been publicly testing a sample signed root at https://ns.iana.org/dnssec/status.html 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.

Deployment at the DNS root

Many 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. However, root level deployment may be delayed for a variety of reasons.

Thierry Moreau reports that as of May 22, 2006, the technology is nearly ready.^{[cita requerida]} Thierry reports that the major technological problems stalling deployment are:

1. The zone enumeration privacy issue (noted above).
2. The trust anchor key rollover issue.
3. Further testing is desired to strengthen the confidence that DNSSEC is adequate (especially given the failures of earlier versions).

However, political issues are likely to cause trouble and delay deployment:

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

ICANN has described its DNS root zone signing as simply to "determine timetable, coordination requirements and costs for full deployment"​ instead of actual deployment, suggesting that it may be a long time before DNSSEC is deployed at the root (global) level of DNS.

The Public Interest Registry announced in July, 2008 that it will begin using DNSSEC in a then-unspecified deployment timetable. It further 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".​ In September, ICANN and VeriSign each published implementation proposals​ and in October, the National Telecommunications and Information Administration, a part of the U.S. Department of Commerce, asked the public for comments.​

DNSSEC Deployment Initiative

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

It was reported​ 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."

DNSSEC deployment in the U.S. federal government

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

See also

• EDNS - extension to DNS to allow for the larger packets DNSSEC uses
• TSIG - used to securely authenticate transactions between the resolver and name servers
• DNSCurve - light-weight encryption/authentication between name servers and resolvers.

External links

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

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 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
• RFC 4641 DNSSEC Operational Practices

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
• 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
• "DNSSEC Deployment at the Root", May 22, 2006, by Thierry Moreau CircleID
• 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