Why the DNS is broken, in plain language

by Kim Davies on November 12, 2008

At ICANN’s meeting in Egypt last week, I had the opportunity to try and explain to various non-technical audiences why the Domain Name System (DNS) is vulnerable to attack, and why that is important, without needing a computer science degree to understand it. Here is the summary.

How does the DNS work?

The DNS can be considered to be a question-and-answer system. When you type in an address like “icann.org” into a web browser, your computer needs to turn that into a numeric address of the computer hosting that website. To do this, it sends a question over the Internet to a DNS server “Where is icann.org?” The DNS server sends back an answer, “The address is”.

Typical DNS transaction

How do you attack the DNS?

Let’s say I want to execute an attack on this question and answer exchange, in order to convince the computer to go to the wrong address. When the computer I wish to attack asks a question, my goal is to provide a fake response back to that computer quicker than the real server comes back with the response. By getting my forged answer back faster, the computer will proceed using my answer, rather than the official one.

Execution of a spoofing attack

So, if I send back a fake address to a computer, I can get that computer to go to a different address than the one intended. For example, on that address I might have set up a fake website intended to take someone’s sensitive data, like a replica of a bank’s website.

If I manage to attack one computer why is that a big deal?

A successful attack on one computer in isolation can be problematic for the user of that computer, but it is not that interesting to an attacker to succeed against only one person. Unlucky for us, just one successful attack can very easily have wider consequences. Let me explain.

The DNS is made much more efficient by the use of “caching” name servers. These name servers sit at ISPs, or on corporate networks, and perform DNS lookups on behalf of customers. It then stores the answers it receives in a cache, so for future lookups for the same domain it does not repeat the lookup – it just remembers the previous answer.

This means that if you execute an attack and it gets stored in a cache, it can actually impact many people over and over again, because that answer will be redistributed to everyone that uses that same caching server.

This is why this type of attack is usually called a “cache poisoning” attack, because by poisoning the cache with the wrong data, it creates a much more serious problem.

So I just send back an answer quicker, and that’s it?

It is not quite as simple as just sending a quicker answer back to a computer, you also have to guess certain attributes correctly on the answer that match the question. For example, your answer needs to go back to the same computer the question originated. You also need match the question that was being asked in your answer.

Attributes that need to match

It is simple, however, to guess most of the attributes. As you know which computer you are trying to attack, you don’t need to guess that. As you know which domain you are trying to impersonate, that is also a given. Conventionally, there are only two variables. One variable is you need to guess which server the answer is coming from. The average domain on the Internet has around two or three name servers, only one of which will respond to any given query. Therefore you have about a one in three chance of guessing that correctly. The second variable is a unique reference number (formally, a “transaction ID”), that has about 65000 possibilities. Therefore you have about a 1 in 65000 chance of guessing that correctly.

Earlier this year, security researcher Dan Kaminsky found that it is devastatingly simple to exhaust all those possibilities in a very short amount of time by performing an attack in a certain way. How short? Well, British DNS researcher John Dickinson did some tests and found that on average he could successfully attack a server in just 1.3 seconds.

How do you fix the problem?

The sad news is there is no real solution as far as the regular DNS is concerned. It is not like a security hole in a piece of software that can be repaired with an update. This is an architectural flaw in the DNS protocol itself. There are patches for DNS software, but these only attempt to make executing an attack more difficult, they don’t solve the problem.

Some of the short term approaches to make attacks more difficult are as follows:

  1. Randomise the “source port”. One of the attributes in the packet that an attacker needs to guess is called the port number. For architectural reasons, this needs to be port 53 on the way to the server — this is how the server realises it is a DNS query as opposed to a different type of query. However, the port number that a response is sent back to doesn’t need to be port 53. By randomising this, you make it harder for an attacker to guess. Much of the software updates to this problem in mid-2008 related to adding source port randomisation.
  2. Block open recursive name service. If you provide access to a caching name server to the whole Internet, then it is very easy for the whole Internet to execute an attack against your server. If you limit access to just those who need it (i.e. your local network), then you reduce that risk.
  3. Experimentation with capitalisation of domains. Domains in practice are not case sensitive – if you type ICANN.ORG or icann.org, it means the same thing. However, inside the DNS protocol itself, the encoded transmission between computers actually is case sensitive. This property can be used to add some more randomness to transmissions. If my computer sends off a question asking about “iCaNn.OrG” and gets back an answer for “icann.org”, it can throw it away as untrustworthy. This approach is still experimental and being discussed.

The net effect of these attempts to reduce the risk of attacks primarily involve adding more randomness for the attacker to guess. These approaches approximately double the number of “bits” of randomness. To be clear though, they only make an attack harder, but an attack is still viable. Furthermore, we know that both network speeds and computer speeds get faster and faster each year. These are the two things that slow down an attacker. Therefore, we know that successful attacks will just be easier and easier into the future.

