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 192.0.2.0”.

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.

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.

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.

So where is IPv6 deployment most evident? It?s a very difficult thing to measure. It is difficult to measure the amount of IPv6 traffic as so much of it is tunneled inside of IPv4. And anyway, tunneled traffic is probably from end users rather than ISPs, but we need ISPs to deploy IPv6 to allow the Internet to grow. So how can we see where ISPs are deploying IPv6 in their networks?

One possible measure of IPv6 deployment in ISPs is the number of IPv6 address blocks (prefixes) seen in the routing table in comparison with the the number of autonomous systems (ASs – roughly equivalent to ISPs) in a region. Geoff Huston has a regional breakdown of advertised ASs on his web site and the SixXS project has a regional breakdown of the IPv6 address blocks visible per region on its web site.

AfriNIC, the Regional Internet Registry for Africa and parts of the Indian Ocean, has a higher proportion of networks in its region announcing IPv6 addresses than the others. Africa also has a smaller deployed base but IPv6’s size is designed to support exactly the kind of network growth that highly populated areas, like Africa and Asia will see as their deployed base grows in the next few years.

Proportion of ASs in RIPE NCC service region announcing IPv6 prefixes

Proportion of ASs in APNIC service region announcing IPv6 prefixes

Proportion of ASs in ARIN service region announcing IPv6 prefixes

Proportion of ASs in LACNIC service region announcing IPv6 prefixes

Proportion of ASs in AfriNIC service region announcing IPv6 prefixes

My landlord isn’t the only ISP providing an Internet connection using private IPv4 addresses. As mentioned at the last AfriNIC meeting, there are many millions of connections sitting behind hierarchies of IPv4 NATs.

But this week I was inspired to look at deploying IPv6 alongside my NAT. This has been done very successfully in the IPv6 hours at NANOG 42, APRICOT 2008 and this week’s IETF 71. I wanted to see if I could get IPv6 connectivity to my laptop despite not having a unique address to terminate a tunnel. I did and it took me less than five minutes.

If your ISP doesn’t provide a native IPv6 service you can get an IPv6 tunnel from an ISP that provides IPv6 tunnels. An IPv6 tunnel is just a way of putting IPv6 packets inside IPv4 packets for the IPv4 portion of the journey over the Internet. I can’t use the popular 6to4 tunnelling method because they can only run between two hosts with unique addresses and I don’t have a unique address on my home network.

Fortunately, Teredo (also known as Miredo) lets me tunnel IPv6 packets past my NAT, giving me what the IETF have called “IPv6 access of last resort”. Windows Vista computers have Teredo support built in but my OS X machine does not. But just 30 seconds with a search engine showed me that “deep darc” has published an implementation of Miredo for OS X. In less than a minute it was downloaded and installed.

There was no need to change any of the settings because the defaults worked fine. On visiting the IANA web site I saw that my browser was using IPv6 (see image at the top).

Teredo/Miredo will give the users of NATed connections access to unique IPv6 addresses, making it easier for them to use any services blocked by NATs in their ISP’s network.

With help from the Regional Internet Registries, three /8s were returned in 2007 and last month we recovered one more. We now have 43 unallocated /8s. Here’s a table showing the details of the returned blocks.

/8	Year	Help from
46 – BBN	2007	BBN and ARIN
49 – US DoD	2007	ARIN
50 – US DoD	2007	ARIN
14 – Public Data Net	2008	Network Operators

Despite this windfall we are unlikely to see any more whole /8s returned to the IANA free pool. Our investigations indicate that the other legacy “Class A” assignments are all at least partially used. Recovering the space in those blocks would require large companies to engage in expensive renumbering exercises.

But more importantly, it would not buy us very much time. We allocated more than one /8 per month in 2007, so to gain even one year would require a huge amount of renumbering by the users of more than a dozen legacy assignments.

Geoff Huston’s mathematical projection suggests the IANA free pool will be empty before the second half of 2011 and the RIRs’ pools will run out barely a year later. Of course, whatever mathematical models he uses, he cannot account for the very human possibility of a run on the bank.

Address recovery cannot extend the life of the IANA free pool by more than a few months.

It is possible that unused portions of the legacy “Class A” and “Class B” will be returned to the RIRs free pools. Alternatively, it is possible people with partially used legacy assignments will wait for a variant on the policy proposals in the RIPE and APNIC communities to emerge and then engage in remunerated renumbering and address transfer programs.

Whatever actually happens in the next few years, we can be sure that anyone needing large amounts of address space for a rapidly growing network will have to deploy IPv6. IPv6 deployment in the Internet’s core infrastructure is continuing and network operators at ISPs and enterprises need to plan for a world where their users will need to communicate with systems on both IPv4 and IPv6.