Domain Name System Security Extensions: Internet Protocol Suite

Internet Protocol Suite
Application Layer
BGP DHCP DNS FTP HTTP IMAP
IRC LDAP MGCP NNTP NTP POP
RIP RPC RTP SIP SMTP SNMP
SSH Telnet TLS/SSL XMPP
(more)
Transport Layer
TCP UDP DCCP SCTP RSVP ECN
(more)
Internet Layer
IP (IPv4, IPv6) ICMP ICMPv6 IGMP
IPsec
(more)
Link Layer
ARP/InARP NDP OSPF Tunnels (L2TP)
PPP Media Access Control (Ethernet, DSL,
ISDN, FDDI) (more)
Domain Name System Security Extensions
From Wikipedia, the free encyclopedia
(Redirected from DNSSEC)
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.
Contents
1 Overview
2 How it works
2.1 Records
2.1.1 Algorithms
2.2 The lookup procedure
2.2.1 Recursive name servers
2.2.2 Stub resolvers
2.3 Trust anchors and authentication chains
2.4 Signatures and zone signing
2.5 Key management
3 History
4 Zone enumeration issue, controversy, and
NSEC3
4.1 Why DNS zone data is normally kept
private
4.2 DNSSEC reveals zone data
4.3 Initial Reaction
4.4 On-line Signing
4.5 NSEC3
5 Deployment
5.1 Early deployments
5.2 Deployment at the DNS root
5.2.1 Planning
5.2.2 Implementation
5.3 Deployment of alternative trust anchors
to the DNS root
5.4 DNSSEC deployment initiative by the
U.S. federal government
5.5 DNSSEC deployment in the U.S. federal
government
17-03-2011 Domain Name System Security Extensi
http://en.wikipedia.org/wiki/DNSSEC 1/16
5.6 DNSSEC deployment by ISPs
6 Tools
7 See also
8 References
9 External links
9.1 Organizations / Websites
9.2 Standards
9.3 Other documents
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 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 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 by several difficulties:
The need to design a backward-compatible standard that can scale to the size of the Internet
Prevention of "zone enumeration" (see below) where desired
Deployment of DNSSEC implementations across a wide variety of DNS servers and resolvers (clients)
Disagreement among implementers over who should own the top-level domain root keys
Overcoming the perceived complexity of DNSSEC and DNSSEC deployment
Some of these problems are in the process of being resolved, and deployment in various domains is in progress.
How it works
DNSSEC works by digitally signing these records for DNS lookup using public-key cryptography. The correct
DNSKEY record is authenticated via a chain of trust, starting with a set of verified public keys for the DNS root
zone which is the trusted third party.
Records
DNS is implemented by the use of several resource records. To implement DNSSEC, several new DNS record
types were created or adapted to use with DNSSEC:
RRSIG
DNSKEY
DS
NSEC
NSEC3
NSEC3PARAM
When DNSSEC is used, each answer to a DNS lookup will contain an RRSIG DNS record, in addition to the
record type that was requested. The RRSIG record is a digital signature of the answer DNS resource record
set. The digital signature can be verified by locating the correct public key found in a DNSKEY record. The DS
record is used in the authentication of DNSKEYs in the lookup procedure using the chain of trust. NSEC and
NSEC3 records are used for robust resistance against spoofing.
Algorithms
DNSSEC was designed to be extensible so that as attacks are discovered against existing algorithms, new ones
can be introduced in a backward-compatible fashion. As of this writing (July 2009), the following security
algorithms are defined that are most often used:
[2]
Algorithm Field Algorithm Source
0 Reserved
RFC 4034
1 RSA/MD5
3 DSA/SHA-1
5 RSA/SHA-1
7 RSASHA1-NSEC3-SHA1 RFC 5155
8 RSA/SHA-256
RFC 5702
10 RSA/SHA-512
12 GOST R 34.10-2001 RFC 5933
The lookup procedure
From the results of a DNS lookup, a security-aware DNS resolver can determine if the answer it received was
secure, or if it was otherwise insecure and the authoritative name server for the domain being queried doesn't
support DNSSEC or if there is some sort of error. The lookup procedure is different for recursive name servers
such as those of many ISPs, and for stub resolvers such as those included by default in mainstream operating
systems.
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
[3]
and generic top-level domains (like .com) is underway.
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."
[4]
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.
[5]
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."
[5]
It can also potentially perform its own
signature validation by setting the Checking Disabled (CD) bit in its query messages.
[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
th
July 2010.
[6]
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, but reducing the size of
the RRSIG/DNSKEY records.
When a new KSK is created, the DS record must be transferred to the parent zone and published there. The
DS records use a message digest of the KSK instead of the complete key in order to keep the size of the
records small. This is helpful for zones such as the .com domain, which are very large. The procedure to update
DS keys in the parent zone is also simpler than earlier DNSSEC versions that required DNSKEY records to be
in the parent zone.
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.
[7]
The initial RFC 2065 was published by the IETF in 1997, and initial attempts to implement that specification led
to a revised (and believed fully workable) specification in 1999 as IETF RFC 2535. Plans were made to deploy
DNSSEC based on RFC 2535.
Unfortunately, the IETF RFC 2535 specification had very significant problems scaling up to the full Internet; by
2001 it became clear that this specification was unusable for large networks. In normal operation DNS servers
often get out of sync with their parents. This isn't usually a problem, but when DNSSEC is enabled, this out-of-
sync data could have the effect of a serious self-created denial of service. The original DNSSEC required a
complex six-message protocol and a lot of data transfers to perform key changes for a child (DNS child zones
had to send all of their data up to the parent, have the parent sign each record, and then send those signatures
back to the child for the child to store in a SIG record). Also, public key changes could have absurd effects; for
example, if the ".com" zone changed its public key, it would have to send 22 million records (because it would
need to update all of the signatures in all of its children). Thus, DNSSEC as defined in RFC 2535 could not
scale up to the Internet.
The IETF fundamentally modified DNSSEC, which is called DNSSEC-bis when necessary to distinguish it from
the original DNSSEC approach of RFC 2535. This new version uses "delegation signer (DS) resource records"
to provide an additional level of indirection at delegation points between a parent and child zone. In the new
approach, when a child's master public key changes, instead of having to have six messages for every record in
the child, there is one simple message: the child sends the new public key to its parent (signed, of course).
Parents simply store one master public key for each child; this is much more practical. This means that a little
data is pushed to the parent, instead of massive amounts of data being exchanged between the parent and
children. This does mean that clients have to do a little more work when verifying keys. More specifically,
verifying a DNS zone's KEY RRset requires two signature verification operations instead of the one required by
RFC 2535 (there is no impact on the number of signatures verified for other types of RRsets). Most view this as
a small price to pay, since it changes DNSSEC so it is more practical to deploy.
Zone enumeration issue, controversy, and NSEC3
Although the goal of DNSSEC is to increase security, DNSSEC as defined in RFCs 4033 through 4035
introduces a new problem that many believe is a new security vulnerability: the zone enumeration (aka zone
walking) issue. DNSSEC forces the exposure of information that by normal DNS best practice is kept private.
NSEC3 (RFC 5155) was developed to address this issue; it was released in March 2008. NSEC3 mitigates,
but does not eliminate, zone enumeration, since it is possible to exhaustively search the set of all possible names
in a zone.
[8]
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.
[9]
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.
[citation needed]
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. Research has produced recommendations to properly combine these
two DNS features.
[10]
The reason DNSSEC introduced this problem is 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 wasor should bepublic. However, registrars and
many large organizations told the working group members that DNSSEC as currently defined was unacceptable,
and that they would not or legally could not deploy it.
On-line Signing
One approach to preventing zone enumeration was codified in RFC 4470. Instead of signing the not-found
responses in advance, a not-found response is generated for each query. For example, if a query is received for
'b.example.com', instead of serving a previously signed response saying there are no names between
'a.example.com' and 'mail.example.com', which reveals the existence of 'mail.example.com', the response might
be that 'there are no names between b.example.com and ba.example.com'. If the next query asks about
'ba.example.com', the response might be 'there are no names between ba.example.com and baa.example.com'.
This makes enumerating the entire zone impractical.
This approach has some disadvantages. It requires a signing key to be kept on-line and accessible to each DNS
server. Many zone signing keys are kept on-line anyway to support automatic resigning or dynamic zone
updates, but these functions are needed only on a single master DNS server, while to support on-line signing the
zone signing key must be kept on each authoritative DNS server. Some authoritative servers must be accessible
from the Internet and ideally these will be widely dispersed, making it difficult to keep the keys under control.
Care is also required to prevent an attacker flooding the DNS server with requests for bogus names, denying
service to legitimate users.
NSEC3
After deliberation, an extension was developed: "DNSSEC Hashed Authenticated Denial of Existence"
(informally called "NSEC3"). In this approach, DNSSEC-aware servers can choose to send an "NSEC3"
record instead of an NSEC record when a record is not found. The NSEC3 record is signed, but instead of
including the name directly (which would enable zone enumeration), the NSEC3 record includes a
cryptographically hashed value of the name. The NSEC3 record includes both a hash after a number of
iterations and an optional salt. 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 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.
[11]
Widescale deployment of DNSSEC could resolve many other security problems as well, such
as secure key distribution for e-mail addresses.
However, the DNSSEC specification has been challenging to develop. NSEC3, one of its critical pieces, was
only formally defined in an RFC in March 2008, and it is not yet widely deployed.
DNSSEC deployment in large-scale networks is also challenging. Ozment and Schechter observe that
DNSSEC (and other technologies) has a "bootstrap problem": users typically only deploy a technology if they
receive an immediate benefit, but if a minimal level of deployment is required before any users receive a benefit
greater than their costs (as is true for DNSSEC), it is difficult to deploy. DNSSEC can be deployed at any level
of a DNS hierarchy, but it must be widely available in a zone before many others will want to adopt it. DNS
servers must be updated with software that supports DNSSEC, and DNSSEC data must be created and added
to the DNS zone data. A TCP/IP-using client must have their DNS resolver (client) updated before it can use
DNSSEC's capabilities. What is more, any resolver must have, or have a way to acquire, at least one public key
that it can trust before it can start using DNSSEC.
DNSSEC implementation can add significant load to some DNS servers. Common DNSSEC-signed responses
are far larger than the default UDP size of 512 bytes. In theory, this can be handled through multiple IP
fragments, but many "middleboxes" in the field do not handle these correctly. This leads to the use of TCP
instead. Yet many current TCP implementations store a great deal of data for each TCP connection; heavily
loaded servers can run out of resources simply trying to respond to a larger number of (possibly bogus)
DNSSEC requests. Some protocol extensions, such as TCP Cookie Transactions, have been developed to
reduce this loading.
[12]
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), Puerto Rico (.pr) and Sweden (.se),
who use DNSSEC for their country code top-level domains;
[13]
RIPE NCC, who have signed all the reverse
(in-addr.arpa) that are delegated to it from the Internet Assigned Numbers Authority (IANA).
[14]
ARIN is also
signing their reverse zones.
[15]
TDC was the first ISP to implement this feature in Sweden.
IANA has been publicly testing a sample signed root (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
(http://www.dnssec.net/projects) maintains a list of such projects. There is also a Google Map of World Wide
DNSSEC Deployment (http://maps.google.com/maps?
q=Google%20Map%20of%20World%20Wide%20DNSSEC%20Deployment) .
On February 24, 2009, VeriSign announced that they would deploy DNSSEC across all their top level domains
(.com, .net, etc.) within 24 months.
[16]
On June 2, 2009, the Public Interest Registry signed the .org zone.
[17]
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".
[18]
On June 23,
2010, 13 registrars were listed as offering DNSSEC records for .ORG domains.
[19]
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.
[20]
Deployment at the DNS root
DNSSEC was first deployed at the root level on July 15, 2010.
[21]
This is expected to greatly simplify the
deployment of DNSSEC resolvers, since the root trust anchor can be used to validate any DNSSEC zone that
has a complete chain of trust from the root. Since the chain of trust must be traced back to a trusted root without
interruption in order to validate, trust anchors must still be configured for secure zones if any of the zones above
them are not secure. For example if the zone "signed.example.org" was secured but the "example.org"-zone was
not, then, even though the ".org"-zone and the root are signed a trust anchor has to be deployed in order to
validate the zone.
Political issues surrounding signing the root have been a continuous concern, primarily about some central issues:
Other countries are concerned about U.S. control over the Internet, and may reject any centralized
keying for this reason.
Some governments might try to ban DNSSEC-backed encryption key distribution.
Planning
In September 2008, ICANN and VeriSign each published implementation proposals
[22]
and in October, the
National Telecommunications and Information Administration (NTIA) asked the public for comments.
[23]
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.
[24]
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.
[25]
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.
[25]
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.
[26]
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 is expected to implement DNSSEC in June 2010, followed by .com, .net, and .edu
later in 2010 and 2011.
[27]
Country code top-level domains will be able to deposit keys starting in May
2010.
[28]
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.
[29][30][31]
As of May 2010, all thirteen root servers have begun serving the DURZ.
[26]
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 (https://data.iana.org/root-anchors/) .
[21]
Deployment of alternative trust anchors to the DNS root
Due to delays with signing the root, there have been several proposed and deployed alternative trust anchors.
1. The IKS Jena has been running an alternative trust anchor system called the "DLV registry" since January
19, 2006.
[32]
It uses DLV records (a renamed DS record) that can be looked up by querying
<domainname>.dnssec.iks-jena.de. This is a spidering registry which aims to get as much validation as
possible.
[33]
2. The Internet Systems Consortium has been running an alternative trust anchor system called the "DLV
registry" since March 27, 2006.
[34]
It uses DLV records (a renamed DS record) that can be looked up
by querying <domainname>.dlv.isc.org. Support for the ISC DLV registry has been supported in BIND
since version 9.3.3.
3. Samuel Weiler proposed an alternative trust anchor using TA records in April 2004,
[35]
but this proposal
has yet to be implemented.
4. ICANN announced an Interim Trust Anchor Repository on February 17, 2009.
[36]
This system will use
DS records, but will only be available to top level domains.
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
[37]
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
[38]
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.
[39]
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.
[40]
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."
[41]
DNSSEC deployment by ISPs
Several ISPs have started to deploy DNSSEC-validating DNS recursive resolvers. Comcast became the first
major ISP to do so in the United States on October 18, 2010.
[42][43]
Tools
DNSSEC deployment requires software on the server and client side. Some of the tools that support DNSSEC
include:
Windows 7 and Windows Server 2008 R2 include a "security-aware" stub resolver that is able to
differentiate between secure and non-secure responses by a recursive name server.
[44][45]
BIND, the most popular DNS name server (which includes dig). Version 9.3 implemented the newer
DNSSEC-bis (DS records) although it did not support NSEC3 records. BIND 9.6 was released in
December 2008 and has full support for NSEC3 records.
Drill (http://www.nlnetlabs.nl/projects/drill/) is a DNSSEC-enabled dig-like tool bundled with ldns
(http://www.nlnetlabs.nl/projects/ldns/) .
Drill extension for Firefox (http://www.nlnetlabs.nl/projects/drill/drill_extension.html) adds to Mozilla
Firefox the ability to determine if a domain can be verified using DNSSEC.
DNSSEC-Tools (http://www.dnssec-tools.org/) aims at providing easy to use tools for helping all types
of administrators and users make use of DNSSEC. It offers tools for administrators of Authoritative
Zones (http://www.dnssec-tools.org/wiki/index.php/Authoritative_Zone_Administrator) , Authoritative
Server (http://www.dnssec-tools.org/wiki/index.php/Authoritative_Server) , and Recursive Servers
(http://www.dnssec-tools.org/wiki/index.php/Recursive_Server) as well as a library and tools for
Application Developers (http://www.dnssec-
tools.org/wiki/index.php/DNSSEC_Application_Development) and existing patches for extending
common applications (http://www.dnssec-tools.org/wiki/index.php/DNSSEC_Applications) .
Zone Key Tool (http://www.hznet.de/dns/zkt/) 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 (http://www.unbound.net/) is a DNS name server that was written from the ground up to be
designed around DNSSEC concepts.
GbDns (http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/) is a compact, easy-to-install
DNSSEC name server for Microsoft Windows.
mysqlBind The GPL OSS for DNS ASPs now supports DNSSEC.
OpenDNSSEC is a designated DNSSEC signer tool using PKCS#11 to interface with Hardware
Security Modules.
SecSpider (http://secspider.cs.ucla.edu/) tracks DNSSEC deployment, monitors zones, and provides a
list of observed public keys.
DNSViz (http://dnsviz.net/) and DNSSEC Analyzer (http://dnssec-analyzer.verisignlabs.com) are Web-
based tools to visualize the DNSSEC authentication chain of a domain.
DNSSEC Validator (http://www.dnssec-validator.cz/) is a Mozilla Firefox addon for visualization of
DNSSEC status of the visited domain name.
See also
EDNS - extension to DNS to allow for the larger packets DNSSEC uses and the DO flag bit
TSIG - used to securely authenticate transactions between the resolver and name servers
DNSCurve - light-weight encryption/authentication between name servers and resolvers.
RPKI - a similar technology applied to Internet routing registry records
References
1. ^ Interview with Dan Kaminsky on DNSSEC (25 Jun 2009) Kaminsky interview: DNSSEC addresses cross-
organizational trust and security
(http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci1360143,00.html)
2. ^ "Domain Name System Security (DNSSEC) Algorithm Numbers" (http://www.iana.org/assignments/dns-sec-
alg-numbers/dns-sec-alg-numbers.xhtml) . IANA. 2010-07-12. http://www.iana.org/assignments/dns-sec-alg-
numbers/dns-sec-alg-numbers.xhtml. Retrieved 2010-07-17.
3. ^ http://www.root-dnssec.org/
4. ^ RFC 4033: DNS Security Introduction and Requirements (http://tools.ietf.org/html/rfc4033#section-7) . The
Internet Society. March 2005. p. 11. http://tools.ietf.org/html/rfc4033#section-7. "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 (http://tools.ietf.org/html/rfc1123#page-74)
. IETF (Internet Engineering Task Force). p. 74. http://tools.ietf.org/html/rfc1123#page-74. "A "stub resolver"
relies on the services of a recursive name server [...]".
5. ^
a

b

c
RFC 4033: DNS Security Introduction and Requirements (http://tools.ietf.org/html/rfc4033#page-12) .
The Internet Society. March 2005. p. 12. http://tools.ietf.org/html/rfc4033#page-12.
6. ^ root-anchors (https://data.iana.org/root-anchors/)
7. ^ "Using the Domain Name System for System Break-Ins" (http://citeseer.ist.psu.edu/bellovin95using.html) by
Steve Bellovin, 1995
8. ^ Breaking DNSSEC (http://cr.yp.to/talks/2009.08.10/slides.pdf) Daniel J. Bernstein, 2009
9. ^ Albitz, Paul; Cricket Liu (April 2001). DNS and BIND (http://oreilly.com/catalog/9780596001582/) (4e. ed.).
O'Reilly Media, Inc.. ISBN 9780596001582. http://oreilly.com/catalog/9780596001582/.
10. ^ Split-View DNSSEC Operational Practices (http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-
view)
11. ^ U.S. National Strategy to Secure Cyberspace (http://georgewbush-
whitehouse.archives.gov/pcipb/cyberspace_strategy.pdf) , p. 30 February 2003
12. ^ Metzger, Perry, William Allen Simpson, and Paul Vixie. "Improving TCP security with robust cookies"
(http://www.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf) . Usenix.
http://www.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf. Retrieved 2009-12-17.
13. ^ Electronic Privacy Information Center (EPIC) (May 27, 2008). DNSSEC (http://epic.org/privacy/dnssec/)
14. ^ RIPE NCC DNSSEC Policy (http://www.ripe.net/docs/ripe-359.html)
15. ^ ARIN DNSSEC Deployment Plan (https://www.arin.net/resources/dnssec/)
16. ^ VeriSign: We will support DNS security in 2011 (http://www.networkworld.com/news/2009/022409-
verisign-dns-security.html?page=1)
17. ^ .ORG is the first open TLD signed with DNSSEC (http://pir.org/index.php?
db=content/News&tbl=Press&id=25)
18. ^ Sean Michael Kerner. ".ORG the Most Secure Domain?"
(http://www.internetnews.com/security/article.php/3774131) . www.internetnews.com.
http://www.internetnews.com/security/article.php/3774131. Retrieved 2008-09-27.
19. ^ ".ORG Registrar List - with DNSSEC enabled at the top" (http://www.pir.org/get/registrars?
order=field_dnssec_value&sort=desc) . http://www.pir.org/get/registrars?
order=field_dnssec_value&sort=desc. Retrieved 2010-06-23.
20. ^ VeriSign: Major internet security update by 2011
(http://news.zdnet.co.uk/security/0,1000000189,39877966,00.htm)
21. ^
a

b
"Root DNSSEC Status Update, 2010-07-16" (http://www.root-dnssec.org/2010/07/16/status-update-2010-
07-16/) . 16 July 2010. http://www.root-dnssec.org/2010/07/16/status-update-2010-07-16/.
22. ^ Singel, Ryan (October 8, 2006). "Feds Start Moving on Net Security Hole"
(http://blog.wired.com/27bstroke6/2008/10/feds-take-step.html) . Wired News (CondNet).
http://blog.wired.com/27bstroke6/2008/10/feds-take-step.html. Retrieved 2008-10-09.
23. ^ National Telecommunications and Information Administration, U.S. Department of Commerce (October 9,
2008). "Press Release: NTIA Seeks Public Comments for the Deployment of Security Technology Within the
Internet Domain Name System" (http://www.ntia.doc.gov/press/2008/DNSSEC_081009.html) . Press release.
http://www.ntia.doc.gov/press/2008/DNSSEC_081009.html. Retrieved 2008-10-09.
24. ^ National Institute of Standards and Technology (3 June 2009). "Commerce Department to Work with ICANN
and VeriSign to Enhance the Security and Stability of the Internet's Domain Name and Addressing System"
(http://www.nist.gov/public_affairs/releases/dnssec_060309.html) . Press release.
http://www.nist.gov/public_affairs/releases/dnssec_060309.html.
25. ^
a

b
"DNSSEC for the Root Zone" (http://www.ripe.net/ripe/meetings/ripe-59/presentations/abley-dnssec-root-
zone.pdf) . http://www.ripe.net/ripe/meetings/ripe-59/presentations/abley-dnssec-root-zone.pdf.
26. ^
a

b
Hutchinson, James (6 May 2010). ICANN, Verisign place last puzzle pieces in DNSSEC saga
(http://www.networkworld.com/news/2010/050610-icann-verisign-place-last-puzzle.html?hpg1=bn) .
NetworkWorld. http://www.networkworld.com/news/2010/050610-icann-verisign-place-last-puzzle.html?
hpg1=bn.
27. ^ "DNSSEC to become standard on .ORG domains by end of June"
(http://www.thetechherald.com/article.php/201010/5366/DNSSEC-to-become-standard-on-ORG-domains-by-
end-of-June) . http://www.thetechherald.com/article.php/201010/5366/DNSSEC-to-become-standard-on-ORG-
domains-by-end-of-June. Retrieved 2010-03-24.
28. ^ More security for root DNS servers (http://www.h-online.com/security/news/item/More-security-for-root-
DNS-servers-962569.html) Heise Online, 24 March 2010
29. ^ "DNSSEC Root Zone High Level Technical Architecture" (http://www.root-dnssec.org/wp-
content/uploads/2010/06/draft-icann-dnssec-arch-v1dot4.pdf) . http://www.root-dnssec.org/wp-
content/uploads/2010/06/draft-icann-dnssec-arch-v1dot4.pdf.
30. ^ 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."
31. ^ RFC 5702, 3.1. "RSA/SHA-256 signatures are stored in the DNS using RRSIG resource records (RRs) with
algorithm number 8."
32. ^ dns-wg archive: Signed zones list (http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00053.html)
33. ^ Good practices guide for deploying DNSSEC, p. 25
(http://www.enisa.europa.eu/act/res/technologies/tech/gpgdnssec/at_download/fullReport)
34. ^ ISC Launches DLV registry to kick off worldwide DNSSEC deployment (https://www.isc.org/node/62)
35. ^ Deploying DNSSEC Without a Signed Root (http://www.watson.org/~weiler/INI1999-19.pdf)
36. ^ Interim Trust Anchor Repository (https://itar.iana.org/)
37. ^ Department of Homeland and Security wants master key f or DNS
(http://www.heise.de/english/newsticker/news/87655) Heise News, 30 March 2007
38. ^ Analysis: of Owning the keys to the Internet
(http://www.upi.com/Security_Terrorism/Analysis/2007/04/12/analysis_owning_the_keys_to_the_internet/) UPI,
April 21, 2007
39. ^ DNSSEC Deployment Initiative Newsletter - Volume 1, Number 2 (http://www.dnssec-
deployment.org/news/dnssecthismonth/200606-dnssecthismonth/) , June 2006
40. ^ Memorandum For Chief Information Officers (http://www.whitehouse.gov/omb/memoranda/fy2008/m08-
23.pdf) Executive Office Of The President - Office Of Management And Budget, 22 August 2008
41. ^ Feds tighten security on .gov (http://www.networkworld.com/news/2008/092208-government-web-
security.html) Network World, 22 September 2008
42. ^ Comcast Blog - DNS Security Rollout Begins (http://blog.comcast.com/2010/10/dns-security-rollout-
begins.html) , October 18, 2010
43. ^ Comcast DNSSEC Public Service Announcement Video (http://www.dnssec.comcast.net/dnssec-video.htm)
, October 18, 2010
44. ^ Seshadri, Shyam (11 November 2008). "DNSSEC on Windows 7 DNS client"
(http://blogs.technet.com/sseshad/archive/2008/11/11/dnssec-on-windows-7-dns-client.aspx) . Port 53.
Microsoft. http://blogs.technet.com/sseshad/archive/2008/11/11/dnssec-on-windows-7-dns-client.aspx.
45. ^ DNSSEC in Windows Server (https://www.dns-oarc.net/files/workshop-2006/Microsoft-DNSSEC.pdf)
External links
Organizations / Websites
DNSSEC (http://www.dnssec.net/) - DNSSEC information site: DNSSEC.net
DNSEXT (http://www.ietf.org/html.charters/dnsext-charter.html) DNS Extensions IETF Working Group
CircleID - News and Opinions on all DNSSEC related issues (http://www.circleid.com/topics/dnssec/)
DNSSEC-Tools Project (http://www.dnssec-tools.org)
DNSSEC Deployment Coordination Initiative (http://www.dnssec-deployment.org)
DNSSEC Deployment Team (http://www.root-dnssec.org)
Standards
RFC 2535 Domain Name System Security Extensions
RFC 3833 A Threat Analysis of the Domain Name System
RFC 4033 DNS Security Introduction and Requirements (DNSSEC-bis)
RFC 4034 Resource Records for the DNS Security Extensions (DNSSEC-bis)
RFC 4035 Protocol Modifications for the DNS Security Extensions (DNSSEC-bis)
RFC 4398 Storing Certificates in the Domain Name System (DNS)
RFC 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing
RFC 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
RFC 4641 DNSSEC Operational Practices
RFC 5155 DNSSEC Hashed Authenticated Denial of Existence
Other documents
A Fundamental Look at DNSSEC, Deployment, and DNS Security Extensions
(http://www.circleid.com/posts/dnssec_deployment_and_dns_security_extensions/) by Geoff Huston
"Using the Domain Name System for System Break-Ins"
(http://www.cs.columbia.edu/~smb/papers/dnshack.pdf) by Steve Bellovin, 1995
A short timeline of DNSSEC (http://www.nlnetlabs.nl/dnssec/history.html) by Miek Gieben
Enabling secure name resolution using DNSSEC for various applications
(http://wiki.archlinux.org/index.php/DNSSEC)
DNSSEC Howto (http://www.nlnetlabs.nl/dnssec_howto/) by Olaf Kolkman (RIPE NCC/NLnet Labs)
Howto secure your (reverse) Zone (http://www.hznet.de/dns/dnssec-decix050916.pdf) by Holger
Zuleger
Easier Email Security is on the Way? (http://www.dwheeler.com/essays/easy-email-sec.html)
"DNSSEC and the Zone Enumeration" by Marcos Sanz
(http://www.denic.de/fileadmin/Domains/DNSSEC/zone-enumeration.pdf)
NIST Special Publication (SP) 800-81, Secure Domain Name System (DNS) Deployment Guide
(http://csrc.nist.gov/publications/nistpubs/) , May 2006
Bootstrapping the Adoption of Internet Security Protocols (http://weis2006.econinfosec.org/docs/46.pdf)
, Andy Ozment and Stuart E. Schechter, June 2628, 2006
DNSSEC BRIEFING and Root Zone Signing (Part I) (http://ccnso.icann.org/workinggroups/ccnso-iana-
wg-dnssec-paper-04feb08.pdf) , ccTLD paper on DNSSEC by ccNSO, February 2008
U.S. National Strategy to Secure Cyberspace (http://georgewbush-
whitehouse.archives.gov/pcipb/cyberspace_strategy.pdf) , February 2003
Cybertelecom :: DNS Security & USG Policy (http://www.cybertelecom.org/dns/security.htm)
SecSpider Tool for Tracking DNSSEC Deployment (http://secspider.cs.ucla.edu)
Plea to sign the root (http://stfr.org)
DNSSEC in 6 Minutes by Alan Clegg, Internet Systems Consortium
(http://alan.clegg.com/files/DNSSEC_in_6_minutes.pdf) (PDF-Datei; 315 kB)
Retrieved from "http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions"
Categories: Internet standards | Internet protocols | Domain name system | Public-key cryptography | Key
management
This page was last modified on 14 March 2011 at 16:55.
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may
apply. See Terms of Use for details.
Wikipedia is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.

Domain Name System Security Extensions: Internet Protocol Suite

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Domain Name System Security Extensions: Internet Protocol Suite

Uploaded by

Copyright:

Available Formats

Internet Protocol Suite

You might also like