Saragiotis Blog An every day adventure


Protecting the Domain Name System

This article was published in ENISA's EQR.

What is DNS?

In our modern way of living we are using digital identifiers to perform a number of tasks. We use digital identifiers to visit a web page, i.e. we enter the unified resource locator (URL) in the address bar of a web browser, to send an email, to login at page or program, to dial a number and in plenty more circumstances. In most of the cases, these digital identifiers are used to lookup up a secondary or another format of information. When we are visiting a web page the URL is used to lookup among other things the IP address of the internet server that hosts the page. The IP address is used by our client to connect to the server.

The Domain Name System (DNS) is the protocol and the worldwide system that associates a category of digital identifiers, called domains, to a variety of data. DNS is a distributed, hierarchical system. There are a lot of islands of information, each authoritative for a number of domains. These islands are called zones. The authority for each subdomain is delegated by referrals to other islands of information, i.e. other servers, possible remote and under another authority’s control. It is clear that no authority has or can acquire full knowledge of the available data. It should also be noted that any authority could host any zone it wishes, but this will only be accessible if a parent zone delegates authority to it.

Today the DNS is used widely in looking up IP addresses from domains and the reverse, application servers, i.e. mail servers, and hosting tables of hosts, i.e. hosts that are known to generate SPAM and we wish not to receive mail from. Other, emerging uses of DNS include the association of phone numbers with IP addresses to use it with VoIP and RFID’s code lookup to sources of information. Plenty other DNS uses are foreseen in sensor and peer to peer networks. The frequency of use of DNS is also very high. Every email sent creates 3 or more DNS lookups, while every web page needs a few lookups as well.

DNS is a widely deployed system. It is estimated that there are more than 2 million DNS servers on the internet. But, DNS is also used in the private intranets and local LANs. The estimated number of DNS servers in such private networks is more than 10 million.

How does DNS work?

There are several entities involved in DNS and a lot of interactions occur during the lookup of the data associated to a domain, as shown in Figure 2. The stub client () that wants to get the associated data of a domain sends the request to a recursive resolver (). The recursive resolver, which is usually provided by the user’s ISP, will traverse the DNS authoritative servers (), starting from the root, to retrieve the data and return them to the stub client. Each recursive resolver is configured with an entry point to the DNS which is the root zone.

What are the known threats?

There are three different types of communications in DNS. The obvious ones are the communication between the stub client and the recursive resolver and the communication between the recursive resolver and the authoritative servers. The third type of communications is the one used between authoritative servers to synchronise the zones, after zone changes. Most of these communications are performed by exchanging User Datagram Protocol (UDP) packets that are being matched and essentially protected by the UDP source port and an application defined query ID.

The identified threats to DNS communications and components are being listed in RFC 3833 and they are:

  • Packet Interception - man-in-the-middle attacks
  • ID Guessing and Query Prediction
  • Name Chaining - Cache Poisoning
  • Betrayal By Trusted Server
  • Denial of Service
  • Wildcards insertion

The most dangerous attacks are those by which the attacker gains control of a zone, meaning that he is presented as authoritative server for that zone to a part of the internet and can modify the data returned to the user. In most of the cases this is used to impersonate a web site. There are plenty of web pages explaining how this attack can be performed, but in principle it affects a recursive resolver at a time by guessing the source port of its query to an authoritative server and the corresponding query ID and installing a false delegation for that zone, as shown in Figure 3. This kind of attacks, which are called cache poisoning attacks, where observed first in 1989 and variations of it come to light continuously.

Ellaborating on the cache poisoning attacks

A variation of this attack, the fast poisoning attack, by which an attacker can gain control of a zone in a matter of seconds, was discovered in July 2008. The industry reacted fast and in coordination and a patch released that randomised the Query ID and UDP source port for each request, decreasing the possibility for success of each packet in this attack from 1 in 2^16 (roughly 66 thousand) to 1 in 2^32 (more than 4 billion). This patch has been installed in the majority of recursive resolvers and solved the problem temporarily. It is proven that with gigabit connectivity someone can still succeed in this cache poisoning attack in 10 hours. This limits the problem at this point of time in enterprise networks, which of course can be accessed by attackers through some other security flaw or an infected laptop or a disgruntled employee. Furthermore, it is only a matter of time for the increase of speed in internet connectivity to allow these attacks to be performed through the public internet. So, another permanent solution to the problem is needed.

If a cache poisoning attack succeeds, then there are several types of attacks that the users of that recursive resolver are prone too. The simplest attack is redirecting the traffic to another malicious server. This can influence:

  • web traffic, by displaying other content than the intended, performing phishing attacks or installing malicious software;
  • mail traffic,  by eavesdropping on confidential mail without leaving any traces;
  • voice conversations, by eavesdropping and obtaining credentials to services, and plenty more.

Even Secure Sockets Layer (SSL) protected traffic is prone to attacks if further to traffic redirection a SSL weakening attack is performed that could accomplish cipher specification weakening.

How can we be protected?

Against this background it is clear that the DNS is still far from being secure. The existing flaws can affect the public internet users as well as the enterprise users. The ISP’s recursive resolvers as well as those used by enterprises have to be secured. For the communications that occur between the DNS entities, widely deployed and proven solutions exist for those between stub clients and recursive resolvers and between authoritative servers. A solution has to be established for verifying the authenticity and protect the integrity of the DNS data in the communications between the recursive resolvers and the authoritative servers. This solution will definitely involve digital signatures and a form of Public Key Infrastructure (PKI). One such solution is the use of DNSSEC. DNSSEC is a security extension to the DNS that, if deployed, can solve the cache poisoning problem.

Before its widespread deployment DNSSEC has to overcome several obstacles. First of all is the issue of trust of authority. It has to be decided if the entire internet trusts a single authority to sign the root zone of the DNS or another distributed approach has to be followed. Whatever solution is chosen, the supporting security architecture has to be defined. Another obstacle is the scarcity of automation tools for handling DNSSEC zone operations. In DNS, an error in the syntax of a zone can have a small or no impact at all in the reachability of the zone while in a DNSSEC enabled zone, an error can mark the zone bogus and unreachable. Moreover, tools have to become available for the end users. Enabling DNSSEC on stub clients and notifying end users about the authenticity of the data will raise their awareness on the dangers and help them make educated decisions on trusting a content provider.