Frequently Asked Questions on Cache Poisoning and Cross Pollination

Last revised 6 August 2008

What is the issue?

A method of inserting false data into a name server has been discovered by a security researcher. This method affects recursive name servers, which are usually provided by ISPs and network operators to provide DNS service to their end users. As these types of name servers remember previous lookups in a cache, they are often called caching name servers, caching resolvers or similar.

The attack relies on the fact that an attacker can send fake DNS answers in response to a query and trick it into thinking the wrong data is correct for a given domain. The method is a specific type of cache poisoning attack. It is called cache poisoning because the server remembers the wrong answer in its cache, and then provides that wrong answer in future lookups.

While similar vulnerabilities have been discovered in the past, and have been patched in software, this attack is particularly concerning as it is far more effective. This has significantly raised the level of concern.

The cache poisoning is made much more viable, in part, by the fact that many name servers use the same source port number for every one of their DNS queries. If the source port is easy to guess, an attacker can much more reliably predict how to attack the server. One mitigation technique is to therefore use a randomised source port. This helps reduce the risk of attack, but does not solve the problem entirely.

Why is this issue critical only for some domain operators?

Domains are operated on a name server configuration known as an authoritative name server. Authoritative name servers are not vulnerable to this type of attack. However, a number of domain operators use servers that are configured both as an “authoritative name server” and as a “recursive name server”. The vulnerability in the recursive portion of the name server can infect the data of the authoritative name server, therefore making the authoritative portion vulnerable.

How can I test if my domain is affected?

To test whether a domain has authoritative name servers that are vulnerable to cross-pollination from a recursive name server, we have developed a tool to quickly scan for the issue. It is available at:

http://recursive.iana.org/

How should domain operators solve this problem?

Authoritative name servers should never be configured to provide recursive name service. Any recursive name service on these authoritative name servers should be turned off. If this is not possible for operational reasons (i.e. the server is used for other purposes that require a recursive name server), the domain operator should discontinue using that server as an authority.

I have seen there are patches for my name server software for this vulnerability. What does it do?

The patches for this vulnerability randomise the source port of DNS queries, making it harder to execute a cache poisoning attack against the server. However, it does not fully fix the problem. The only complete solution to the problem is deployment of DNSSEC.

I have patched my authoritative name server against the latest vulnerability, yet I am told the server is still vulnerable. Why is this?

We are not only testing whether your specific authoritative name server has been patched to enable source port randomisation. We are testing whether the name server is providing recursive name service.

The combination of non-randomised source ports, and open recursive name service, is a very serious security problem. However, randomising source ports only makes the type of attack more difficult, it does not solve the problem. It is still possible to conduct a cache poisoning attack on an authoritative name server as long as it is providing recursive name service.

How do I learn more about this vulnerability?

The US Computer Emergency Response Team (CERT) issued a vulnerability notice which is available from the following address:

http://www.kb.cert.org/vuls/id/800113

How do I turn off recursive name service in my software?

Each software package is different, and you should review the documentation. In the most popular server software, BIND, you can add the following to your configuration file in versions 8 and above:

options { recursion no; };

I need recursive name service on my server, how do I patch the server for source port randomisation?

Each software package is different, and you should speak with the software vendor. A list of vendors is provided in the CERT advisory above.

How do I verify a server has been patched for source port randomisation?

The DNS Operations, Analysis and Research Center (OARC) have provided some tools to assist this. If you send a TXT query for the domain porttest.dns-oarc.net through the recursive name server, it will provide a rating on how random that server's source port is. You should look for an answer of GREAT to indicate that your server does not need to be patched (or has already been patched.)

To execute this using the dig command line tool, perform a query like

dig +short porttest.dns-oarc.net txt @1.2.3.4

where 1.2.3.4 is replaced with the IP address of the name server being tested.

For a more user-friendly version for end users to test their ISP’s recursive name servers, they can visit the web page at

http://entropy.dns-oarc.net/test/

I have turned off recursive name service, and now I have problems looking up domain names from within my network. What is the problem?

You may be relying on the recursive functionality you just turned off to provide DNS service to you or your customers. In this case, two possible solutions are: turn off the recursive service, and configure you and your customers to use a different recursive service; or configure another name server to be authoritative and change the delegation for the domain to point to the new server.

Why is it urgent to fix this problem?

The method of attack is much more dangerous than typical vulnerabilities. While the method has been known privately for several months by software vendors who have been working to fix the problem, the public announcement of the vulnerability was not expected to be made until August 6 by its discoverer.

However, the fault was independently discovered and published by others in mid-July, and the knowledge on how to conduct the attack is now in the public domain. Therefore any affected name server is exposed at this time.

One of my authoritive name servers is vulnerable, and I can not turn off recursion. What should I do?

You should stop using this as an authority, and update the delegation of your domain appropriately. You may wish to consider replacing it with a new server depending on your diversity requirements.

What actions has ICANN taken to address this problem in top-level domains?

The name servers that serve the top-level domains ICANN operates directly (for example, .INT) are verified to not be affected by this issue. We are scanning all top-level domains on a regular basis and informing our contacts at these registries of recursive name servers that we discover. We are providing advice to them on the issue, and assistance to remedy the problem.

Is the poisoning of authoritative name servers a problem limited to top-level domain operators?

No, it does not just affect top-level domain operators. You can similarly poison other domains at a lower level in the DNS using the same method. However, the top-level domains have the greatest exposure as they encompass large parts of the DNS tree. In addition, ICANN's direct role is to handle delegation of authoritative name servers for top-level domains, so this is our primary focus.

It is best practice for any domain's authoritative name servers to be separated from any recursive name server function.

As a top-level domain operator, is there anything I need to do with my customers?

A number of top-level domain operators have found the issue sufficiently important that they have advised all their customers of the vulnerability. A sample of announcements made by various parties are:

You should consider making a similar announcement to your community, as the vulnerability is serious for all recursive name server operators.

How is ICANN discovering which name servers are recursive?

It is simple to diagnose what name server is providing recursive name service by sending a query to the name server for a domain it is not authoritative for with the Recursion Desired (RD) flag set, and analyse the response. ICANN does this. A server with recursion disabled should not successfully answer such queries.

As anyone can remotely test the vulnerability of servers in this way, it is important to quickly act to secure domains against this issue.

I am a top-level domain operator and I am not sure how to act, or what servers I need to change?

We will happily provide guidance to any top-level domain operator on this issue. Let us know if we can be of assistance at iana@iana.org.