DNS cache poisoning: still works and still makes lots of damage

Published: 2011-06-27
Last Updated: 2011-06-27 19:19:08 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
5 comment(s)

I was teaching this week at University. It was a pretty normal class until I heard the following from one of my students:

What happened to google?

A couple of seconds after, many people started to make the same complaint and one minute after nobody had access to google. I typed the google URL from my computer and got the following screen:

Strange google appearance

First thing I though was that google suffered an attack. Looking further, I queried for the current google IP and found the following:

Changed google ip

When I looked for the owner of that IP address, ARIN says it is not precisely google. I performed a nslookup from another domain and got the correct ip address for google:

Correct IP address for google

At this time I found out we were victim of a DNS cache poisoning attack.Since the network admin was not at his office because class was in the night, there was nothing I could do but wait for the DNS cache to expire.

How this attack works and How we can protect ourselves

The DNS process works as follows to resolve ip address from a fully qualified domain name (FQDN):

  • Client sends a query to the internal DNS looking for an ip address for a machine name.
  • Internal DNS server performs recursion and if it's not present in the cache looks for the IP address on the internet from the authoritative nameserver of the domain.
  • The authoritative nameserver answers the IP address requested.
  • The Internal DNS server answers the IP address to the client.

The attack works as follows:

  • Attacker queries the target DNS server for a FQDN not present in the cache.
  • Target DNS server performs recursion and looks for the IP address on the internet from the authoritative nameserver of the domain.
  • Attacker floods the target DNS server with fake responses for the query.
  • Target DNS server updates the cache and begins serving the fake ip address every time the FQDN is requested.

How do we protect ourselves from the attack?

  • Use the last version of your DNS server (I really like BIND) as it randomize the source port of your queries.
  • Do not allow recursion from outside of your network. Allow it only from your corporate network computers.
  • Use DNSSEC. The root servers support it since July 15 2010 and the protocol allows to authenticate valid records from domains zones.

Any other protection measure you want to share with us? Please use our contact form.

Manuel Humberto Santander Peláez | http://manuel.santander.name | http://twitter.com/manuelsantander

5 comment(s)


For those of you using a Windows DNS server, the source port randomization is built-in to Windows 2008 R2's DNS server and other versions that have 'Security Update MS08-037' applied.
Test My DNS
> https://www.dns-oarc.net/oarc/services/dnsentropy
"First thing I though was that google suffered an attack"

How often did this happen? "If you hear hoofbeats–don’t think of zebras" ...
Allow me to focus on two points of how to protect :
1) "do not allow recursion from outside ..."
I agree, don't.
But if the logs of the cached poisoned server were analysed, probably one would find that the attack was launched by an internal device !!!
Cache poisoning, eg Dan Kaminsky style, can only be successful (in a reasonable period of time) if there is sufficient bandwidth between attacker and victim.
This being said : you cannot forbid your internal caching name server to service your internal clients ...
If you are not using DNSSEC, you're game for attackers.
But what precisely *is* using DNSSEC ?
a) do offer signatures that can be validated
This is more or less implied by the statement that "root servers support it".
It is also the essential contribution in "DNSSEC tips", posted as follow up on this diary.
b) (MOSTLY OVERLOOKED) do validate signatures
It is useless to offer signatures that can be validated, if the receiver of the signature ignores them.

eu. also is ready for DNSSEC,
with complete chain-of-trust since early september 2011.

Marc Lampo
Security Officer
Sorry, that should have been :

eu. is ready for DNSSEC since september 2010 (not 2011 !)

Marc Lampo

Diary Archives