Domain Name System Security Extensions

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.

Overview

The 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 documents some of the known threats to the DNS and how DNSSEC responds to those threats.

DNSSEC was designed to protect applications (and caching resolvers serving those applications) from using forged or manipulated DNS data, such as that created by DNS cache poisoning. All answers from DNSSEC protected zones are digitally signed. By checking the digital signature, a DNS resolver is able to check if the information is identical (i.e. unmodified and complete) to the information published by the zone owner and served on an authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect any data published in the DNS, including text records (TXT), mail exchange records (MX), and can be used to bootstrap other security systems that publish references to cryptographic certificates stored in the DNS such as Certificate Records (CERT records, RFC 4398), SSH fingerprints (SSHFP, RFC 4255), IPSec public keys (IPSECKEY, RFC 4025), and TLS Trust Anchors (TLSA, RFC 6698).

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; this is true only if the DNS server is using a self-signed certificate,not recommended for Internet-facing DNS servers).

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[1] that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered (As of 22 January 2010) by several difficulties:

Microsoft Windows uses a stub resolver, and Windows 7 and beyond in particular use a non-validating (but DNSSEC-aware) stub resolver.[2][3] For the non-validating stub resolver to place any real reliance on DNSSEC services, the stub resolver must trust both the recursive name servers in question (which is usually controlled by the Internet Service Provider) and the communication channels between itself and those name servers, using methods such as IPsec, SIG(0), or TSIG.[4] The use of IPsec is not widespread.[5]

Operation

DNSSEC works by digitally signing 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. Domain owners generate their own keys, and upload them using their DNS control panel at their domain-name registrar, which in turn pushes the keys via secDNS to the zone operator (e.g., Verisign for .com) who signs and publishes them in DNS.

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:

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

Algorithms

DNSSEC was designed to be extensible so that as attacks are discovered against existing algorithms, new ones can be introduced in a backward-compatible fashion. The following table defines, as of April 2013, the security algorithms that are most often used:[6]

Algorithm field Algorithm Source Implementation status[7]
1 RSA/MD5 Must Not Implement
3 DSA/SHA-1 Optional
5 RSA/SHA-1 Required
7 RSASHA1-NSEC3-SHA1 RFC 5155 Recommended
8 RSA/SHA-256 RFC 5702 Recommended
10 RSA/SHA-512 Recommended
12 GOST R 34.10-2001 RFC 5933 Optional
13 ECDSA/SHA-256 RFC 6605 Recommended
14 ECDSA/SHA-384 Recommended

The lookup procedure

From the results of a DNS lookup, a security-aware DNS resolver can determine whether the authoritative name server for the domain being queried supports DNSSEC, whether the answer it receives is secure, and whether there is some sort of error. The lookup procedure is different for recursive name servers such as those of many ISPs, and for stub resolvers such as those included by default in mainstream operating systems. Microsoft Windows uses a stub resolver, and Windows Server 2008 R2 and Windows 7 in particular use a non-validating but DNSSEC-aware stub resolver.[2][3]

Recursive name servers

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

  1. The process starts when a security-aware resolver sets the "DO" 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.
  2. When the resolver receives an answer via the normal DNS lookup process, it then checks to make sure that the answer is correct. Ideally, the security-aware resolver would start with verifying the DS and DNSKEY records at the DNS root. Then it would use the DS records for the "com" top level domain found at the root to verify the DNSKEY records in the "com" zone. From there, it would see if there is a DS record for the "example.com" subdomain in the "com" zone, and if there were, it would then use the DS record to verify a DNSKEY record found in the "example.com" zone. Finally, it would verify the RRSIG record found in the answer for the A records for "www.example.com".

There are several exceptions to the above example.

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

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

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

Stub resolvers

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

A validating stub resolver can also potentially perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages.[4] A validating stub resolver uses the CD bit to perform its own recursive authentication. Using such a validating stub resolver gives the client end-to-end DNS security for domains implementing DNSSEC, even if the Internet Service Provider or the connection to them is not trusted.

