Simplified tcp based communication approach towards domain name system for improving security

By exploiting this vulnerability the attacker can launch different types of attacks like Cache Poisoning, DNS Spoofing, Protocol corruption, Zone corruptions, Session Hijacking, etc. Although the use of UDP makes the system faster, ye, it is suggested that all DNS based communications should be TCP based rather than UDP.

ISSN:2249-5789 Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357 Simplified TCP Based Communication Approach towards Domain Name System for Improving Security Alok Pandey1 , Dr Jatinderkumar R Saini2 Sr Systems Manager, Department of Computer Science Engineering, Birla Institute of Technology Mesra, Jaipur Campus, Rajasthan, INDIA e-mail :alokpandey1965@yahoo.co.in Director (I/C) & Associate Professor, Narmada College of Computer Application, Bharuch, Gujarat , INDIA e-mail: saini_expert@yahoo.com Abstract Using DNS, domain names can be assigned to groups of Internet resources independent of their physical location Without DNS, the only way to reach other computers on the Internet is to use the numerical network address The use of IP address for locating and connecting to remote systems is tedious and is not very user friendly A preferable and much relied upon service for retrieving an IP address just by referencing a FQDN is DNS Several types of DNS based communications take place on the internet which are exploited by the cyber criminals for attacking systems Although different mechanisms have been suggested by the research community to secure the DNS based communications yet it is still not fully secure Since DNS does not necessarily require the establishment of a TCP connection it allows the attackers to redirect the response to the victims host by spoofing the source IP address as the victims IP address By exploiting this vulnerability the attacker can launch different types of attacks like Cache Poisoning, DNS Spoofing, Protocol corruption, Zone corruptions, Session Hijacking, etc Although the use of UDP makes the system faster, ye, it is suggested that all DNS based communications should be TCP based rather than UDP Keywords : DNS, DNS Spoofing, DNS Poisoning Introduction Computers communicate with each other on the basis of IP Addresses Each device on the network needs a unique IP address to enable data packets to reach their destinations Initially there were only a few hundred computers making up the ARPANET, the military / educational precursor to the Internet in the early days It may be easy to remember a few IP addresses on local network, but is difficult to keep track of the addresses of remote systems that Due to its ability to map system names into numeric IP addresses hierarchically and its distributed nature & robustness, DNS has evolved into a globally distributed database and is a critical component of the Internet might be often used Thus came the concept of host names Host names provide a more “friendly” way to name the systems and resources, making it easier for humans to remember them The hostnames of the frequently visited web based resources can be recorded with their respective IP addresses Initially when the number of nodes was small, then a single text file could easily map host names to their corresponding IP addresses This text file is called Hosts.txt and used to be managed by the Stanford Research Institute (SRI) This Hosts.txt file contained all of the name-to-address mappings for all nodes on the ARPANET Operating systems use the Hosts.txt file to map host names to IP addresses System administrators copied the Hosts.txt file from SRI to their local systems periodically to update their address maps As the number of nodes on the network increased and the use of this static text file for providing mapping, became impractical The networks were growing and the new hosts were being added at a very high rate Soon neither SRI nor the system administrators could keep pace with the necessary frequent updating procedures There was an urgent need of an automatic translation mechanism that could manage the mapping of IP Addresses to their respective Host Names Thus the Domain Name System (DNS) was developed in the mid-1980s to provide a dynamic means of updating and resolving host names to their IP addresses It is one of the basic services on the Internet DNS was originally specified in 1983 by Paul Mockapetris in RFCs 882 and 883 It is described as a distributed database with the purpose to replace the HOSTS.TXT file that maps the hostnames to IP addresses and vice versa The Domain Name System (DNS) provides translation from human-friendly names to data in other formats DNS is commonly used of the translation from names like “www.mysite.com” to the “dotted-quads” of IPv4 addresses, such as 192.168.1.64, or “colon separated hex” of IPv6 addresses like fd63:fad8:482a:65d3::0:f0cc The DNS also acts as a form of assistance operator for both human-to- 347 ISSN:2249-5789 Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357 machine and machine-to-machine interactions In addition to IP addresses, the DNS is also used to look up for mail servers, cryptographic keys and retrieving information related to other DNS Name Servers, Canonical Names, etc Several internet based services rely on DNS for their operation Hence if DNS fails or is slow, then the web sites cannot be located In September 1981, D L Mills published RFC 799, “Internet Name Domains” wherein he suggested that in the long run, it will not be practicable for every internet host to include all internet hosts in its nameaddress tables hence some sort of hierarchical namespace partitioning should be devised to deal with recording and maintaining such details of every internet host DNS works both as a set of protocols and as a globally distributed database that is used heavily on the Internet The database is a network of several million servers, which actively cooperate to provide a globally distributed service that translates between human-oriented alphanumeric labels and machineoriented numbers Any large-scale disruption of the DNS would make the Internet unusable Based upon the decision to move to a “Hierarchy of Domains” in a meeting in February 1982 the RFC 805, “Computer Mail Meeting Notes,” was published The Web and email traffic would grind to a halt since the Internet users and systems would not be able to use human-friendly names for communication and would be forced to use IP addresses for everything Any accidental or intentional DNS failures would take companies such as Microsoft [1] and Amazon [2] and countries such as Sweden [3] and Germany [4] partially or fully off the Internet Ever since DNS came into existence three decades ago, it has been continuously improved for making it more reliable and secure Even today DNS is subject to a variety of threats and attacks One of the goals of this document is to help readers understand today‟s threats to the DNS infrastructure and how to mitigate these threats using the inherent capabilities of the DNS or by implementing policies for operational practices 1.1 History of the DNS In the earliest days of the Internet, names of systems connected to the network were assigned locally and there was no DNS The Network Information Centre (NIC) kept track of the names In December 1973 RFC 597, “Host Status,” was published, which became the first official collection of hostnames The system manager was expected to use RFC 597 and keep their local list of host-toaddress mappings up to date Soon an online file was maintained by the NIC for containing the official name to address mappings and subsequently the RFC 606, “Host Names On-Line,” was proposed and published in December 1973 by L Peter Deutsch Early names as defined in RFC 606 were simple labels Like, the system at MIT‟s Artificial Intelligence lab was called “MIT-AI.” This simple label approach of naming hosts on the network was used for almost a decade and could not work forever In August 1982 with the publication of RFC 819, by Zaw-Sing Su and Jon Postel, this new approach of host naming, described as the “Domain Naming Convention for Internet User Applications” was codified and introduced The new Domain Naming Convention was intended to use hierarchy for distributing administrative management of the namespace that would eliminate duplicity of names RFC 819 provided the general outline of the DNS, including the ideas of naming authorities, registrars and iterative and recursive resolvers It suggested that the Internet names be used to form a treestructured administrative dependent hierarchy, rather than topology dependent, hierarchy It also defined the first top-level domain, ARPA, as “The Set Of Organizations involved in the Internet system through the authority of the U.S Defence Advanced Research Projects Agency.” In October 1982, RFC 830 “A Distributed System For Internet Name Service” was published by ZawSing Su It described an architectural view of a name resolution service provided through the cooperation among a set of domain name servers (DNSs) and discussed system components like database, caching of names, application interfaces and protocols for interprocess communication necessary to implement a distributing naming system By November 1983, Paul Mockapetris had published RFCs 882 “Domain Names - Concepts and Facilities” and RFC 883 “Domain Names Implementation and Specification,” giving the initial specifications for the DNS as we know it today The structure of names in the DNS was also defined very early in the history of the Internet In October 1984 Jon Postel and Joyce Reynolds published RFC 920, “Domain Requirements,” which defined the original top-level domains (ARPA, GOV, EDU, COM, MIL, and ORG), the two letter country domains and opened the possibility of other top-level domains for “multi organizations,” large international organizations-of-organizations, etc 348 ISSN:2249-5789 Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357 proposed architecture, especially for critical DNS zones, such as the com zone In 1987 the original DNS RFCs 882 and 883 were replaced by RFCs 1034 and 1035 respectively and updated the DNS specifications based upon implementations of RFCs 882 and 883 Both the RFCs 1034 and 1035 are the core standards upon which the DNS is based DNS has been modified to address new requirements time and again to incorporate changes to the DNS operational environment Literature Review Steven Cheung et al in their paper “ FormalSpecification Based Approach for Protecting the Domain Name System” [5] formally specify a DNS wrapper that examines the incoming and the outgoing DNS messages of a name server to detect messages that could cause violations of the security goal, cooperates with the corresponding authoritative name servers to diagnose those messages, and drops the messages that are identified as threats Based on the wrapper specification, they implemented a wrapper prototype and evaluated its performance Xunhua Wang, Yih Huang et al In their paper “Enabling Secure On-line DNS Dynamic Update” [6] point out two difficulties in the current DNSSEC (DNS Security Extension) standards in the handling of DNS dynamic updates: a) On-line storage of a zone security key, creating a single point of attack for both inside & outside attackers, b) Violation of the role separation principle, which in the context of DNSSEC separates the roles of zone security managers from DNS server administrators To address these issues, they propose a secure DNS architecture that is based on threshold cryptography They show that the architecture adheres to the role separation principle without presenting any single point of attack and also show experimental results revealing that, in terms of signature computation times, their architecture incurs negligible performance penalty when using RSA/MDS signatures but significant overhead when using DSA signatures They believe that the high level of security can be achieved by their Yih Huang Yih et.al in their paper “Securing DNS Services through System Self Cleansing and Hardware Enhancements” [7] try to develop a secure DNS architecture that contains the damage of successful, undetected attacks They achieve this by constantly cleansing the servers and rotating the role of individual servers Moreover, the server rotation process itself is protected against corruption by hardware They show the advantages of our design in the areas of protection of the DNS master file and cryptographic keys, incorruptible intrusion tolerance, high availability, and scalability, the support of using of high degrees of hardware/server redundancy to improve both system security and service dependability Suranjith Ariyapperuma et al in their paper “Security vulnerabilities in DNS and DNSSEC “ [8] highlight some of the security vulnerabilities in the Domain Name System (DNS) and the DNS Security Extensions (DNSSEC) DNS data that is provided by name servers lacks support for data origin authentication and integrity by using digital signatures Although DNSSEC provides security for DNS data, it suffers from serious security and operational flaws They point out with DNS and DNSSEC architectures, and consider the associated security vulnerabilities Christof Fetzer et.al in their paper “Enhancing DNS Security using the SSL Trust Infrastructure” [9] point out some of the shortcomings of the current secure DNS (DNSSEC) standard like, online updates and denial of service attacks etc which are serious obstacles that might prevent DNSSEC from replacing the traditional DNS To address these issues, they propose a simple extension to the existing DNS It is SSL based and individual domains can decide independently of each other if and when to adopt the extensions They show how to implement these extensions with the help of a simple proxy DNS server Yong Wan Ju et al in their paper “Cache Poisoning Detection Method for Improving Security of Recursive DNS” [10] propose a new detection method for cache poisoning attack on the recursive DNS The proposed method overcomes the weak-points of the previous researches such as DNSSEC and DoX system which are hierarchical or vertical additional deployments of several DNS servers, accordingly overall performance of the system is decreased and additional traffic cost is needed That is to say, the proposed method sets forth independent cache poisoning detection method with the similar security level of DNSSEC, notwithstanding the the improvement, there is little 349 ISSN:2249-5789 Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357 influence on DNS performance and additional traffic The DNS database to procure the information required Daniel Massey et al in their paper “ Public Key Validation for the DNS Security Extensions “ [11] say that t he deployment of DNS Security (DNSSEC) can only succeed if there is an effective mechanism for DNS public key validation This paper compares three potential approaches to DNS key validation A tree based approach utilizes the existing structure of the DNS tree to form highly structured key signing rules This makes following chains of trust simple, but it allows no flexibility for individual zones and makes incremental deployment impossible A pure web of trust based approach imposes no structure what so ever on the key signing process This lack of structure provides a high degree of local control, but also makes it difficult to find trusted chains or specify security policies The third approach is a new proposal based on a the concept of a fault-tolerant mesh of trust The mesh approach utilizes some structured elements from the tree-based approach while maintaining the local flexibility found in the web of trust Our analysis shows the hybrid mesh approach has the best chance of succeeding in the Internet 3.1 DNS organization and infrastructure David Conrad in his paper “Towards Improving DNS Security, Stability and Resiliency” [12] discusses in detail about some of the attacks how to mitigate them The DNS in Operation DNS is a distributed database system spread across multiple DNS servers which allows the resolution of domain names into their respective IP addresses The queries result in responses in the form of IP addresses which are stored in the DNS databases in the form of Resource Records abbreviated as RRs A domain name may consist of several strings separated by dots which represent administrative boundaries For example, the dot between “gmail” and “com” in the domain name “www.gmail.com” represents the administrative boundary between the “com” top-level domain and Gmail, the company responsible for “gmail.com.” The Internet‟s DNS is a single large tree, read right-to-left, with progressively more specific administrative units to the left.7 Within a DNS tree, each administrative unit is called a „zone‟ For example, the “wikipedia.org” zone is the piece of the DNS tree including all names ending in “.wikipedia.org.” Further subdivisions are possible like “wikipedia.org” might have multiple zones, such as “en.wikipedia.org” The DNS lookup occurs each time a user enters a URL in a web browser The application typically uses an intermediate system called a resolver to navigate Beneath the seemingly simple DNS look-up service lies a complex logical and administrative infrastructure The DNS name resolution service uses a data repository, organized as a globally distributed database that‟s largely structured after the hierarchical domain name space, or DNS tree At the top of the hierarchy is the root, a single domain represented by a dot (“.”) Below the root are top-level domains (TLDs), whether generic (for example, com, gov, or edu) or country-specific (such ccTLDs include de, uk, and so on) The next level consists of enterprise level domains (ELDs) owned by commercial, government, or academic organizations such as nist.gov or mit.edu A large enterprise generally has administrative control over a given zone, classified as an ELD, and a set of sub-domains Thus, a zone refers to an administrative entity in the DNS that provides DNS services for a group of domains The term “zone” has percolated up to the top levels, and the terms root zone, TLD zone, and ELD zones are often used The information flow in the DNS takes place primarily among three distinct system entities: authoritative name servers, stub resolvers, and caching name servers, also called resolving / recursive name servers or resolvers Different type of DNS Servers work together to provide the replies to the DNS lookups performed by majority of the applications 3.2.Authoritative servers Every authoritative name server is associated with a zone and, as its name denotes, is the authoritative source for DNS data pertaining to that zone To provide fault tolerance, effective administration, and efficient name resolution, several geographically and logically distributed authoritative name servers exist for each zone These are further classified into primary name servers, which maintain authoritative DNS data in zone files, and secondary name servers, which frequently refresh their contents from the primary name servers The Authoritative servers respond to the query in one of the following ways: A positive response with an answer  A negative response indicating the answer does not exist  A referral response where to find further information The authoritative servers are typically operated by or on behalf of zone administrators ISPs, DNS registrars, and hosting providers often operate authoritative servers on behalf of their customers The authoritative DNS infrastructure, particularly for 350 ISSN:2249-5789 Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357 “high value” zones such as top-level domains, are generally outsourced to DNS-focused service providers, such as Verisign, Afilias, and Neustar 3.3 Stub resolvers Stub resolvers are lightweight clients that formulate DNS look-up queries on behalf of applications, such as Web browsers or email servers and send them to caching name servers Stub resolvers don‟t usually have any caching features Caching name servers each serve multiple stub resolvers domain to other name servers The root servers know the name servers for domain1.com and within those name servers the west.domain1.com domain is delegated to another set of name servers that manage that portion of the overall domain1.com domain In most cases, domains and their records are either managed directly by the organization owning the domain or by the ISP that provides the Internet connection for the organization Depending on the zone or domain requested, they either query the appropriate authoritative name servers or serve responses from their own caches built from previous queries 3.4 Resolver The DNS clients use a resolver to request resolution of a host name to an IP address The resolver is an application which acts as an intermediary between name servers and various applications such as Web browsers, e-mail applications, etc that need name resolution A DNS resolver acts on behalf of client software to retrieve information about a particular domain name For example: Assuming that your browser has to connect to www.abc.com Then local resolver creates a DNS query and sends it to the name server(s) listed in the local computer‟s TCP/IP settings In the case of smaller enterprises and end users, Internet service providers typically operate resolvers In the case of larger enterprises, the resolvers are usually operated by the enterprises themselves or by large-scale DNS hosting providers How DNS works DNS functions as a distributed database using a client/server relationship between clients and the servers that maintain DNS data This distributed database structure enables the DNS to be dynamic and decentralized, allowing control over their own portion of the DNS database by local domains and also enabling clients to access the database At the topmost level there are the root servers (.) which represent the period They are 13 in numbers (ROOT-SERVERS.NET) and are distributed across the globe The root servers maintain the database for the top level domains (gTLDS-SERVERS.NET) i.e com, net, org, mil, edu, gov, int etc These top level domain servers typically maintain data only about the name servers which are authoritative for a particular domain The authoritative name servers, contain data about primary name servers or delegated name servers for that particular domain Finally these name servers maintain data for the individual domains These authoritative name servers maintain the records for a domain or delegate some of or the Image source: Verisign Domain Name Industry Brief, June 2007 (PDF), last page There are two parts in the DNS Tree namely - a root zone file and different name servers that act as the “Root Servers” The root zone file is small and lists all top-level domains along with name servers for respective domains The root zone file is managed by three different organizations: ICANN, the U.S Dept of Commerce and Verisign ICANN [13] is responsible for accepting and validating changes from various top-level domain authorities and then suggesting the necessary changes in the root zone file which are then authorized by the U.S Dept of Commerce‟s National Telecommunications and Information Administration (NTIA) and then Verisign finally applies the updates, signs the zone using DNSSEC and publishes the revised root zone file on a “distribution master” server 351 ISSN:2249-5789 Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357 The 13 root name servers are operated by the 12 independent organizations [14] These root name server operators fetch the root zone file from the distribution master server which is maintained by Verisign and then publish the information on the root name severs which they operate independently Many of these root name servers are clusters of machines which are distributed globally at multiple locations/sites and share information using “Anycast” routing technique The summary of these servers are as follows:Root A B C D E F G H I J K L M Organization Sites Verisign University of Southern California, Information Sciences Institute Cogent Communications University of Maryland, College Park U.S NASA Ames Research Center Internet Systems Consortium, Inc 49 U.S Department of Defense, Network Information Center U.S Department of Defense, Army Research Lab Netnod 38 Veisign 70 RIPE NCC 18 ICANN 39 WIDE Project 4.1 How DNS lookup works The DNS clients use a resolver to request resolution of a host name to an IP address The resolver is an application which acts as an intermediary between name servers and various applications such as Web browsers, e-mail applications, etc that need name resolution A DNS resolver acts on behalf of client software to retrieve information about a particular domain name Let us say that, a browser has to connect to www.abc.com then its local resolver creates a DNS query and sends it to the name server(s) listed in the local computer‟s TCP/IP settings The sequence of events to get the IP address for www.abc.com are - First the computer queries the name server (DNS server) it is set up to use This is the recursive name server shown above If the name server doesn‟t know the IP address for www.abc.com, so it will start the following chain of queries before it can report back the IP address to the calling computer Query the Internet root servers to get the name servers for the com TLD Query the com TLD name servers to get the authoritative name servers for abc.com Ask the authoritative name servers for abc.com to finally get the IP address for the host www.abc.com, then return that IP address to your computer Finally the computer has the IP address for www.abc.com, it can access that host If there is a connection to the ISP then the ISP‟s name servers resolves the query The resolver sends the DNS resolution request to the first of the name servers as specified in the local TCP/IP settings The server checks its cache of previously resolved names, for abc.com so, that name server sends a DNS query to the root server for the com domain The root server responds with the addresses of the name servers that are authoritative for the abc.com domain The ISP‟s name server then builds another request for www.abc.com and submits it to the abc.com‟s 49 name server, which responds with the IP address of www.abc.com This information is passed back to the resolver, which gives it to the calling application As a result abc.com‟s Web site appears in the browser Resolving a host name to an IP address is called forward lookup Caching is an important part of the operation of the DNS At each stage along the way, from application to resolver to name server, information may be cached In normal DNS operation, to improve performance, the resolver will store the responses and referrals it has received so that future lookups for the same information can be answered immediately Caching is used to avoid sending queries across the network to DNS servers, speeding response time Because caching is an expected part of DNS operation, each domain name response (resource record) includes a “time to live” (TTL) value indicating how long information may be cached 4.2 DNS Security Extensions (DNSSEC) DNSSEC (DNS Security Extensions) is an important tool in increasing the security of the Internet‟s Domain Name System It is a set of extensions to the DNS for providing authentication and performing integrity checking of DNS data Authentication ensures that zone administrator can provide authoritative information for any particular DNS domain and integrity checking ensures that information cannot be modified accidentally or maliciously while in transit or in storage in the DNS DNSSEC provides a strong cryptographic signature of DNS data that the DNSSEC compliant resolvers can verify to ensure that the data received over the network hasn‟t been modified since it was originally DNSSEC-signed 352 ISSN:2249-5789 Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357 In DNSSEC, the server and the resolver both have to be security aware as the DNS server is required to support some additional types of DNS records Likewise the resolver should be able to detect the new DNSSEC extensions and must check DNS data for authentication and data integrity Any modification of the DNS data from what was originally signed at the authoritative source can be detected, thereby allowing a security-aware DNS resolver to discard corrupt or unauthorized data Although DNSSEC was standardized in 2005, it is not commonly used However, adoption of DNSSEC is expected to accelerate as the root DNS zone was signed in July 2010 can misdirect name resolution mapping, opening network data to capture inspection and potential corruption Many other types of threats have also been seen in which DNS system is used to carry out attacks on the other assets These different types of threats to the DNS, can be broadly categorized as below: • Denial of Service – In this type of attack the Internet users are kept away from using the DNS • Data Corruption - In this case there will be unauthorized change of information in the DNS) • Information Exposure – Here the information is disclosed about Internet users after examining their DNS traffic DNS Threats Since DNS is critical to the operation of the Internet, it must be secure from different types of threats and risks This portion provides information on some of the existing threats which lead to DNS failure and their counter measures for mitigating such risks A variety of threats have been seen to the DNS system including threats to the DNS infrastructure itself The most common types are :- 5.1 DNS Spoofing DNS spoofing means that a computer on the Internet has been able to advertise a false IP address for itself This is due to the easy setting up of one s DNS resolver and feeding it with false information It can also be done by the following:1 A malicious DNS advertises false IP address to a victim Subsequent DNS queries are sent bogus IP address, traffic is sent to wrong host Java applets could be created to spoof IP address in order to penetrate into insecure server This unprotected server in a network thinks that it being contacted by a trusted host but in fact, the machine on the end of the connection is operated by some malicious users DNS Spoofing is a serious attack based on the strong trust relations between client machine and their DNS server The DNS server can be attacked in many different ways but all rely on the translation between Domain Name and IP address 5.2 Cache Poisoning Another security concern regarding to DNS is the process of Cache Poisoning It is a process where attacks are launched on cache data of DNS in order to misdirect and intercept packets on domain name servers One simple type of attack is where bogus data from a remote name server is offered to a genuine name server, which in turn stores the misleading data in its cache By providing false host name and mapping information, the attacker 5.3 Denial of Service It is the most significant threat to the DNS and also the hardest to defend against In DOS, The attacker purposefully tries to disrupt service by creating failure / mistakes, in the DNS infrastructure itself by performing some malicious activities This results in DNS becoming slow or inaccessible and is often called a Denial of Service (DoS) attack In many a cases, both human as well as automated systems users of the DNS face increased delays, timeouts, and other performance related issues The worst-case may a complete disruption of all DNS-related and DNSdependent services Denial of Service threatens the DNS security, integrity and stability of its internal sub-component Within this category two different types of DOS have been seen:(1) Resource Starvation – Insufficient resources here the attacker tries to misuse the system resources like server CPU, memory, internet bandwidth etc because of which the DNS service becomes slow The attacker tries to flood the network, switches, routers etc with bogus traffic or tries to block the legitimate DNS requests and replies and disrupt the normal working of the DNS infrastructure (2) Resource Disruption – The attacker tries to disrupt the normal working by creating events which make the resources unavailable until some external event restores the resource - typically creates intentional electrical power failure which will bring down the servers till the power is restored The threat of DoS covers all components of the DNS including: Physical & network infrastructure buildings, power supplies, network connections 353 ISSN:2249-5789 Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357 Server infrastructure - servers and related system that allow for DNS queries to be sent and received Management infrastructure - processes that allows for the creation, modification, and deletion of DNS content Administrative infrastructure - support agreements and procedures, staffing, invoicing, and similar arrangements 5.4 Data Corruption Data Corruption in DNS can happen because of different reasons Some of the reasons are:1 When DNS responses don‟t match the intended, published data When someone has intentionally or accidentally changed the data in DNS servers in un-authorized ways As DNS queries and responses pass over the Internet, over an intermediate DNS server (resolver) which might have corrupt or incorrect data inserted into their cache because of attacks called as cache poisoning When an attacker sends answers to queries faster than the legitimate servers can, providing erroneous data to the application 5.5.Information Exposure The DNS protocol was originally designed as a mechanism to associate named resources to addresses without any concern for Privacy protection DNS queries and responses are transmitted without any form of encryption, and hence can be observed at multiple points DNS operators may also be capable of correlating requests and using them for other purposes At the same time there is a requirement that individuals should be able to use the DNS and the related WHOIS protocol in an anonymously as it would let the individuals perform DNS queries without having their requests observed and correlated with their identity Besides the above mentioned threats some more types which are not immediate operational type have been observed as follows:- minimum security restrictions are imposed by the routers and firewalls on its traffic As a result, DNS traffic has been used for several forms of attack 5.7.1 Fast Flux DNS As defined by ICANN‟s Security and Stability Committee “Fast flux” is an evasion technique used by the cyber-criminals and Internet miscreants to evade their identification, location and shutting down such web sites that are used for illegal purposes.28 In Fast Flux DNS, networks of typically compromised servers by malware are used as name servers This allows for rapid changes to DNS-related data, and helps attackers to delay or evade detection and mitigation of their activities 5.7.2 DNS as a Hidden Channel DNS requests and responses can be used as a hidden channel for communications [16] Several cases have been documented in which DNS has been used as the mechanism for communications between botnet command and control servers of the systems that make up the botnet Some tunnelling protocol like IP over DNS and TCP over DNS have been developed by the cyber criminals that allow arbitrary data to be passed over the DNS protocol Thus using such techniques DNS can be used by attacker to bypass network security mechanisms and compromise other internal systems 5.7.3 Application Corruption Attacks Similarly maliciously created DNS responses can be used to corrupt some applications In some cases, DNS responses can cause unexpected application behaviours They may be used to compromise systems As has already seen in web application, huge amounts of SQL injection and cross-site scripting attacks can lead to different types of attacks on the network resources It may be assumed that any data obtained over a network channel could be intentionally malicious or accidentally malformed In cases where application or library source code is unavailable [17], some caching resolvers have configuration options that allow filters to be applied to responses to reduce the risk of malicious data being supplied to applications Mitigating DNS Threats 5.6 Ossification Issues related to maintaining backward compatibility and implementing future upgrades resulting due to technological improvements is a critical problem Such a situation has been broadly termed as ossification [15] Due to ossification DNS has lesser ability to adjust to future changes in the Internet Ossification has also delayed the deployment of upgrading of technologies which are needed for security, stability of the DNS The DNS has a number of features as part of the original design or incorporated later on that make it resilient to many forms of disruption and attack Some such recent additions to the DNS system are “DNS Security Extension” also known as the DNSSEC and operational practices such as the deployment of “Anycast” [18] which provide increased protection against many of the common threats to the DNS 6.1 Denial of Service Threats 5.7 Threats from the DNS Since DNS is a core component of internet hence The mitigations for all forms of DoS attacks can be done by: 354 ISSN:2249-5789 Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357 a) By way of over-provision the infrastructure to withstand attacks b) Spreading out the infrastructure to different geographic locations, using independent facilities, systems and other technologies to remove the choke points c) Utilizing operational best practices that apply to other core IT systems, with welldocumented and mature processes and procedures that are reviewed and updated regularly 6.2 Stub Corruption Trusted stub resolver and its network path should be used It should be verified that the IP Address for DNS resolution services that are mentioned at /etc/resolv.conf on Unix-related systems and in the registry in Windows systems are the correct expected values Using DNSSEC will mitigate some of corrupted resolution paths 6.3 Caching resolver corruption Timely application of security packs and systems updates ensure that they are guarded against the known threats Although implementation of name server allows a server to act as caching resolver and also as an authoritative server, they should not be hosted on the same box As a best practice, separation of authoritative name service from caching resolution service should be done as it will mitigate various forms of data corruption such as cache poisoning and inappropriate responses to the authoritative queries 6.7 Query Prediction As discussed in “DNS Threat Analysis” [20], every message in the DNS has a 16-bit query identifier that is used to match responses to queries In combination with the 16-bit source port, this gives a total of 32 bits to uniquely identify a DNS transaction between any given source and destination As early as 1986, it was recognized that this provided only a weak defence against injection of bogus responses by a malicious third party In particular, it is possible to take advantage of “the Birthday Paradox”, to predict a query identifier and then inject a response [21] 6.8 Man-in-the-Middle DNS traffic is not encrypted An attacker with control over the intermediate network can implement a variety of man-in-the-middle attacks 6.9 Cache Poisoning Predicting queries and man-in-the-middle attacks allow for an attacker to insert bogus data into a cache, an attack known as cache poisoning, discussed in detail above The key mitigation for all of these protocol corruption attacks is DNSSEC, which allows a security-aware resolver to verify that the DNS data have not been modified in transit With this capability, it no longer matters that an attacker can predict query identifiers, can sit in the middle of a DNS transaction, or can attempt to poison the cache since any attempt to modify the DNS data will be detectable 6.10 Data Corruption 6.4 Intermediate systems Intermediate systems are critical as they play an important role in DNS resolutions and hence should be updated timely By using DNSSEC any modifications of data in transit can be detected by the validating resolver Unfortunately, the use of DNSSEC is hampered by middle-boxes that inhibit used of DNSSEC by incorrectly handling requests that ask for DNSSEC-signed responses or the responses themselves [19] 6.5 Authoritative mitigation server corruption In addition to mitigations previously discussed, it is important to ensure the DNSSEC keying material is managed to minimize the chance that an attacker can steal keying material and impersonate an authoritative server Best practices for DNSSEC deployment use “offline signing keys” minimizing the possibility of key theft 6.6 Protocol Corruption Protocol Corruption takes advantage of limitations or vulnerabilities in the DNS protocol itself to corrupt DNS data There are three broad categories of Protocol Corruption: DNSSEC can be used to guard against data corruptions as it was primarily designed for this reason Other techniques like constant vigilance of the system resolvers and application of necessary security patches should be done 6.11 Information Exposure Information Exposures are unauthorized releases of personal and other data associated with the DNS and DNS queries These exposures can occur at both the administrative level as well as at the network and system level with attacks known as “Cache Snooping” and “Zone Walking” Protecting against Cache Snooping related to authoritative servers General protection of data including secure data paths and methods to protect against system compromise are the countermeasures 6.12 Mitigating DNS as a hidden Channel Mitigation of hidden channel use of DNS requires detection Constant monitoring may help to detect unusual use patterns, such as a large number of TXT responses being sent to a particular server Analysis of DNS traffic within an enterprise can provide a baseline to detect the hidden channel DNS problems 355 ISSN:2249-5789 Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357 Our Approach Internet supports both TCP based (port no 53) and UDP based (port no 53) transport mechanism for DNS However majority of the communication is UDP based Since DNS does not necessarily require the establishment of a TCP connection it allows the attacker to redirect the response away from its network to the victims host by spoofing the source IP address as the victims IP address By exploiting this vulnerability the attacker sends a small request to the DNS server to which the server may respond with a very large reply This large reply can be redirected by the attacker to the victim machine and thus consume most of the victim‟s resources Daniel Bernstein has reported that a 36-byte DNS query can result in a 3995-byte DNS response a proper handshake actually takes place The sender sends the FIN packet which is acknowledged by the receiver by an ACK packet and if the receiver also wants to terminate the connection at the same time it also sends a FIN packet to the sender This FIN packet is once again acknowledged by the sender by sending ACK packet By using the above concept it can be ascertained that the communications to the DNS servers are being send by legitimate DNS Resolvers and servers Hence it is suggested that all DNS based communication TCP should be used as the transport mechanism rather than UDP as it will greatly improve the security aspects of DNS References:- Such attacks are classified as DNS amplification attacks as it amplifies the attacker‟s ability to consume resources on the victims system Since DNS queries are small, the attackers queries can go undetected which might lead to a distributed denial of services attack on the victim‟s system Since a spoofed IP address is used by the attacker it becomes very difficult to trace such attacks.DNS has been used for amplification attacks for some time, DNS Amplification attacks make use of either authoritative servers or resolvers to reflect data towards a target As per the frame format defined for DNS in RFC 1035 there is a 16 bit field called identifier which can be assigned value by the program that generates any kind of query This identifier is copied in the corresponding reply and can be used by the requester to match up replies to outstanding queries However there is no provision for any kind of sequence numbers As most of the communications are UDP based hence there is no mechanism to check whether the packets coming in or going out are legitimate nor not This forms the basis for generating different types of attacks like DNS Spoofing, Cache Poisoning, Zone corruptions, Session Hijacking, Data corruption, Protocol corruption etc Although the use of UDP makes the system faster yet it is suggested that all DNS based communications should be TCP based rather than UDP When TCP is used for communication then a threeway handshake will take place for graceful communication to happen The sender will send a SYN packet which will be acknowledged by the receiver by sending back the SYN ACK packet which is again acknowledged by the sender by sending an ACK packet after which the data transfer phase begins When a TCP connection closes gracefully then also http://www.microsoft.com/presspass/press/2001/jan01/ 01-24dnspr.mspx 2.http://www.pcworld.com/businesscenter/article/185458/ dd os_attack_on_dns_hits_amazon_and_others_briefly.html 3.http://www.iis.se/en/pressmeddelanden/felaktig-dnsinformation-2 http://www.securityweek.com/content/reports-massivedns-outages-germany 5.“Formal-Specification Based Approach for Protecting the Domain Name System By Steven Cheung, Department of Computer Science, University of California, Davis, CA 95616, and Karl N Levitt, Department of Computer Science, University of California, Davis, CA 95616 “Enabling Secure On-line DNS Dynamic Update” by Xunhua Wang, Yih Huang, Department of Computer Science, George Mason University, Fairfax, VA 22030 USA , Yvo Desmedt, Department of Computer Science, Norida State University, Tallahassee, FL 32306 USA and David Rine, Department of Computer Science, George Mason University, Fairfax, VA 22030 USA “Securing DNS Services through System Self Cleansing and Hardware Enhancements” by Yih Huang, David Arsenault, and Arun Sood , Department of Computer Science and Center for Image Analysis, George Mason University, Fairfax, VA 22030 “Security vulnerabilities in DNS and DNSSEC” by Suranjith Ariyapperuma and Chris J Mitchell, Information Security Group, Royal Holloway, University of London, Egham, Surrey TW20 0EX, UK “Enhancing DNS Security using the SSL Trust Infrastructure”by Christof Fetzer and Gert Pfeifer, Dresden University of Technology, Department of Computer Science, Institute for System Architecture, 01062 Dresden, Germany and Trevor Jim, AT&T LabsResearch, 180 Park Ave., Florham Park, NJ, 07932, USA 10 “Cache Poisoning Detection Method for Improving Security of Recursive DNS” by Yong Wan Ju, Kwan Ho 356 ISSN:2249-5789 Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357 Song, Eung Jae Lee, National Internet Development Agency of KOREA and Yong Tae Shin, Internet Communication and Network Lab., Soongsil Univ 11 “Public Key Validation for the DNS Security Extensions” by Daniel Massey, USC / ISI , Ed Lewis, Network Associates, Inc., lewis@tislabs.com, Olafur Gudmundsson, Ogud.com, Russ Mundy, Network Associates, Inc., Allison Mankin, USC/ISI 12 “Towards Improving DNS Security, Stability and Resiliency” by David Conrad, Internet Society., www.internetsociety.org 13 In this case, ICANN is acting in the role of the Internet Assigned Numbers Authority This role could be moved to another organization, but the function would be same 14 http://www.root- servers.org/ www.internetsociety.org 15 http://www.merriam-webster.Com/dictionary /ossification 16 http://www.oe.energy.gov/DocumentsandMedia/ DNS_Exfiltration_2011-01-01_v1.1.pdf 17 http://www.kb.cert.org/vuls/ d/ 844360 18 http://www.ietf.org/rfc/rfc4786.txt 19 http://www.icann.org/en/committees/security/sac035.pdf 20 http://tools.ietf.org/html/rfc3833 21 http://www.secureworks.com/research/articles/dnscachepoisoning Biographical notes Alok Pandey is Senior Systems manager and faculty member at B.I.T (MESRA), Jaipur Campus His qualifications include B.E.(EEE), MBA He has also done MCSE, RHCE, CCNA, IBM Certified E-Commerce and diploma in Cyber law He has a rich industrial working experience of more than 17 years and also a teaching experience of about years in the areas of Data Communication and Computer Networks, Information Security, E-Commerce, Systems Management , ERP etc He is also a member of CSI, IAENG and ISOC His research interests include Computer Networks and Network Security Dr Jatinderkumar R Saini is Ph.D from Veer Narmad South Gujarat University, Surat, Gujarat, India He secured first rank in all three years of MCA in college and has been awarded gold medals for this He is also a recipient of silver medal for B.Sc (Computer Science) He is an IBM Certified Database Associate-DB2 as well as IBM Certified Associate Developer-RAD He has presented 14 papers in international and national conferences supported by agencies like IEEE, AICTE, IETE, ISTE, INNS etc One of his papers has also won the „Best Paper Award‟ 11 of his papers have been accepted for publication at international level and 13 papers have been accepted for national level publication He is a chairman of many academic committees He is also a member of numerous national and international professional bodies and scientific research academies and organizations 357 ... their paper “ FormalSpecification Based Approach for Protecting the Domain Name System [5] formally specify a DNS wrapper that examines the incoming and the outgoing DNS messages of a name server... Caching name servers each serve multiple stub resolvers domain to other name servers The root servers know the name servers for domain1 .com and within those name servers the west .domain1 .com domain. .. for a particular domain The authoritative name servers, contain data about primary name servers or delegated name servers for that particular domain Finally these name servers maintain data for