An Analysis of DNSSEC
Submitted By: Team Trojans-1
Arjun Ashok
Priyank Mohan
Balaji Thirunavukkarasu
An Analysis of Domain Name System Security Extensions (DNSSEC)
Abstract
DNS Security or simply DNSSec has evolved to become an important security measure for the DNS. This
paper gives a brief introduction to the structure of Domain Name System and discusses the various
security threats that it possibly faces. Thereafter it goes on to explain what DNSSec is all about, the trust
models that are being followed for the key validation process, the various vulnerabilities, and some of
the challenges that it faces in its actual realization. We also list some of the alternatives to DNSSec and
conclude with what the future holds for this security mechanism.
I.
Introduction
The Domain Name System (DNS), as the name suggests, is a hierarchical distributed internet
infrastructure that stores host names and their corresponding Internet Protocol (IP) addresses. It can be
visualized as a distributed database which provides the service of translating the domain names from its
human readable form to machine readable IP addresses and vice versa. Since the information stored in
the DNS is integral to the operation of the internet as a whole, it is essential to secure it and its
communications. The DNS was not designed with security in mind, and hence, is prone to various types
of attacks. Due to the lack of a security layer over the DNS system, the DNS queries can be manipulated
on the wire and the user can be redirected to a malicious website. Furthermore, a hacker can use DNS
spoofing to modify the server responses and send it back to the user. Recently, the RSA Security web
page was hijacked by spoofing the DNS tables [2].
In order to address these security issues, the DNS clients can employ security techniques for source
authentication and data integrity in order to ensure the source is authoritative and the received data
has not been tampered [3]. The confidentiality of the data does not come into play here as the DNS data
in public information. One of the proposed methods for securing the DNS is the DNS Security Extensions
(DNSSEC). It is a signature based process for securing the DNS requests and responses.
In this paper, we will discuss the structure of the DNS and some of its security issues. We will then
discuss DNSSEC, how it proposes to protect the DNS queries and responses along with some of the
roadblocks or challenges involved in its implementation.
II.
Domain Name System (DNS)
“DNS is a distributed hierarchical system maintained by a collection of organizations and entities across
a series of platforms and configurations, mapping easily remembered names to IP addresses. In some
cases, the DNS is also used for load distribution across distributed servers. For example, Akamai provide
distribution of their web content through DNS. [1]”
A.
The Structure of DNS
The DNS follows a hierarchical tree structure which is analogous to the UNIX file system. As shown in the
figure below, there is the root server, followed by the top-level domains (TLDs) at the next level, each
domain represented by .com, .net, .edu or country-specific like .us, .jp etc.. The domains are usually
further divided into zones, which can be visualized as sub-domains managed by some organizations.
Figure 1. Example DNS tree structure showing the domain and zone hierarchy [1].
The figures above show the tree structure of DNS and how it is organized. This also shows that when our
system makes a DNS request, it is usually not as simple as getting a response from a single server. In
some cases, this process can involve querying numerous servers distributed across various domains.
Each zone is usually associated with name servers which answer the queries coming from DNS clients,
known as resolvers. The resolver on the client side is known as the stub resolver which initiates the DNS
request. It has a corresponding resolver program running at the name server which receives and acts
upon the request, by either finding it in its local cache, or querying other name servers, starting with the
root server. This process can be visualized through the figure below.
Figure 2. Figure showing the iterative DNS resolution process [4]
Based on the type of query (iterative or recursive), the resolver queries other name servers till it reaches
the intended recipient and then returns its IP address to the stub resolver in the client. This process is
known as resolving.
This description of the DNS operation is a high-level abstraction of the actual process which usually
involves caching and configuration at every level.
B.
DNS Threats
The nature of the DNS request and response messages being sent in separate unencrypted and unsigned
packets, makes it vulnerable to different types of attacks. Some of the known threats to the DNS are
listed below.
1.
Packet interception
This is one of the simplest forms of threats to the DNS system. It is usually done by
eavesdropping on requests or responses and injecting a faster response to the resolver. This
way, an attacker can mislead either end of communication.
2.
Name Chaining
DNS name-chaining attacks are a subset of “cache-poisoning attacks”. What is common in these
attacks is that an attacker is able to introduce DNS names of his / her choice into the responses,
forcing the victim to make a wrong choice in subsequent requests.
In case of cache poisoning attacks, an attacker inserts resource records into the victim’s cache
while replying to the query issued by the victim. Once an attacker successfully injects false data
into a victim’s cache, he or she will be able to control subsequent transactions from the victim’s
system by directing the request to a server of the attacker’s choice.
3.
Denial of Service
DNS is prone to Denial of Service attacks as in the case of network service. The application of
security techniques to overcome this threat seems to make it worse as it adds overhead for
every DNS message and can add to the number of messages being sent.
4.
Brute Force
The fact that DNS runs over UDP makes the life of an attacker easier. Any attacker can use brute
force techniques to predict the Id field in the DNS header (since it is 16bit), while the UDP port
has a well known value. By guessing the Id along with predicting the queries of the resolver, an
attacker will be able to inject data of choice.
II.
Domain Name System Security Extensions (DNSSEC)
Domain Name System Security Extensions have been brought to existence for the purpose of providing
authentication and integrity of DNS data. Authentication of source data can be used by the resolver to
make sure it is communicating with valid name servers. While DNSSEC addresses issues related to
authentication and integrity, it does not address all the types of threats mentioned above such as denial
of service attacks.
Data integrity, on the other hand ensures that the data has not been tampered while being transmitted.
“DNSSEC was first introduced in RFC 2535 "Domain Name System Security Extensions" [4] in 1999, but
has been substantially updated since then. [6]” It incorporates authentication and data integrity through
digital signatures and public key cryptography.
One approach that is often used is by signing each DNS message that is sent from a DNS server.
Typically, a name server of a particular zone is associated with its corresponding private key which it
uses to sign the data it sends out to the requesting name server or the resolver. In order for the
resolvers to decrypt the data, they are either configured with the public keys of the corresponding name
servers, or they learn these public keys from the name servers through the DNS resolution process,
wherein the public key is explicitly sent to the resolver, signed by the private key of the name server.
In other words, a DNSSEC response contains the DNS data along with the digital signature. “A resolver
that knows the zone’s public key can verify the signature and authenticate the DNS response. [7]”
In order to maintain the integrity of the data being transmitted, the hash of the resource record set
(RRset) is often signed and sent by the name server. The signature is then validated based on the hash
to check if it has been modified. MD5 and SHA1 are used for hashing, while signatures use MD5/DSA or
RSA. As stated above, these signatures are stored as resource records of type (RRSIG) and are used with
the corresponding zone’s public key for authentication.
III.
DNSSec Trust Models for Key Validation
There are a couple of approaches to perform the key validation process. One of them is the Tree-based
approach which is basically a strict framework that allows a resolver to build a chain of trust from the
root [9]. In this approach, a strict hierarchy of key validation is followed – a zone public key will be
considered authentic only if it has been signed by the parent. Such an approach would localize the
damage to only a zone, incase its private key is compromised. But there are also numerous
disadvantages associated with this model. It creates a single point of failure, or in other words if any
failure occurs at any intermediate node the entire structure below it would be disabled because of their
total dependency on this one and single path – the chain of trust. Also, it places all the nodes under the
same umbrella of security and trust, which is highly impractical in the actual scenarios.
The second approach tries to do away with the strict hierarchy imposed by the above model. This
approach known as the Web of Trust, allows various resolvers and zone servers to select their own trust
relationships [9]. As long as a public key is signed by another valid key, it is deemed valid to use. Since
such a model does not depend on a chain of trust, it is highly scalable and robust. In the event that a
zone finds itself overburdened with signing public keys, it can request those servers to get the signatures
from somewhere else. However this model brings along a very important disadvantage as well. Since
there is no trust chain established here, a hacker could impersonate a zone server to create and sign its
own set of public keys. A resolver would be unaware and it will trust the signature and response
received from such a false server.
IV.
DNSSEC Vulnerabilities
1.
DNSSec builds a trust link from the trusted root till the client resolver. For this, every parent
node must have a record known as the Delegation Signer Resource Record (DS RR) which
contains the hash of its public key encrypted by its private key. The child node holds the public
key for the same, also known as the Key Signing Key (KSK), thereby establishing a link between
itself and the parent. The KSK allows a zone to authenticate several of its local keys that it can
use to sign records for its child nodes. Such a mechanism facilitates a zone server to distribute
and use multiple local keys for one public key from the parent. The problem with this chain of
trust lies in the fact that a compromise of this public key would lead to the entire sub-domain
being marked as false. [7], [8]
2.
The implementation of DNSSec is based on the exchange of public-private key pairs between the
nodes of a DNS tree structure. Such an environment underlines the need for understanding
various security concerns for the keys. The foremost and primary concern is the key
compromise. A zone private key compromise would let a hacker have access to all the record
sets in the caching name servers. So it is of utmost importance that the private keys must not be
stored in the server memory. This concern also brings forth the need of an approach that avoids
any single points of failure in the structure. Secondly, key rollovers must be handled efficiently
by the servers – all the concerned name servers must be kept updated with any change of keys.
Lastly, there should be some means to synchronize the time between primary and secondary
servers in order to prevent a hacker from reusing old signature keys in the event that the person
is able to change the current system time on a server. [7]
3.
DNSSec currently does not have any proper log analysis and monitoring tools that are necessary
in order to maintain and debug a signed domain. [7]
4.
Data update happens only in the primary servers which inform the secondary servers only
during a zone transfer. During this time, a client request could result in inconsistent responses
based on which server responded. Moreover, a single compromise in such primary servers could
lead to total inconsistency of the data. [7]
5.
Another type of Resource Record known as the NextSECure (NSEC) is used for validating all the
names that exist within a zone. The NSEC maintains the authoritative owner names in a
canonical form. For example, an NSEC record that holds the name a.localdomainsj.com followed
by d.localdomainsj.com is a proof that there does not exist any name as b.localdomainsj.com.
An attacker could obtain a list of all the existing names in a zone by querying all these NSEC RR’s
and thereby could spoof an entire zone. [7], [10]
V.
Roadblocks in DNSSEC deployment
We have seen that even though various strategies have been suggested for implementing DNSSec, each
one has their own disadvantages. Not only restricting to specific models, the overall realization of
DNSSec itself is marred by several roadblocks and issues. The wide spread of DNS zones imposes various
limitations. No proper standards have been defined yet that would be able to encompass the DNS in its
entirety.
Implementing a PKI based infrastructure in a DNSSec environment is not as simple as it might seem. The
signed zones here do not rely on certificate authorities (CA). In a PKI environment it is easy to build a
trust between two entities based on the signature from a common root authority – CA. Secondly, using
large size keys in the zone environment would have a detrimental effect on the performance of the DNS
response verification process, considering the vast number of requests it has to cater to in a single time
unit [3]. This brings out another point of view that, each zone needs to use its private key for generating
signatures, far more than its corresponding public keys. Such a process increases the chances of a singlepoint failure that would give away the entire security for the name servers, if a zone signing key is
compromised.
Another issue arises with the secure and successful distribution of updated keys to all the caching name
servers. Consider a scenario where an authoritative name server has performed a key rollover but one
of the caching name servers still uses it old key because it has not been informed about the rollover.
When it receives a response, it would try to verify the zone RRSIG with the old public key which would
result in a failure of authentication. There are two possible methodologies suggested by researchers in
order to update the keys [3]. First one uses the concept of authoritative name servers updating all the
DNSSec caching name servers with the new keys. This turns out to be highly impractical because the
servers high up in the hierarchy are absolutely unaware of the name server mappings at the lower level.
Another one is based on a scheduled or regular check that a caching name server runs to procure any
updated keys from their zone servers. In order to ensure that all the caching name servers have updated
themselves, there should be an overlap period during which they can use both the old and new keys to
verify signatures.
Due to the large variety and structure of this DNS tree, we need to consider each and every
administrative domain across which these name servers have to coordinate. Every domain has its own
value or importance for implementing security across the DNS. A structure that consists of an
authoritative and its caching name servers behind a corporate firewall may not require DNSSec at all
while others might. So it is not practical to treat all with the same solution. In some cases, even though a
child zone might support DNSSec, its parent zone might not. This would result in several isolated secure
zones in the DNS tree rather than a uniform support from the root till the resolver [8].
VI.
Alternatives to DNS Security
Security can be implemented in the DNS hosting environment in elements like the platform (OS)
of the DNS, the DNS software (software running on the name server & resolver) and the DNS
data (configuration and zone files).
1. Name Server Software:
This approach involves using some of the best practices in configuring and maintaining the name
server software, to avoid some of the threats mentioned below. Some of these steps are:
1. Using secure OS with secure configuration and installation.
2. Restricting the access privileges on the name server.
3. Use software to check the integrity of zone files.
Threats addressed
Zone Transfer attacks, Denial of Service (DoS), packet flooding attacks, Address Resolution
Protocol (ARP) spoofing attack and attempts to corrupt the configuration or data files.
2. Transaction Signature (TSIG)
These mechanisms involve mutual authentication of servers based on shared secret key. It
prevents tampering of zone transfer and server update information by utilizing the shared
secret key for mutual authentication as well as signing the information being transferred. TSIG
achieves source authentication through the use of hash based message authentication codes
(HMAC) [11].
Threats addressed
Dynamic Name server Updates attacks, Zone transfer attacks etc.
Figure 3. DNS Transaction threats and security objectives [11].
VII. The Road Ahead
Despite its advantages and the various threats it addresses, DNSSEC the main reasons hindering its
large-scale adoption is scalability and implementation complexity. However, work is ongoing in several
organizations to overcome some of these limitations and make DNSSEC adoptable. One such example is
Secure64 software, a company which is releasing software that is targeted at addressing the DNSSEC
issues we just mentioned. The software, namely Secure64 DNS signer is targeting the automation of
processes such as the generation, backup, restore and rollover of keys and zone signing in order to
simplify the implementation in terms of entries into the configuration file [12]. According to Mark
Beckett, Sr. VP of Marketing – the Greenwood Village, “the Signer achieves high scalability through the
use of high speed cryptographic algorithms 6,000 RSA operations per second with a 1024-bit key. In
addition, Signer can be configured to sign zones either in bulk or incrementally, making it possible to
deploy it in the largest and most dynamic environments without compromising existing update
intervals” [12].
Another way to improvise on DNS security is to implement DNSSEC from the zone servers till the user
level i.e., client stub resolver level. Till now we have only considered DNSSEC that functions between the
caching name servers and their zone servers, but extending this concept all the way to the client
applications can ensure end-to-end security validation of the response authenticity on the client side [3].
This approach will also lessen the load on the cache servers by allowing the client software to take
authentication decisions. This can be achieved either by incorporating signature validation functionality
into the applications or by having the name server send various status messages as a result of its
validation check.
Another major development expected in favor of large-scale implementation of DNSSEC is that U.S.
government to deploy DNSSEC in dot-gov TLD by December 2009. This suggests that considering the
growing vulnerabilities in the DNS infrastructure, it is evident that DNSSEC needs to be adopted to
address security issues. Therefore, quoting IANA’s Richard Lamb: “DNSSEC is not an overnight solution
for the Kaminsky problem, but it’s the right solution in the long run.”
VIII. References
[1] Amy Friedlander; Allison Mankin; W. Douglas Maughan. DNSSEC: a protocol toward securing
the internet infrastructure. Communications of the ACM - Smart business networks, Volume 50 ,
Issue 6 (June 2007) Pages: 44 – 50
[2] Giuseppe Ateniese; Stefan Mangard. A New Approach to DNS Security (DNSSEC). Proceedings
of the 8th ACM conference on Computer and Communications Security, Philadelphia, PA, USA;
Session: Mobile Code and Distributed Systems, Year of Publication: 2001, Pages: 86 – 95
[3] Chandramouli, R.; Rose, S. Challenges in securing the domain name system. In Security &
Privacy, IEEE,Volume 4, Issue 1, Jan.-Feb. 2006 Page(s):84 – 87
[4] Paul Albitz; Cricket Liu. DNS and BIND, 3rd Edition September 1998;
http://oreilly.com/catalog/dns3/chapter/ch02.html
[5] Atkins, D.; Austein, R. Threat Analysis of the Domain Name System. RFC 3833, Aug. 2004;
www.ietf.org/rfc/rfc3833.txt.
[6] Guillard, Alexis. DNSSEC Operational Impact and Performance. International Multi-Conference
on Computing in the Global Information Technology, 2006. ICCGI '06, Publication Date: Aug.
2006 On page(s): 63-63.
[7] Ariyapperuma, Suranjith; Mitchell, Chris J. Security Vulnerabilities in DNS and DNSSEC. The
Second International Conference on Availability, Reliability and Security, 2007. ARES 2007. 10-13
April 2007 Page(s):335 - 342
[8] Osterweil, E.; Massey, D.; Lixia Zhang. Observations from the DNSSec Deployment. Secure
Network Protocols, 2007. NPSec 2007. 3rd IEEE Workshop, 16-16 Oct. 2007 Page(s):1 – 6
[9] Massey, D.; Lewis, E.; Gudmundsson, O.; Mundy, R.; Mankin, A. Public Key Validation for the
DNS Security Extensions. Proceeding of DARPA Information Survivability Conference & Exposition
II, 2001. DISCEX '01. Volume 1, 12-14 June 2001 Page(s):227 - 238 vol.1
[10] J. Schlyter, Ed.; DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format. Network Working
Group, August 2004; http://www.ietf.org/rfc/rfc3845.txt
[11] Ramaswamy Chandramouli, Scott Rose, Secure Domain Name System (DNS) Deployment
Guide; http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf
[12] Brian Prince, Vendor Pushes DNSSEC as a Fix for DNS Security,
http://www.eweek.com/c/a/Security/Vendor-Pushes-DNSSEC-as-a-Fix-for-DNS-Security/