For the non-validating stub resolver to place any real reliance on DNSSEC services, the stub resolver must trust both the recursive name servers in question (which is usually controlled by the Internet Service Provider) and the communication channels between itself and those name servers, using methods such as IPsec, SIG(0), or TSIG.[4] The use of IPsec is not widespread.[5]

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 system or via some other trusted source. When DNSSEC was originally designed, it was thought that the only trust anchor that would be needed was for the DNS root. The root anchors were first published on 15 July 2010.[11]

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.

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

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

Keys in DNSKEY records can be used for two different things and typically different DNSKEY records are used for each. First, there are key signing keys (KSK) which are used to sign other DNSKEY records. 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 while reducing the size of the RRSIG/DNSKEY records.

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

DANE Working Group

DNS-based Authentication of Named Entities (DANE) is an IETF working group[12] with the goal of developing protocols and techniques that allow Internet applications to establish cryptographically secured communications with TLS, DTLS, SMTP, and S/MIME based on DNSSEC.

The new protocols will enable additional assurances and constraints for the traditional model based on Public Key Infrastructure. They will also enable domain holders to assert certificates for themselves, without reference to third-party certificate authorities.[13]

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

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.[18] 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 makes DNSSEC deployment more practical.

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

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 download the entire list of names or other information in a zone.

This is because DNS by definition translates domain names into lower level protocol addresses. Both the abstract space of domain names and the lower level addresses are sparsely populated, so that keeping the occupied spaces secret affords a modicum of resistance towards automated attack software. In a word, if you don't know whom to address your message to, you cannot harass them.

DNS functions much like a distributed phonebook, so that the list of addresses it contains makes an attacker's job much easier. While they would otherwise need to collect information about what machines exist one by one, wholesale access to DNS servers' zone files enables automated attacks over swathes of endpoints connected to the internet.

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

Additionally it is possible that 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 . In the context of the phonebook analogy, the system would now be leaking information about who paid for the information to be placed in the directory—in many cases like those of journalists, people working for competing companies and such, quite a dangerous breach of etiquette.

For such reasons, it is unclear whether DNSSEC is legal to deploy at all in many countries, unless the registry data it forces DNS to divulge 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

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. Research has produced recommendations to properly combine these two DNS features.[21]

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

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 re-signing 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.

The proponents of DNSCurve argue that it is still easy to enumerate a zone protected by NSEC3 and present a proof of concept implementation. This attack could be mitigated by using more computationally intensive hash functions.

RFC 5155 formally defined NSEC3 in March 2008.

Universal DNSSEC

In order to prevent zone enumeration, CloudFlare have implemented a solution called by them "Universal DNSSEC". In this approach, CloudFlare servers queried for a non-existing resource return a single NSEC record, signed on the fly using ECDSA, which states that "the record exists but the requested record type does not". Such an answer does not require naming the next existing record but is still correctly interpreted by DNS resolvers.[22]

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.[23] Wide-scale deployment of DNSSEC could resolve many other security problems as well, such as secure key distribution for e-mail addresses.

DNSSEC deployment in large-scale networks is also challenging. Ozment and Schechter observe that DNSSEC (and other technologies) has a "bootstrap problem": users typically only deploy a technology if they receive an immediate benefit, but if a minimal level of deployment is required before any users receive a benefit greater than their costs (as is true for DNSSEC), it is difficult to deploy. DNSSEC can be deployed at any level of a DNS hierarchy, but it must be widely available in a zone before many others will want to adopt it. DNS servers must be updated with software that supports DNSSEC, and DNSSEC data must be created and added to the DNS zone data. A TCP/IP-using client must have their DNS resolver (client) updated before it can use DNSSEC's capabilities. What is more, any resolver must have, or have a way to acquire, at least one public key that it can trust before it can start using DNSSEC.

DNSSEC implementation can add significant load to some DNS servers. Common DNSSEC-signed responses are far larger than the default UDP size of 512 bytes. In theory, this can be handled through multiple IP fragments, but many "middleboxes" in the field do not handle these correctly. This leads to the use of TCP instead. Yet many current TCP implementations store a great deal of data for each TCP connection; heavily loaded servers can run out of resources simply trying to respond to a larger number of (possibly bogus) DNSSEC requests. Some protocol extensions, such as TCP Cookie Transactions, have been developed to reduce this loading.[24] To address these challenges, significant effort is ongoing to deploy DNSSEC, because the Internet is so vital to so many organizations.

Early deployments

