This paper highlights the DNS security topic and Palestine Country Code Top Level Domain ".PS ccTLD" security measures. The main security objectives discussed are data origin authentication and data integrity that by design DNS lacks. The ".PS ccTLD" security topic is addressed as case study for DNS security issue and its security guidelines are discussed. The possibility of implementing DNS Security Extensions as well as Transaction Signature as enhancement for the DNS security is discussed. A novel security approach is illustrated which is implemented in the ".PS ccTLD" that helps in ensuring that it never goes into a total collapse state. The system is called DNS Early Warning System, the main idea behind this system is to guarantee the integrity of the DNS zone files by making sure that all changes applied to the files with respect to syntax and content are correct and legitimate.
KEYWORDS
DNS Security, DNS Security Extensions, ".PS ccTLD", DNS Early Warning System.
INTRODUCTION
Domain Name System (DNS)[1] is the standard mechanism for name to IP address resolution. Its is a critical component of the Internet infrastructure, because most network services and applications require a translation step from domain name to IP address[2]. ".PS ccTLD" is the domain name assigned to Palestine, and it is managed by the Palestinian National Internet Naming Authority "PNINA"[12]. DNS faces different security threats, they are mainly cache poisoning, man-on-the-middle attack, and DoS. Theses attacks affects confidentiality, authenticity, integrity and availability of the DNS service. Since security issue was not considered with initial design of DNS, a set of security extensions have been proposed to solve the known security problems with DNS. DNS Security Extensions (DNSSEC) provides data integrity and origin authentication using pre-generated digital signatures for each data item stored in the DNS database[3]. Still, Obstacles face the wide deployment of the DNSSEC. Also, Transaction Signature (TSIG) was introduced to allow for transaction level authentication using shared secrets and one way hashing. Different security incidents were recorded that affected the DNS of the root DNS servers as well as other country code top level domain names. ".PS ccTLD" was chosen as an example to present its security measures and the "Early Warning System" that guard the ".PS ccTLD" from being compromised. The rest of the paper is composed of the following sections. Section two presents a related work, section three briefly introduces the DNS function, structure and its effect on internet services. Section four addresses DNS threats and their defenses. The fifth section provides detailed information about DNSSEC, its background, implementation, and challenges. Section six presents some real incidents about attacking DNS, and their effects. Section seven considers the ".PS ccTLD" security measures and its "Early warning system". Finally section eight comes to the conclusion.
RELATED WORK
Different papers discussed DNS security, A related one is [7], which addressed security issues of DNS, their threats and solutions. The author presented how DNSSEC can ensure source authenticity and integrity, also addressed the challenges that faces DNSSEC as well as DNS end to end security. But, detailed information about DNSSEC implementation and usage was not provided, and the author did not provide any information about real threats targeting DNS servers and defenses. An other related work is the .SE security collapse issue [10], in which it was concluded that main reason for the collapse of the ".SE ccTLD" was the lack of implementing an "Early Warning System" .
DOMAIN NAME SYSTEM (DNS)
DNS Infrastructure:-
DNS translates domain names to IP addresses, and vice versa. Its implemented as a globally distributed database supporting a hierarchical structure. A client entity known as a Resolver acts on behalf of a client by submitting queries to, and receiving responses from, the DNS server. The top-level domains are those immediately below the root. A domain is broken into smaller units called zones[3].
Name servers and resolvers:-
Name servers generally maintain complete name/address information about a particular zone in a file known as the zone file. Every zone needs to provide a primary and a secondary/slave name server. Primary master servers maintain the zone data in a locally stored zone file. All changes to zone data must take place at the database of the primary server. A secondary server updates its database through zone transfer mechanism. The primary protocol used for DNS communications is UDP. However, TCP is used to provide zone transfers. Name servers listen on UDP and TCP port 53 for DNS queries [3].
DNS root servers:-
Root servers are the base on which the Internet's naming system runs. Each server contains a copy of the same file, which lists where on the Internet all the directories for top-level domains such as .com or .net or .uk can be found. There are 13 servers dotted across the world that store this file (and they are named "A" through to "M") [4].
DNS Operations:-
A name server can operate in two modes, recursive or iterative. In recursive mode the name server searches through the DNS hierarchy in response to queries and returns either an error or the answer. For iterative queries, the queried name server operating in iterative mode consults its own database for the requested data. If it cannot find the answer, it typically gives the IP address of the closest name server that might know the result [3].
Resource Records:-
Name servers return back to the resolver clients Resource Records (RR). They are stored in name server zone files, and have the format shown in Figure 1.
Figure 1 - Resource Record Format
The domain name is a pointer to the RR. The Time To Live (TTL) is the length of time that a cached RR may be considered to be valid. Class is the type of the network; RRs typically belong to the IN (Internet) class. The most commonly used values for the Type field are SOA, NS, A, PTR, MX, and CNAME[3].
DNS Implementation:-
DNS is implemented both at server and client side. The client side is part of the TCP/IP stack at the client operating system, or at the application level. DNS server is implemented as a software or as a hardware. Common DNS servers that are used by different service providers are: bind which runs on unix/Linux platform, Microsoft DNS service which runs on windows 2000/2003 server operating system, simple dns plus software, and Cisco network registrar[5].
DNS Caching:-
Name servers manage two kinds of data. The first kind of data held in sets called zones; each zone is the complete database for a particular sub-tree of the domain space. The second kind of data is cached data which was acquired by a local resolver. This data may be incomplete, but improves the performance of the retrieval process when non-local data is repeatedly accessed. Cached data is eventually discarded by a timeout mechanism, based on the record TTL[6].
DNS THREATS
Man-in-the-Middle Attack:-
This threat exists in the context of query/response transactions. Attacker can spoof authoritative name servers responding to DNS queries and alter DNS responses in transit through man-in-the-middle attacks[7]. The aim of this attack may also to place the incorrect data in the slave server through the normal zone transfer process between the master and slave servers. To mitigate it, some DNS server implementations use IP based access control list [8].
Cache poisoning attack:-
This threats leads to altering the DNS responses stored in caching name servers[7]. DNS responses will be cached. However, attackers can abuse this cache function by putting incorrect information in a DNS server's cache. This kind of attack is called DNS cache poisoning. To help defense cache poisoning attack DNSSEC is introduced.
DoS attack:-
The general concept of DoS attack is to flood a server with requests to make it too busy to accept new legitimate requests, or to make it respond so slowly as to be rendered effectively unavailable. However, in DNS, another form of DoS can be achieved by making malicious use some of the resource record types in zone file[8]. A third form of DoS attack is the DDoS attacks using recursive name servers that can create an amplification effect similar to the now-aged Smurf attack [11]. To counter part this threat the following actions may be taken:
DNS name servers facing the world should not be the same ones serving users or clients in your network.
Limit usage of the DNS name server and the recursive functionality to your network.
Implement spoofing counter-measures such as those suggested.
DNS SECURITY ENHANCEMENT and TSIG
DNSSEC background:-
Security has to be added to the DNS to provide a more secure naming system[8]. DNSSEC provides origin authentication and data integrity, which is achieved by using digital signature, and there exist public and private keys for the server[7]. The keys can be used to verify that the received data came from the correct name server, and the data has not been modified.
DNSSEC implementation:-
Zones that implement DNSSEC are called signed zones because they include digital signatures for resource records in their zone files served by DNSSEC-aware authoritative name servers[7]. In response to DNS queries, DNSSEC-aware authoritative name servers return signed DNS responses to DNSSEC aware caching name servers. A signed DNS response contains three sets of records, the requested resource records (RRs), Special Resource Records (SIG RRs) that carry the digital signatures associated with the requested RRs, and DNSKey RRs, which include the public key used to verify the signatures. A DNSSEC-aware caching name server starts from a trusted public key stored within itself-the trust anchor-and establishes a trusted chain that ends in the public key of the zone that has provided the signed DNS response.
PKI in DNSSEC:-
A name server first uses a one-way hash function to map its variable-length zone data into a fixed-length hash value[8]. The hash value is a cryptographic checksum of the data. After that, the server encrypts the hash value (instead of the zone data) using its private key. This encrypted hash value is called digital signature. The server will send both the zone data in plain text and the digital signature to its recipient. The recipient will first decrypt the digital signature using the server's public key to obtain the hash value. It will then run the same hash function to map the received zone data to a hash value. If this just calculated hash value is the same as the one from the server, the zone data will be verified.
DNSSEC challenges and Limitations:-
DNSSEC has not been widely implemented or deployed. Its complex to implement[3]. It has a number of limitations. DNSSEC requires all name servers in the authentication path (from the root to the queried servers) -hardly fulfilled- must deploy DNSSEC, and DNSSEC incurs extra administrative overhead[7].
One of the challenges facing DNSSEC is the administration of large signed zones based on DNSSEC due to lack of agreement on best practices. An other one, is that DNSSEC environment differs from PKI in that the signed zone doesn't use the concept of trusted third parties such as certificate authorities (CAs). Finally, DNS end to end security issue arise, where to impose security between stub resolver client and DNS server, to incorporate the function of signature validation in the resolver, or the caching name server securely passes the response to the resolver.
Transaction Signature for DNS (TSIG):-
Besides DNSSEC, TSIG was introduced to allow for transaction level authentication using shared secrets and one way hashing[14]. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. It can be further used to protect zone transfers. In this case the data covered would be the whole zone transfer. In this way, TSIG can overcome some shortcomings of the DNSSEC.
DNS ATTACKS REAL INCIDENTS
Root servers under attack
Attack 1: On 21st October 2002, DDoS (ping-flooding) Attack managed to swamp nine of the 13 servers[9]. The result was the roll-out of a new technology called Anycast. "Anycast allows a number of servers in different places to act as if they are in the same place". This approach has two advantages: The servers spread the load of an attack among themselves. And the servers can be spread geographically around the world so if something physically happens at one location-for example an earthquake-then the root server itself can remain operational.
Attack 2: On 6th February 2007 (DDoS)[4], for approximately two-and-a-half hours, the system that underpins the Internet came under attack. Three-and-a-half hours after the attack stopped, a second attack, this time lasting five hours, began. Three of the Internet's 13 DNS "root servers" (responsible for controlling global internet traffic) were intensely smacked by a remote-controlled network of thousands of zombie computers. The "denial of service" attack was intended to engulf many of the root servers with colossal amounts of traffic. Engineers soon discovered that all the attack packets were larger than the 512-byte size and so simply blocked any packets larger than that.
To deal with the problem, administrators of the systems, try to suck up the queries by adding extra bandwidth to the system to answer all the requests or find patterns in the queries being sent and decide if those patterns can be used to filter the attacking traffic, either by stopping the source of the attack (by ignoring all requests from it) or working with those further upstream to filter their bad traffic.
".SE ccTLD" Total Collapse
On 12th October 2009, the ".SE ccTLD" zone [10], broke from 21:45 local time and was not returned to normal until 22:43 local time. Because of caching, it wasn't until around 23:30 local time that the major Swedish ISPs had flushed their own DNS caches, DNS lookups are cached a certain time and the .se zone has a 24 hour time-to-live. The problem happened during planned maintenance of the .SE domain. The .SE registry used an incorrectly configured script to update the .SE zone, which introduced an error to every single .se domain name, the script did not add a terminating ".". The implications of this event introduced problems that affect an entire top-level zone have very wide-ranging effects as can be seen by the .se incident. There are just over 900,000 .se domain names, and every single one of these were affected, the security issue violated here is Integrity resulted in Denial of Service, it happened as a result of a scripting error, the script is not secure to handle this job, or needs modification to be used trustily. It was concluded that to prevent such problem from occurring an "Early Warning System" should be implemented.
".PS ccTLD" DNS SECURITY
When considering the security issue of the ".PS ccTLD", one should take into consideration the goals to be achieved. Defined measures should also be explicitly stated to reach the indented goals. The goals to be achieved are defined by CIA model which are Confidentiality, Integrity, and Availability. It worth mentioning that the ".PS ccTLD" never been totally collapsed since it was launched in December 2003. This success is achieved because of implementing the security guidelines for DNS as well as implementing the DNS Early Warning System.
Current ".PS ccTLD" security measures
Different actions are taken to enhance the security of the ".PS ccTLD" master name server. These actions help protect against DoS attacks, cache poisoning attack, zone file integrity violation, zone file confidentiality. The actions are listed in the table 1.
Security Measure
Achieved Goal
Having six name servers to provide DNS services for the ".PS ccTLD". The servers are geographically distributed and not bound to a single subnet or network path.
Eliminates a single point of failure, and defend against DoS.
Only DNS service is running on the master DNS server.
Enhances the availability of the DNS service.
A firewall system is implemented, where UDP port 53 is the only open port which is used for DNS queries, and TCP port 53 used for zone transfer is allowed only slave name server.
-Provides a defense layer between the Internet and the master name server, enhances the availability of the DNS service, and protects against attacks targeting other application running on the server.
Configure border router to filter traffic from external networks with addresses from internal network.
Protects against spoofing
DNS servers is configured to restrict zone transfer to slave name servers only.
Ensures the confidentiality issue of the zone file.
Use of the latest version of the bind software -DNS service software- and keep it updated.
Overcomes DNS service shortcoming, vulnerabilities, buffer overflows and bugs.
Master DNS server is configured to not allow Dynamic Updates.
Helps in preserving the integrity of the zone file.
Recursive queries are not allowed to disable the caching functionality of the server.
Protects against spoofing, and mitigates cache poisoning attack
Separate DNS registration database from master DNS server into two different machines
Hardening the task of the attacker to compromise the master name server.
Implementation of Early Warning System
Provides the last defense layer to protect the integrity of the zone file.
Table 1 - ".PS ccTLD" Security Measures
DNS Early warning system (DNS-EWS)
One novel idea, implemented in the ".PS ccTLD" is the Early Warning System (DNS-EWS) is implemented using a scripting shell language to ensure that ".PS ccTLD" zone file is correct regarding the syntax and the changes applied to it. Its considered the last defense layer that should not be compromised. The system will ensure the integrity of the zone file. It will help protect the DNS zone files even if an attacker managed to compromise the DNS registration system. Figure-2 presents the flow chart illustrates the idea behind the (DNS-EWS). It worth mentioning that this system is implemented and successfully protected the ".PS ccTLD" for around six years ago till now.
Figure 2 - DNS Early Warning System (DNS-EWS) Flow chart
Figure 3 depicts a piece of the script that shows the implementation of the procedure "Get Number of changes between the current and New zone file" and the check condition of the values of changes.
Figure 3 - DNS-EWS part of the code
The "$1" in the script denotes the zone file name, e.g. ps for the file holds the name servers for the domains under the ".PS ccTLD", and $Threshold is the variable that holds the value set by the administrator for the maximum expected number of changes for the DNS records in the zone file per day.
Systems that do not implement (DNS-EWS) would just have two actions: the first is to generate the new zone file and the second is to reload the DNS service. But such implementation would leave the ".PS ccTLD" vulnerable to integrity problem in case of having wrong records in the registration database system or if the database itself was attacked.
".PS ccTLD" security recommendations
The use of DNSSEC in the ".PS ccTLD" will face obstacles mentioned in earlier section, also it will not be fully helpful until the root servers fully implement the DNSSEC, which is expected to be so in July 2010 [13]. ".PS ccTLD" may implement transaction signatures, or TSIG, to cryptographically authenticate and verify zone data between master and salve servers[14], and to help defense against man-in-the-middle attack. Still this needs some sort of management and technical coordination since the name servers for the ".PS ccTLD" are not all under the same managerial entity.
CONCLUSION
The DNS is very vital internet service, its failure may lead to internet collapse. Although it is important, it lacks security measures by design. ".PS ccTLD" proved its security through implementing different security measures. Apparently the Early warning System (DNS-EWS) which prevented a possible total collapse of the DNS such that occurred in the ".SE ccTLD". However, ".PS ccTLD" still requires extra enhancement to its security by deploying TSIG to secure zone transfer between the master name server and the salves. To correctly implement TSIG ".PS ccTLD" administrator should coordinate the exchange of secret key with the administrators of the salve name servers for the ".PS ccTLD", also all DNS servers must support TSIG to be successfully implemented. DNSSEC would be cumbersome to implement in the ".PS ccTLD" and it faces obstacles to be a suitable solution to provide further security in the ".PS ccTLD", since the root DNS servers still did not fully support DNSSEC. DNSSEC may not be that crucial security demand for the ".PS ccTLD" since the name servers are not providing any recursion or caching functionality. The listed and implemented security measures for ".PS ccTLD" proved its strengthens in protecting the ".PS ccTLD" and can be used as a model for other DNS operators.
