Abstract
The Domain Name System (DNS) is a naming system which transforms human readable domain names, into machine readable IP addresses and vice versa. The DNS servers create a database entry for each domain and send the equivalent IP address when they receive a query. DNS servers synchronize themselves with the authoritative DNS sources. When a query came to DNS server, it caches this request for future queries. If this request comes from a non-authentic client and has cached by DNS server, this causes a poisoned cache. This request may come from an improper software, a wrong configured name server or a malicious software which is created to exploit the DNS system.

Conventional DNS Query

Let’s explain this with an example. At first, the client makes a request for www.example.net to the IPS’s DNS server. The DNS server knows that this client is not an authoritative for the domain, so it also knows that it has to find it out of its cache, not in the local zone.

The DNS server forwards this query randomly to one of its 13 root servers. The root server receives this query but know nothing about this new domain. But it knows the Global Top Level Domain (GTLD) servers which are responsible for .net domains. GTLD server receives the same query from root server. If it also knows nothing about this domain, it adds a referral to the query and sends it back.
This cycle returns until one of the servers knows the exact answer of our query. This true equivalent of the domain is called A Record.

The DNS server also files away this answer into its own cache for the future queries.

A Normal DNS Query (from www.unixwiz.net)

Figure 1 shows a normal procedure of DNS query. Here, the client sends a DNS query for the site www.unixwiz.net. The local recursive nameserver doesn’t know the answer and asks to an other root server. It sends back the message with a referral to an other root server. Local server tries all the authoritative root servers, until it finds the closest name server which is in the same domain with the target site. Finally, it sends a query to that name server and receives back the IP address.

Cache Poisoning
The previous scenario was the way how a DNS query should be. The DNS server caches the A Record for future queries, but not forever, just for a while. This time interval is defined by the Time To Live (TTL) variable in the server configuration, and the only authorized person is the administrator of the DNS server. During TTL, each query for the same domain, will be answered from the local database. After the TTL passed, the record in the server database will be dropped and any query will cause a complete DNS cycle.

If our bad guy wants to redirect the innocent clients to his malicious site rather than the original “good one”, he has to change this local database entry with his fake data.

Indeed, it’s not so easy to send random DNS packets to the server. Because, DNS servers just allow the expected packets from other servers. And they have some specific messages between each other, that make the connection unique. Communication between servers is over UDP ports that the query (Question and Query ID of the DNS packet) was sent through.  So, the bad guy has to know these data to send a response to DNS server, which is like coming from an authoritative root server.

The method he used is, sending a query for the target site and replying his own query before the original root server will. Figure 2 shows this process over an example.

DNS Server Cache Poisoning (from www.unixwiz.net)

In this example, the bad guy sends a query to the DNS server for the target site www.bankofsteve.com. DNS server doesn’t know the IP address of this site and sends a query to a root server. The bad guy starts to flood at this point with increasing Query IDs. If he can find the true Query ID as fast as possible and sends back the poisoned DNS message to the victim name server with this Query ID, the DNS server accepts this response rather than the original one. In this example, the bad guy sends his malicious site’s IP address as a response of the original bank site query, before the bank’s original name server replies the query. The victim nameserver rejects the original nameserver’s response, because the Query ID will not be expected, after the bad guy sends the message by using this ID.

Dan Kaminsky Method for Cache Poisoning
In 2008, Dan Kaminsky who is a security researcher and Director of Penetration Testing for IOActive, found a way to poison not just the addresses one by one. He discovered a way to change the authority records too.

In this method, the basic idea is same with the early cache poisoning method, but there is a difference. The bad guy server floods the victim server with the response of the target site query and the authoritative record for the target domain. This means, the bad guy server becomes both the target site and the target name server.

How to Fix
The key point here is the Query ID. If the bad guy can not guess the Query ID, all the method collapses. But the problem is the number of Query IDs that DNS servers use. Old style DNS servers uses 16 bit Query IDs, which means 64k chance to find the ID number. So randomization of the Query ID is a solution. But it’s still feasible to find the ID by trying.

Increasing the Query ID bits may be a solution to this problem. But all the Internet infrastructure lies on the 16 bit DNS Query ID. So it’s impossible to change the Query ID structure.

The most effective way to solve this problem is randomizing both the Query ID and the ports. The client talks to a nameserver on port 53/tcp. And the nameservers talks to each other on random UDP ports with random Query IDs and finds the answer. And than, the nameserver answers back to the client on port 53/tcp.

By this way, finding the true Query ID and the port combination is a fat chance.

Conclusion
Today all the major DNS servers support the method above. The most common DNS servers, BIND and MS DNS server have already patched their software against this vulnerability.
The major Unix/Linux distributions such as RedHat, Gentoo and SuSE, have some security tools that scans the entire system against the vulnerabilities. Glsa-check tool of Gentoo Linux is one of them. It scans the system and updates the packets which are marked as insecure by the Gentoo Development Team. So being updated as fast as possible is the key point of being secure.

References
1.http://en.wikipedia.org/wiki/DNS_cache_poisoning
2.http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
3.http://bugs.gentoo.org/show_bug.cgi?id=231201
4.http://security.freebsd.org/advisories/FreeBSD-SA-08:06.bind.asc
5.http://www.softpanorama.org/DNS/dns_ports.shtml
6.http://www.doxpara.com/DMK_BO2K8.ppt

Az önce internetin hızını test etmek için aşağıdaki siteye girdim. Sonuç şaşırtıcı. Bizim “Interjet”cilerin bunu bi görmesi lazım. Mazhar abiye haber verin.
Söylediklerine göre bu hız yüksek bile değilmiş. Kim bilir daha neler vardır. Görmek istemiyorum. Torrent indirirken download hızım yavaş olduğu için değil, seeder’ların upload hızı yavaş olduğu için tıkanıyorum. Ancak 500kb ile indirebildim. Hızın bu kadar yavaş olması sinir bozucu

Sonradan gelen edit : Az önce yurttaki bağlantımı test ettim. Daha iyi bi sonuç elde ettim.