Early adopters include Brazil (.br), Bulgaria (.bg), Czech Republic (.cz), Namibia (.na)[25] Puerto Rico (.pr) and Sweden (.se), who use DNSSEC for their country code top-level domains;[26] RIPE NCC, who have signed all the reverse lookup records (in-addr.arpa) that are delegated to it from the Internet Assigned Numbers Authority (IANA).[27] ARIN is also signing their reverse zones.[28] In February 2007 TDC became the first Swedish ISP to start offering this feature to its customers.[29]

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,[30] the Internet Systems Consortium introduced another on March 27 of the same year,[31] while ICANN themselves announced a third on February 17, 2009.[32]

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.[33] 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".[34] On June 23, 2010, 13 registrars were listed as offering DNSSEC records for .ORG domains.[35]

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,[36] 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.[37] This goal was achieved on-schedule[38] and Verisign's DNSSEC VP, Matt Larson, won InfoWorld's Technology Leadership Award for 2011 for his role in advancing DNSSEC.[39][40]

Deployment at the DNS root

DNSSEC was first deployed at the root level on July 15, 2010.[41] 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:

Planning

In September 2008, ICANN and VeriSign each published implementation proposals[42] and in October, the National Telecommunications and Information Administration (NTIA) asked the public for comments.[43] 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.[44]

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.[45] 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.[45] 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.[46] 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.[47][48] Country code top-level domains were able to deposit keys starting in May 2010.[49] As of November 2011 more than 25% of top-level domains are signed with DNSSEC.[50]

Implementation

On January 25, 2010, the L (ell) root server began serving a Deliberately Unvalidatable Root Zone (DURZ). The zone uses signatures of a SHA-2 (SHA-256) hash created using the RSA algorithm, as defined in RFC 5702.[51][52][53] As of May 2010, all thirteen root servers have begun serving the DURZ.[46] 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.[41]

Deployment at the TLD level

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

DNSSEC Lookaside Validation

In March 2006, the Internet Systems Consortium introduced the DNSSEC Lookaside Validation registry.[54] 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.[55] 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, a validator that supports it is needed, such as BIND or Unbound, configured with a trust anchor for a DLV zone. This zone contains DLV records;[56] 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.[57]

Gaps in the chain of trust, such as unsigned top-level domains or registrars that do not support DNSSEC delegations, meant administrators of lower-level domains could use DLV to allow their DNS data to be validated by resolvers which had been configured to use DLV. This may have hindered DNSSEC deployment by taking pressure off registrars and TLD registries to properly support DNSSEC. DLV also adds complexity by adding more actors and code paths for DNSSEC validation. Further uncertainty arises because not all validating resolvers support or use DLV. Clients querying one resolver might get DLV-validated responses while clients using a different validating resolver would not.

DLV was not widely used. By May 2015, ISC's DLV registry contained under 5,000 domain names and fewer than 10% of these had an unsigned parent domain name. ISC has announced plans to decommission its DLV registry.[58] It is not clear yet if or when DLV support will be removed from BIND and other implementations of validating resolvers.

DNSSEC deployment initiative by the U.S. federal government

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[59] 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[60][61] 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.[62] 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.[63] 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."[64]

Deployment in resolvers

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

According to CircleID's study, the proportion of clients who exclusively use DNS resolvers that perform DNSSEC validation has risen to 8.3% in May 2013.[68] About half of these clients were using Google's public DNS resolver.

Google Public DNS

Google Public DNS is a freely provided, public DNS service, fully supporting DNSSEC.

On its launch in 2009, Google Public DNS did not support DNSSEC. RRSIG records of course could be queried, but the AD flag (Authenticated Data, meaning the server was able to validate signatures for all of the data) was never set.

On January 28, 2013, Google's DNS servers silently started providing DNSSEC validation information,[69] but only if the client explicitly set the DNSSEC OK (DO) flag on its query.[68]

On May 6, 2013, Google Public DNS enabled the DNSSEC validation by default; meaning all queries will be validated unless clients explicitly opt out.[70]

Issues

It has been known to break proper MX record lookup on Microsoft Exchange 2013 and older causing #550 4.4.7 QUEUE.Expired errors. [71]

IETF standards

Tools

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

See also

