Domain Name Service is transport over the Internet by means of a distributed software system called the Domain Name Server. DNS play important role it performs various operations in the Internet for users of higher layer services like the www, ftp, email, printing and other end-to-end services. Really, the ample majority of the world's Internet users don't know the existence of DNS, or of the important role it plays every time when they type in or clicks on a Uniform Resource Locator (URL) within their www.websitename. On the other hand, if DNS is not working properly, the all users who are using specific DNS, Internet such as "world wide web" is, will not work, or unavailable to them. DNS has been likened to water or electric utility in that the service it provides is not the end service, but, without it, nothing associated with that utility service will function (e.g. Fan, Generator and etc.)
3. DNS History
The Domain Name Service was primarily introduced to support the increasing E-mail users on the ARPANET, presently it supporting the Internet on a global scale. After invention of DNS alphabetic names were introduced on the ARPANET, so usability increased since alphabetic names are used. Alphabetic names are very easier to remember than numeric addresses. Host names were also helpful for implementation of network-aware computer programs, so they should compose a constant host name without care about modify to the physical address because of network modifications. Then also, the equipments of the basic network was still depends on numeral addresses, so each site keep up a "host.txt" file that gives a rendering between host names and network addresses in a set of easy text records that should be easily understand by a person or program. Many of the useful innovations spawned by the Internet were, in fact, a result of necessity, as opposed to a foreordained plan, and DNS is one of them. From the late 1960's through 1970's, the number of host computers (now called servers) connected to the Arpanet/Internet, were a very manageable number. Therefore it was possible to maintain a simple text file, a flat file database if you will, that could be read by humans as well as computers, and which contained the mapping between the textual host names and their corresponding numeric IP addresses. In fact, this task was personally carried out by John Postel4, one of the pioneers of the Internet and the IETF and a highly accomplished networking engineer. This file was distributed to each of the host computers attached to the Internet using the File Transfer Protocol (FTP). As the network grew, however, and especially once the Internet reached "escape velocity" in terms of host growth, the bandwidth overhead of these FTP's became too burdensome on the network itself. In the figure we can see the growth rate of the Internet from Jan-19 94 to Jan-2010.
4. Working Process of DNS
DNS stands for Domain Name Service. DNS converts a host's name into its IP address. Internet is a network of networks so its deals with IP addresses only. Every host holds an IP address that should be known to any other host, then only two hosts able to communicate. But it would be very hard for humans to remember all the IP addresses are using on the Internet. DNS will create possible mappings between IP addresses and names locally to each computer. DNS gives the way to know the IP address of any host on the Internet. It is no different than any other directory service. The IP address is computer friendly but not people friendly. It is difficult to remember and hard to type. For this reason, as well as an IP address computers are also given a people friendly name. The names are assigned using the distributed hierarchical lookup system known as Domain Name System (DNS). In the DNS each machine has a unique name consisting of multiple parts separated by dots (Not unlike IP addresses, except there is no limit to the number of parts)
DNS SYSTEM
Y?
HOST Y
IP=YY.YY.YY.YY
HOST X
IP = XX.XX.XX.XX
Y=YY.YY.YY.YY
DNS is also a hierarchical service it had tree like structure. Indeed name has a structure: it can be server.web.google.com or pc34.labD114.univ-australia.au. The first part of a DNS name is the machine's name, followed by a hierarchical list of domain names. The first domain is usually an identifier for the department to which the machine belongs. The next is usually an identifier for the organization as a whole. The next identifies the type of organization and the last identifies the country. The Mathematics and Computing web server is found on machine "www.sci.usq.edu.au."The machine name is www; the department/faculty name is sci, the organisation name is usq, the organisation type is edu and the country is au. This hierarchical list of domain names is gradually breaking down as commercial interests have begun to dominate the Internet. Companies prefer short and easily remembered domain names and are not willing to accept the existing convention. Therefore you will find domain names that do not follow the convention. The structure is shown in the below figure.
.au
.COM
Yahoo.mail.com
web.yahooo.com
Server.web.yahoo.com
cam.au
edu.au
Google.com
Yahho.com
Pra.com.au
usq.edu.au
Sci.usq.edu.au
Ws.comapny2.net (local)
Employee.company2.net
(what is the IP of
www.company3.net?)An important feature of the DNS is that a single machine can have one or more aliases assigned to it in addition to its true name. This feature is widely used to give descriptive names to server machines. For example the Department of Mathematics and Computing at USQ maintains both a web server and an FTP server. The address for the web server is www.sci.usq.edu.au, The address for the FTP server is ftp.sci.usq.edu.au. Both names resolve to the same IP address and neither is the machine's true name.
Iterative and Recursive Queries
Now we will see what the difference between Iterative and Recursive Query. Normally when the host queries the DNS server it will be a Recursive query. In case of Recursive Query host wants an answer from DNS server or an error message, until host got any of the answer form DNS server then only the query will stop searching. In case of Iterative Query host basically asks the answer if DNS server knows it will give answer otherwise it refers to "referral" server it is a name of a server, it may have the answer for the host query.
Recursive Queries normally from the clients hosts so they need to take care about whole search process, whereas Iterative queries normally come from local DNS servers. We can see the two requests in the below figure.
Iterative Queries
Ws of .net domain 2
3
4
Ws.company3.net (main server)
5
Recursive Queries
1 6
www.company3.net
7
Threats of DNS:
5. Protocol Attacks
We know the DNS protocol attacks are basically depends upon the pitfall of the DNS protocol implementation on the internet. When we are talking about protocol attacks the major attacks are:
DNS Spoofing
DNS ID Spoofing
Now we are going to explain the above given terms.
5.1 - DNS spoofing:
DNS spoofing is a very common attacks, DNS spoofing is a term assigning to the action of acknowledge a DNS request that was expected for another server (a "True" DNS server). This can be in a server to server interchange (The DNS server asks something else for a mapping) or in a client to server interchange (when a client asks a DNS server for a mapping). There is no functional difference. The hacker "spoofs" the DNS server's answer by answering with the DNS server's IP address in the packets' source-address field. DNS Spoofing is the art of creating a DNS entrance to point to different an IP before it be say to designate to. If you want to read better, here we can view an example. If any person on their web browser and want to watch the news on www.abc.com, no need to hesitate of it, they simply typed above mentioned URL in their address location push the enter button. Now, we will see what's happening behind the browser Well primarily, their browser is pass away ask to a DNS Server to receive the appropriate IP address for www.abc.com, now the DNS server says their browser the IP address of ABC, so your browser to connect to ABC's IP address and gives the confine of the home page. After one minute you will get a message saying that BBC's web site has been closed because they don't have cash to pay for their web site. The person amazed, after this you call and tell this incident to your best friend on the phone, after recognize your words receptionist laughing at the person, he went to ABC web site to analyse by himself. You are amazed when he says you he can browse the news of the day as normal and you begin to surprise what is happening here.
5.2 - DNS ID Spoofing
We know that when a machine "A" wants to interact with a machine B, the machine "B" always demands the machine "A" IP addresses. Anyhow in most of cases, Machine A only has the name of "B", in this inspect, the DNS protocol is used to analyse the name of B into its IP address.
Therefore, a DNS query is transfer to a DNS Server announce at "A", requesting for the IP address of the machine "B". Simultaneously, the system "A" got a miscellaneous identification number to its asking which could be show in the replay from the DNS server.
After the replay from the DNS server will be acquire by "A", it will just examine two numbers if those are similar, in this inspect, the replay is accept as valid, and otherwise it will be simply ignored by "A".
But unfortunately this concept is not safe completely. Anyone can a hack system, and get this ID number. Somebody are for example on LAN, some other person who runs a sniffer can intercept DNS requests on the fly, watch the ask for ID number and transmit you a cheat respond with the right ID number but with the IP address of his taste. Then, no need to understand it, the machine "A" will be talking to the IP of hacker's choice thinking its "B". We all know, the DNS protocol depends on UDP for requests and TCP is used only for zone transfers, so any one can painless to transfer a data coming from a cheat IP since there are no SYN/ACK numbers unlike TCP, UDP cannot give a less protection against IP spoofing.
www.bbc.com?ID=11
A sniffing DNS server
Hacker
www.bbc.com=67.67.67.67 ID=11
A Fake replay DNS server
Hacker
The overall view of protocol attacks shown below figure
DNS cache poisoning
Related data attacks
Unrelated data attacks
Client Misdirection
DNS ID spoofing
DNS spoofing
7. Unrelated Data Attack
Unrelated data attack was the first attack, the easiest and the most widely used:
The attacker asks the victim DNS for a nonexistent name mapping in a domain for which he controls the DNS. The attacker uses a "recursive" query so that the remote DNS server will make further inquiries by itself.
The remote DNS, which is don't know of such mapping, will go and ask the DNS server responsible for the required domain. Remember this server is under the control of the attacker.
The attacker will answer, and add in the answer anything he wants to be cached in the victim DNS' cache. This way, he will have poisoned the cache of the remote DNS server.
Hacker
Nonexistent.hacker.org
Ws.victim.org
Ws.hacker.org
Nonexistent.hacker.org?
Answer + anything the hacker
Wants to be cached in the
Victim's cache
6. Related Data Attack
This attack is exactly the similar as an unrelated data attack, but this time the attacker has to make the "additional" information related to the original query. He solves this problem by adding MX, CNAME or NS records, which point to unrelated data. These three records we can find in a DNS database are not a real "mapping" between an IP address and a hostname. They point to some other useful information MX: mail server for a domain, CNAME: Canonical name for an alias, NS: DNS servers for a domain. So, the information in these records is "related" to the original request, but they can point to totally different information the attacker wants to be cached.
8. DNS Sever Side Attacks
8.1 - Email Spoofing
Email spoofing attack is achieve by sending the registered request via an e-mail message containing the spoofed return address that is the trusted source to update the URL IP address mapping for a specific URL under the control of the spoofed source. The attack is powerful if the attacker is able to kidnap the email response to the spoofed source from the registered IP, so that it never reaches the actual source that is the victim organization. This kidnapping of the email response can be achieved indirectly by flooding the valid recipient's email (inbox) so that the confirming email from the registrar never gets through. So this way the source will not even be aware that this fake transaction took place, and they will only discover the attack when, for example, the number of visits to their, e-commerce www website suddenly go to zero, this attack frequently works because such administrative email requests are often verified only by examine the return email address. New processes are already in place with many domain registrars (e.g. VeriSign/Network Solutions) that accommodate, much stronger authentication methods than an easily spoofed email address
8.2 - Known Security Related software Faults
As with more difficult software applications, and particularly ones that deal with changeable length inputs (e.g. character strings), BIND has had its share of hidden software defects, some of whose effects were buffer overflows as a result inaccurate processing of such changeable length inputs. Buffer overflow attacks are well documented in many Internet applications and in the case of earlier versions of BIND, these downfalls could then result in an attacker gaining root user access to the underlying server running the attacked DNS. With such root access, the attacker can then do pretty much as they please with respect to the functioning of DNS, because they can take on the identity of a highly trusted network application. Once a DNS has been kidnapped by this means, it is then possible to convince other DNS's (secondary DNS) which are authoritative for the same domain as the kidnapped DNS server, to arrange a complete copy of their domain URLï€ IP address mapping table, this means, the attacker can then calmly find out the IP addresses of the client and server computers that are on the attacked network.
8.3 - Improper DNS Configuration
Two surveys from early 2007, the first, of 978 www sites in the Fortune 1000, and a second, of 5000 random sites in the .com domain suggest that 25% and 38% of the respective sites had DNS configurations that were either incorrect or weak from a security perspective. Definitely, improper configuration, resulting in insecure applications is a problem that is not limited to DNS, but, the effects of the attacks that can exploit these insecurities can be significant as I have already described in this paper
9. DNS Client Side Attacks
From the client side also we need the response if client want the DNS service must be operating as well. The client side elements of DNS reside in the protocol stack and the www browser of the PC which is ask for the services of DNS. Any of attack on a PC that allows an attacker to run "code of their choice" will make these client side components vulnerable to attack as well. A common attack of this type is one where the attacker diverts the settings for the IP address of the DNS server or servers (primary and secondary) that are controlled by each Network Interface Adapter (NIC), and basically by the TCP/IP protocol stack. The final effect of this kind of attack will be that domain names will be resolved to the IP address of the attacker's choosing.
9.1 - Trojan. QHosts Attacks
This specific virus is a non-self-replicating Trojan attack of the Microsoft Windows operating system (Windows 2000, Windows 95, Windows 98, Windows Me, Windows NT, Windows Server 2003, and Windows XP). This attack modifies the Windows Registry settings associated with the DNS server so that such settings will no longer point to the proper DNS server for that client but to the IP address specified by the attacker. It also modifies a file called the "hosts" file to insert the domain names of about 20 well known search www sites (e.g. www.google.com) and associate those URL's with the aforementioned attacker IP address.
9.1.1 - Method of Attack
An advertisement displayed at the http://www.fortunecity.com//fc428x90smartad. It is known to load a remote site containing this Trojan. This Trojan is depends up the weakness of the Microsoft Explorer to get installed on the local system. Once installed, the Trojan redirects the Domain Name queries to a specified address.
9.1.2 - Attack Severity
The www site of Symantec's categorizing the damage caused by the viral payload as "Diminish Performance". In common, the severity of such an attack on the client side DNS functionality can vary from a frustrating anger to something much more serious if the attacker's DNS were designed to subsequently spoof legal www pages such as, say, www.bank.com, www.first.com, or some other commercial services www site in order to produce account information. As a result any such an effect must be treated as a potentially significant threat.
10. DNS server Side Attacks Mitigations
10.1 - Subnet Diversity
Subnet diversity is an advice which was determined carefully by Microsoft with the outage of their www sites that was described previously in this paper, says that your primary and secondary DNS 's should always be configured to operate on different sub-networks within your network and each sub-network must have a different route to the Internet. The twist for Microsoft is that, as a company at least, they already had learned this lesson because it was included in their own user documentation for their products. In an article published at Dent's www site, Robert Lewis refers to a survey made after to the Microsoft attack which found that 38 percent of the companies in the.com domain have the same DNS design flaw, that is, both DNS's on the same subnet and/or connection to the Internet.
10.2 - OS Platform Diversity
The OS platform diversity advice says that the primary and secondary DNS should be implemented on an operating system, each one, separate from the other. However if for example
The primary DNS is implemented on Linux, then the domain controller should implement the backup DNS on Open BSD. Doing this will commonly make it more complex for an attacker to take down both DNS's by means of the same attack, say, on a specific known buffer overflow condition in one of the two operating systems
10.3 - Separate Public DNS from Internal DNS
In general frequently, a network will supply DNS to the Internet for its domain as well as supplying DNS to the internal network of the company. This advice says that the Internet facing (public) DNS functions should be situated on a server that is on the perimeter network sometimes referred to as the DMZ, while the internal facing (private) DNS functions should be situated on a separate server that is inside of your firewall or inner firewall if you are operating a DMZ with a second, outer firewall. That way, if the public DNS is adjusted, it will be impossible for the hackers to find the URL's and IP addresses associated with the internal network. This type of operation is called to as "Split-Horizon DNS".
10.4 - Don't Share DNS server with other Applications
This paper has already outlined the damage that can be caused by an attacker that exploits a software flaw in the DNS software. If there are other applications running at the same time on the server that is providing DNS, then, there is the possibility, however, remote, that that other software can be compromised, thereby allowing the attacker to gain control of the hardware and OS of the server that is running DNS. This recommendation mandates that no other software application should be hosted on the same server as one that is hosting DNS.
It should be noted that this practice is at odds with certain bundled operating system products such as Microsoft Windows Small Business Server, which bundles a complete server operating system, a WWW server, and Exchange email server, and, optionally, an Structured Query Language (SQL) data base server all on one machine along with Microsoft Active Directory services. Of course it would be possible to turn those extra services off, and run the DNS on a separate server, but the whole purpose of this operating system bundle is to reduce overall cost for the user. It should also be noted that such a bundled product will violate the hardening technique referenced below in section 9.9 "DNS Functional splitting", for the very reason that, in such bundled systems, there is only one DNS server unless the enterprises chooses to implement stand alone servers at a higher upfront cost for, at a minimum, the extra hardware for a separate computer.
10.5 - Restrict Zone Transfers
In this paper we already described an attack scenario where a compromised DNS requests a zone transfer from its domain peer (primary or secondary). By restricting (i.e. accepting) zone transfers only from authorized name servers, the likelihood of success of this kind of attack can be minimized.
10.6 - Configuration Hardening
As we discussed earlier in this paper, BIND is relatively complex software application that runs on UNIX, which is, itself a complicated, though well understood operating system. By carefully following careful guidelines for the initial configuration of a DNS, it is possible to reduce the chance of compromise of the system once it is put into operation. Rob Thomas maintains a www site which provides a template for securing BIND, (www.cymru.com/~robt/Docs/Articles/secure-bind-template.html). A corollary recommendation to this one is to employ a close observation application such as Tripwire and schedule it to run every day in order to verify the integrity of the DNS binaries, configuration files(s), zone data and other important files stored on the DNS server. For users of BIND version 8.1.x, Psionic Technologies (www/psionic.com) arrange a guide for securing that release of BIND when operating in the Open BSD/FreeBSD environment.
10.7 - Release Currency
As will all network accessible software systems, it is difficult to maintain currency with the latest release or patch update for the software that is providing DNS. This is oftentimes easier said than done, considering the variety of such network accessible systems that must be commonly updated and the common practice of many systems security managers and technical experts to leave the administrative work as a lower priority in an oftentimes overloaded schedule.
Below, however, clearly points out the risk of delaying action once an advisory pertaining to DNS concerning security vulnerability and its remedy has been released. As the bar graph shows, within 30 days of the CERT announcement, there was a dramatic rise in the number of reported incidents pertaining to the DNS vulnerability that was communicated in the associated CERT Advisory. The number of incidents tapered off approximately 8 months after the date of the original announcement. It is impossible to judge, from this data, what higher priorities prevented the affected system operators from acting more quickly to implement the remedy indicated in the Cert Advisory but the risks of inaction seem clear.
10.8 - DNS Isolation
This recommendation order that the DNS application be isolated (the more technical phrase is to run DNS in a "chroot jail") and to always run it as a nonroot user. Doing this will additional protect a server, whose DNS application has been compromised, against the attacker after gaining root privileges to the underlying OS and server hardware.
10.9 - DNS Functional Splitting
In addition to Split-Horizon DNS is possible to separate DNS functions into Advertising Name Server and Resolving Name Server functions. By running these functions on two separate servers, it is thereby possible to customize the behaviour of each server and to implement more rigid purpose specific restrictions on each one.
10.10 - DNS Version Number Hiding
This recommendation demand that, in order to make the job of a potential burglar to the DNS more difficult, responses to queries which request the version number of the software should always is hidden from external access
10.11 - DNS Application Diversity
The last recommendation is to consider using a version of DNS software for one of your two DNS's that has been implemented by a different supplier from the supplier that developed the other version of DNS software that you are using.
11. DNS Client Side Attacks Mitigations
Most of the hardening that can be performed on client computers falls into the non-specific category of "safe computing" practices which are well documented at the www sites all of the anti-virus software providers and will not be repeated here. Some might argue that given the large number of vulnerabilities in Microsoft's Internet Explorer Browser, which are well documented at the Pivx Security www site, and, not all of which pertain to directly to DNS vulnerabilities, ,that the user is better off using a different browser, such as Netscape Navigator, when operating with a Microsoft OS. Certainly, given the overall functional overlap between these two software products, that is Netscape Navigator, and Microsoft Internet Explorer it would be a smart practice for the user to be familiar with both products, and to maintain an awareness of the latest
exploits against one versus the other so that the one can be "fired up" when the other is in "high seas" as a result of a particular exploit for which the A/V signature file update is not yet available. Unfortunately, the Trojan.Qhosts One specific protection that can be implemented at the firewall level, however, to stop the exploit from succeeding by blocking DNS queries to IP addresses other than those that are known "valid" DNS addresses for the network in question. That way the system administrator can be a) alerted to such invalid attempts, and b) begin remedial action on the system that has been compromised.
11.1 - Dents
Dents are an implementation of the server side of DNS and it was developed for higher performance and better server management. According to Chor, the design of Dents is very clean, which should contribute to its overall security (http://www.dents.org).
11.2 - Djbdns
Djbdns is a secure replacement for Bind in which security was forethought as opposed to an afterthought in its design. It is structured as a collection of small, independent, and mutually distrusting programs, each of which runs in its own chrooted jail. Its author, Daniel J. Bernstein, has actually offered a monetary award to the first person to publicly verify a security weakness in the latest version of the system (http://cr.yp.to/djbdns.html).
11.3 - MaraDNS
MaraDNS by design goes after the problem of buffer overflow by using specially written software to perform string handling, which, presumably, performs the necessary limit checks that are not performed by the widely available standard library routines that software engineers often use to get the job done. It is designed to operate on both Linux and UNIX systems as well (http://www.maradns.org).
Buffer overflow attacks are well documented and the text, "Building Secure Software", by John Viega and Gary McGraw devotes a full chapter to the root causes of buffer overflow vulnerabilities and the various programming techniques that can be utilized to eliminate these kinds of vulnerabilities. In these authors' opinion the true root cause of such buffer overflow attacks is the non-existent bounds checking on arrays and pointer references in both the C and C++ programming languages, which have been in use for many years.
11.4 - CustomDNS
CustomDNS is a modular DNS server that is written in the Sun Java programming language and in Perl programming language.
(http://customdns.sourceforge.net/)
11.5 - Microsoft DNS
Of course the Microsoft Server operating systems including Windows NT Server, 2000 Server, and Server 2003 contain an implementation of DNS and, in addition, since the release of Windows 2000 Server, and the introduction of Microsoft's Active Directory Service, it is possible to integrate the Zone files of DNS into the Active Directory. This form of operation is referred to as Active Directory Integrated DNS operation and is explained further along with its benefits in the following Microsoft document.
(www.microsoft.com/technet/treeview/)
12. The Future Evolution of DNS
Given the overwhelming "market share" of BIND in the extant DNS's of the Internet, it does not appear that there will be a near term migration to any other software platform, despite the efforts of others as documented in this paper above to develop viable alternative implementations for DNS. This speaks to both the durability of the DNS architecture as specified in the relevant IETF RFC's and the quality of the implementation of BIND, despite the exploits carried out to date against that system. The most recent release of BIND from ISI is version 9.7.0-P2 and of this paper highlights the features contained in that release. In addition to supporting the next generation IP protocol, IPV6, and support for multiprocessor configurations, which will facilitate the implementation of higher performance.
12.1 - DNSSEC Support
The IETF has published an RFC, # 2065, "Domain Name System Security
Extensions"31, which describes the extensions to DNS that provides integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. The extensions also provide for the storage of authenticated public keys that is necessary in order to allow security aware resolvers to learn the authenticating key of zones that are present in addition to those zones for which such resolvers are initially configured. The extensions described in the RFC also provide for the optional authentication of DNS protocol transactions and requests. DNSSEC provides for the digital signature of responses to DNS queries, which will eliminate the problem of DNS spoofing and the consequent potential for cache poisoning (unless the DNS is compromised by some other software failure). DNSSEC does not, however, address the question of bogus queries, which would typically come from an attacker who is mounting a DOS/DDOS attack on a particular DNS.
12.2 - TSIG Security Improvements
TSIG (Transaction Signature) is the means by which BIND signs transactions that it issues. In BIND 8.X.X TSIG is supported for update requests from one DNS to another. TSIG uses a mechanism called HMAC-MD5 to authenticate the sender and message content of each update request. HMAC-MD5 is a symmetric key encryption algorithm, and, therefore, requires that both the sender and the recipient have the same key which must be kept secret. In BIND 9.x, TSIG support is added for queries, the NOTIFY protocol and for zone transfers.
13. Conclusion
This paper has examined a key service associated with the Internet, the Domain Name Service, which must be continuously available in order to allow efficient navigation across the Internet for www browsing and email services. DNS service has been available on the Internet since the early 1980's but by the late 1990's as www growth exploded, DNS became a target of opportunity for malicious hackers. The security challenges that arise with respect to DNS are relatively well understood and reasonable countermeasures have been made available by various organizations to deal with most of these challenges. New versions of DNS software are under different stages of development by various groups and organizations, but it is anticipated that the dominant version, called BIND, will continue to be used for the foreseeable future for the vast majority of the DNS servers extant in the Internet. As with most network accessible applications, prudent system administration is essential in order to provide the most effective protection against cyber attacks against DNS.