If there is no short term solution, what is the long term solution?

While the DNS itself can’t be properly fixed for the security problem, a new protocol that overlays the DNS called DNSSEC does. DNSSEC uses a system of certification to show that a DNS answer has not been modified. If someone tries to execute an attack, the certificate won’t validate, and the incorrect answer will be thrown away.

DNSSEC is difficult to deploy. It requires upgrades in DNS servers, it changes the way domain name holders manage their name servers, and it adds extra complexity. However, with the knowledge that DNS attacks are so simple to execute without it, there is growing consensus that the pain it will take to deploy is less than the pain of a DNS that you can no longer trust.

More information

You can view the presentation slides used in Cairo.

{ 23 comments… read them below or add one }

McTim 11.12.08 at 9:03 pm

nice one, thanks for this!

Archana Shekar 11.13.08 at 1:29 am

The article is very informative.More focus is shown on the situation and how to handle the same.Thank you for such an informative and beautiful article.

Archana Shekar
keeping children safe online and offline,www.8falcons.com

arsa a1-computer 11.14.08 at 1:22 am

very good, thanks!

sohbet 11.16.08 at 10:55 am

very good, thanks!

sarmad 11.17.08 at 11:50 pm

This article is Great !
made me understand why sometimes it says ( searching for http://www.,,,,,)
Thank you

mevlüt şekeri 11.22.08 at 6:11 am

mevlüt şekeri

Paul Wilson 11.24.08 at 5:55 pm


Thanks for a nice clear article. I do have a couple of comments.

The DNS is not “broken” any more than SMTP email, or the Internet itself, is “broken” – all are working just as they were designed to, which happens to be with fairly minimal builtin security functionality. But as demand has grown on the Internet, it has been to put to use in high-security applications, by using additional techniques which have provide the security required for any given application.

I think it’s important to note that the security risks have been widely known from time of development of DNS and other protocols, and that solutions have become widely available as they have been developed, for instance SSL security between web clients and servers, and private-key encryption in email.

So, while the example of the web user being directed to the wrong website is certainly a real one, it is one that has been understood for many years and for which security solutions are available, namely the website certificates which allow the famous browser “lock” icons to be displayed. I think your article really needs mention this point specifically, to put the whole discussion into the real operational context of the Internet. Otherwise I’m afraid it is really quite alarmist.

I’m not saying that current solutions are the best possible, but clearly they have been adequate to allow, for instance, the development of online banking to the multi-million dollar industry that we have today. Like many aspects the Internet, there are problems at various levels which are being solved at the appropriate levels. One of the key solutions in case of DNS is DNSSEC, as you mention, and it is certainly going to be useful in providing an overall robustness in the DNS which would remove the need for some of the ad hoc and application-dependent add-ons that we use today.

Paul Wilson,
Director-General, APNIC

coupons 11.24.08 at 10:10 pm

this plain language makes me understand obliviously. Thanks.

Kim Davies 11.25.08 at 1:03 pm

Hi Paul,

Thanks for your comments.

I agree the general nature of the DNS’s security weakness, as with many other long-standing protocols, is well known. However, there are some things that I think make the issues more serious today, and more serious than exploits with SMTP, HTTP etc.

Firstly, DNS is one of the few core Internet protocols that uses connection-less transport, making spoofing attacks much more straightforward. Nailing up a connection using TCP to execute a spoofing attack on an SMTP or HTTP TCP connection is difficult, doing it by convincing the DNS to go somewhere else with a UDP packet is much easier.

Secondly, the type of attack Kaminsky demonstrated appears a lot more viable than a theoretical DNS attack conceived in the years prior. I think everyone could see the kinds of demonstration attacks where someone sits on a local WiFi point and puts a bad actor into play, tricking computers on that local network to go to spoofed locations. But I am not aware of convincing demonstrations of such speedy cache poisoning attacks as those that have been demonstrated this year. So was cache poisoning known? Of course. Was it known you could do it so effectively? Probably not. In so far as attacks are demonstrably more viable than people thought possible before, I think there is cause for alarm.

The real problem with security, either at the HTTP layer, or at the DNS layer—as we will soon discover—is not the technology but the human interaction with it. It is true that HTTP SSL security, for example, can be a good guard that could theoretically guard against DNS attacks at a higher layer in the stack. But I’d wager that the majority of people that get SSL warnings about invalid certificates just click the button that says “Ignore” and carry on. It will be interesting to see how DNSSEC is deployed in applications, and whether it will provide the same escape path that allows insecure transactions to carry on.

It is understandable given the history of the Internet that strong security measures weren’t baked in when these protocols were first devised, and I don’t think anyone is being critical of that history. But past performance isn’t a guarantee of future success, either.


Bernd Plagge 12.02.08 at 8:22 am

DNSSEC is probably not the way we want to go. While it solves the security problem it is difficult to implement (as you rightly mention) but also it depends on certificates for the root servers.
These certicates are issued and hence controlled by some organization. Such organization then has the power to add or drop domains deemed to be ‘bad’ for one or another reason. It is very unlikely that the whole world will give the mandate for this to anly organization belonging to any local government.
It may be best to look for alternatives.

Kim Davies 12.02.08 at 1:24 pm


What you describe is no different from the situation you have today without DNSSEC. In fact, you touch on one of the great misconceptions of DNSSEC.

ICANN, through its IANA root management function, already has the power to add or drop domains; and DNSSEC would not give it any more or less power to do so. If you disagree that it should manage the DNS root’s contents, and should be managed by another entity, that is a different argument and not related to DNSSEC.

Remember, DNSSEC protects the contents in passage, it doesn’t imbue special powers that don’t already exist in today’s trust relationships.


crg 12.06.08 at 6:17 pm

What to do if your domain DNS have been supplanted? How do you work it out and get back to normal operation?

Şömine 12.17.08 at 7:03 pm

Thanks. This plain language makes me understand obliviously.

Dereon Stephenson 03.07.09 at 5:21 am

Interesting, thanks for sharing this great post :-)