References

  1. ↑ Interview with Dan Kaminsky on DNSSEC (25 Jun 2009) Kaminsky interview: DNSSEC addresses cross-organizational trust and security
  2. 1 2 3 "Understanding DNSSEC in Windows". Microsoft. October 7, 2009. The Windows DNS client is a stub resolver...
  3. 1 2 3 "DNS Security Extensions (DNSSEC)". Microsoft. October 21, 2009. The DNS client in Windows Server 2008 R2 and Windows® 7 is a non-validating security-aware stub resolver.
  4. 1 2 3 4 "RFC 4033: DNS Security Introduction and Requirements". The Internet Society. March 2005: 12.
  5. 1 2 Muñoz Merino, Pedro J.; García-Martínez, Alberto; Organero, Mario Muñoz; Kloos, Carlos Delgado (2006). Meersman, Robert; Tari, Zahir; Herrero, Herrero Martín, eds. Enabling Practical IPsec Authentication for the Internet (PDF). On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops 1. Springer.
  6. ↑ "Domain Name System Security (DNSSEC) Algorithm Numbers". IANA. 2010-07-12. Retrieved 2010-07-17.
  7. ↑ "RFC-6944". IETF.
  8. ↑ http://www.root-dnssec.org/
  9. ↑ http://www.v3.co.uk/v3-uk/news/2039287/verisign-adds-dnssec-com-domain-boost-online-security/
  10. ↑ "RFC 4033: DNS Security Introduction and Requirements". The Internet Society. March 2005: 11. Stub resolvers, by definition, are minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution to a recursive name server. An earlier definition was given in an earlier RFC: Robert Braden (October 1989). "RFC 1123 - Requirements for Internet Hosts -- Application and Support". IETF (Internet Engineering Task Force): 74. A "stub resolver" relies on the services of a recursive name server [...]
  11. ↑ root-anchors
  12. ↑ IETF: DNS-based Authentication of Named Entities (dane)
  13. ↑ Grepular: DNSSEC Will Kill Commercial CAs
  14. ↑ "ImperialViolet". Retrieved 2011-11-26.
  15. ↑ "chromium git". Retrieved 2013-03-09.
  16. ↑ "DNSSEC/TLSA Validator".
  17. ↑ Bugzilla@Mozilla: Bug 672600 - Use DNSSEC/DANE chain stapled into TLS handshake in certificate chain validation
  18. ↑ "Using the Domain Name System for System Break-Ins" by Steve Bellovin, 1995
  19. ↑ Breaking DNSSEC Daniel J. Bernstein, 2009
  20. ↑ Albitz, Paul; Cricket Liu (April 2001). DNS and BIND (4e. ed.). O'Reilly Media, Inc. ISBN 978-0-596-00158-2.
  21. ↑ Split-View DNSSEC Operational Practices
  22. ↑ https://blog.cloudflare.com/dnssec-done-right/
  23. ↑ U.S. National Strategy to Secure Cyberspace, p. 30 February 2003
  24. ↑ Metzger, Perry, William Allen Simpson, and Paul Vixie. "Improving TCP security with robust cookies" (PDF). Usenix. Retrieved 2009-12-17.
  25. ↑ https://ccnso.icann.org/de/node/7603
  26. ↑ Electronic Privacy Information Center (EPIC) (May 27, 2008). DNSSEC
  27. ↑ RIPE NCC DNSSEC Policy
  28. ↑ ARIN DNSSEC Deployment Plan
  29. ↑ Eklund-Löwinder, Anne-Marie (12 February 2012). "[dns-wg] Swedish ISP TCD Song Adopts DNSSEC". dns-wg mailing list. RIPE NCC. Retrieved 2 December 2012.
  30. ↑ dns-wg archive: Signed zones list
  31. ↑ ISC Launches DLV registry to kick off worldwide DNSSEC deployment
  32. ↑ Interim Trust Anchor Repository
  33. ↑ .ORG is the first open TLD signed with DNSSEC
  34. ↑ Sean Michael Kerner. ".ORG the Most Secure Domain?". www.internetnews.com. Retrieved 2008-09-27.
  35. ↑ ".ORG Registrar List — with DNSSEC enabled at the top". Retrieved 2010-06-23.
  36. ↑ VeriSign: We will support DNS security in 2011
  37. ↑ VeriSign: Major internet security update by 2011
  38. ↑ .com Domain Finally Safe
  39. ↑ Verisign's Matt Larson Wins 2011 InfoWorld Technology Leadership Award
  40. ↑ The InfoWorld 2011 Technology Leadership Awards
  41. 1 2 "Root DNSSEC Status Update, 2010-07-16". 16 July 2010.
  42. ↑ Singel, Ryan (October 8, 2006). "Feds Start Moving on Net Security Hole". Wired News (CondéNet). Retrieved 2008-10-09.
  43. ↑ "Press Release: NTIA Seeks Public Comments for the Deployment of Security Technology Within the Internet Domain Name System" (Press release). National Telecommunications and Information Administration, U.S. Department of Commerce. October 9, 2008. Retrieved 2008-10-09.
  44. ↑ "Commerce Department to Work with ICANN and VeriSign to Enhance the Security and Stability of the Internet's Domain Name and Addressing System" (Press release). National Institute of Standards and Technology. 3 June 2009.
  45. 1 2 "DNSSEC for the Root Zone" (PDF).
  46. 1 2 Hutchinson, James (6 May 2010). "ICANN, Verisign place last puzzle pieces in DNSSEC saga". NetworkWorld.
  47. ↑ "DNSSEC to become standard on .ORG domains by end of June". Retrieved 2010-03-24.
  48. ↑ The Inquirer: Verisign deploys DNSSEC on .com TLD
  49. ↑ More security for root DNS servers Heise Online, 24 March 2010
  50. ↑ CircleID: DNSSEC Update from ICANN 42 in Dakar
  51. ↑ "DNSSEC Root Zone High Level Technical Architecture" (PDF).
  52. ↑ RFC 5702, §2.1. "RSA public keys for use with RSA/SHA-256 are stored in DNSKEY resource records (RRs) with the algorithm number 8."
  53. ↑ RFC 5702, §3.1. "RSA/SHA-256 signatures are stored in the DNS using RRSIG resource records (RRs) with algorithm number 8."
  54. ↑ ISC Launches DLV registry to kick off worldwide DNSSEC deployment
  55. ↑ RFC 5011, "Automated Updates of DNS Security (DNSSEC) Trust Anchors"
  56. ↑ RFC 4431, "The DNSSEC Lookaside Validation (DLV) DNS Resource Record"
  57. ↑ RFC 5074, "DNSSEC Lookaside Validation (DLV)"
  58. ↑ https://ripe70.ripe.net/wp-content/uploads/presentations/81-RIPE-DLV-timeline-20150513.pdf
  59. ↑ Department of Homeland and Security wants master key for DNS Heise News, 30 March 2007
  60. ↑ Analysis: of Owning the keys to the Internet UPI, April 21, 2007
  61. ↑ UPI Analysis: Owning the keys to the Internet March 24, 2011 - First link is dead, this is believed to be the same content
  62. ↑ DNSSEC Deployment Initiative Newsletter - Volume 1, Number 2, June 2006
  63. ↑ Memorandum For Chief Information Officers Executive Office Of The President — Office Of Management And Budget, 22 August 2008
  64. ↑ Feds tighten security on .gov Network World, 22 September 2008
  65. ↑ Comcast Blog - DNS Security Rollout Begins, October 18, 2010
  66. ↑ Comcast DNSSEC Public Service Announcement Video, October 18, 2010
  67. ↑ Comcast Completes DNSSEC Deployment, January 11, 2012
  68. 1 2 Geoff Huston: DNS, DNSSEC and Google's Public DNS Service (CircleID)
  69. ↑ Google's Public DNS does DNSSEC validation nanog mailing list archives, 29 January 2013
  70. ↑ Google Public DNS Now Supports DNSSEC Validation Google Code Blog, 1 June 2013
  71. ↑ http://forums.comcast.com/t5/E-Mail-and-Xfinity-Connect-Help/Domains-unable-to-send-to-Comcast-net-from-Exchange-servers/td-p/1176693
  72. ↑ Seshadri, Shyam (11 November 2008). "DNSSEC on Windows 7 DNS client". Port 53. Microsoft.
  73. ↑ DNSSEC in Windows Server

Further reading

External links

This article is issued from Wikipedia - version of the Friday, January 29, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.