Last revised 6 August 2008
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.
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.
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:
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.
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.
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.
The US Computer Emergency Response Team (CERT) issued a vulnerability notice which is available from the following address:
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; };
Each software package is different, and you should speak with the software vendor. A list of vendors is provided in the CERT advisory above.
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
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.
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.
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.
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.
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.
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.
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.
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.