DNS is a the application of services in Internet translating a domain name to IP address.
For example, www for usage in Internet, then is typing name of domain, for example: yahoo.com
so would in mapping to a IP. Ex : So DNS can be analogy at usage of telephone book,
where man who we recognize based on name of contact it we must dial in
telephone set. Same precisely, host computer sends queries in the form of name of computer and domain name server to DNS,
then by DNS is mapped to IP address.
if you want to know more about DNS just submit to
http://mr-amateur.co.cc part of the tips-trick…
thanks before…

Dostluk 08.22.09 at 12:09 am

hoş çalışma, tahnks :P

commonsense 09.01.09 at 8:53 pm

The internet. It runs on the OS designed by the phone company (UNIX, AT&T aka Bell), using the lines built for the telephone (Serial, ADSL, etc.) and later lines built for TV which relied on the structures built of the telephone lines (cable), using a numbers system (IP), just like the telephone. So what’s different? Letting someone else look up the numbers for you. That’s great for the folks back in the 80’s. But I don’t trust people to look up the numbers for me in the 00’s. Why should I? I can look up any number in 3 calls or less: 1. root 2. tld 3. node. After I save some of the numbers, I need not make more than one call. I do not need to be updated every 5 minutes. Nor do I need someone else’s “domain names”. I’ve got aliases. If the hosts file is so terrible, why is it still there, after 30 years? My guess is because IT WORKS. Which is more than I can say for DNS some of the time.

Forum 09.04.09 at 3:17 pm

teşekkürler yazı için thank thank

Douglas Otis 09.09.09 at 8:04 pm

By allowing providers and authoritative servers to utilize SCTP as a default transport, instead of UDP, this would eliminate any possibility of blind spoofing attacks, such as those Dan Kaminsky demonstrated. SCTP would also prevent DNS or DNSSEC being used as a 60X amplifier for reflected attack. SCTP also supports an Auto-Close to automate persistent connections to reduce latency, and allows out-of-order processing and non-reliable delivery so servers do not need to retain in-flight data that is pending acknowledgment.

SCTP represents the future for the Internet. It offers improved error detection for Jumbo frames. Detects bus related bit-specific errors that TCP and UDP miss in 2% of the cases. SCTP is now used in critical infrastructure. There is 10 and 1 Gb/NIC providing SCTP off-loading. Processors even support its newer error checking as a single instruction. It is time for DNS to adopted SCTP as the preferred transport. The DNS message or the DNS protocol will otherwise remain unchanged, without there being any reliance upon port randomization.

Halı yıkama 05.03.10 at 1:46 pm

halı yıkama koltuk yıkama halı tamiri

anonymus 09.21.10 at 2:42 am

the link to John Dickensons tests, where he did that average of 1.3 seconds doesn’t work anymore. I’m not able to find a report about those tests. Do you have any closer information about the test conditions? The graph in the Cairo presentation isn’t that helpful.
Thanks, M.

Anonymous 02.03.11 at 9:05 am

If the Federal Governement asked ICANN to kill DNS- would ICANN do that?

If ICANN killed DNS, would the internet becomes useless for the majority of users?

Thank you for your help.

Robert 07.08.14 at 10:10 am


Simply switching to already supported TCP instead of UDP wouldn\’t help a little in this specific case?

Kind regards, Rob

Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image