Manage Learn to apply best practices and optimize your operations.

Are open recursive DNS servers inherently insecure?

Recursion was meant to make the Internet run better, but expert Michael Cobb explains why the willingness of malicious users to abuse open recursive DNS servers has made it part of numerous ongoing threats.

Are open recursive DNS servers inherently insecure? How are their vulnerabilities any more or less dangerous than closed recursive servers?
It might be a mistake to characterize open recursive DNS name servers as inherently insecure because the actual point of recursion was to make the Internet run better. By spreading the enormous task of looking up tens of millions of domain names across a massively distributed hierarchical architecture, recursion removes the need for one or more impossibly huge directories. Recursion results in faster lookups because many queries can be answered from local or relatively local DNS tables.

Sadly, the willingness of malicious users to abuse this service has made it part of numerous ongoing threats. Several denial-of-service attacks use DNS recursion to amplify their effect, sometimes in conjunction with the abuse of other well-intentioned Internet features like RFC 2671 (Extension Mechanisms for DNS - EDNS). These extension functions require name servers to return much larger responses to queries, thus enabling attacks with much higher UDP response amplifications.

However, just like open relays, which were a good idea for email until they became abused by spammers, open recursive DNS servers have also been frowned upon. US-CERT now recommends that "where possible, organizations should secure their DNS servers to ensure that they do not allow recursion or, at a minimum, restrict access to only trusted domains and disable the ability to send additional delegation information." The US-CERT document, cited above, provides detailed instructions for secure DNS configuration.

In other words, turn off or close the recursion function, which is on by default in many versions of DNS serverware. An open recursive DNS server puts an organization -- and the Internet at large -- at greater risk than a non-recursive or closed recursive DNS server would. Major hosting companies like GoDaddy.com Inc. feel the same way. Its official site warns operators of dedicated servers, saying that: "We do not allow recursive DNS to run on dedicated or virtual dedicated servers unless it runs locally and for a specific IP range."

There are some dissenting voices, notably David Ulevitch, CEO of OpenDNS, which offers a free open recursive DNS service. He was critical of the conclusions drawn by researchers from Georgia Tech and Google that there were around 17 million open-recursive DNS servers on the Internet, of which 68,000 or roughly 0.4% were answering DNS queries with false information, redirecting people to malicious sites. While not arguing with the numbers, Ulevitch pointed out that the researchers were only able to test open recursive DNS name servers, and there is no reason to think closed servers were not also acting maliciously.

The bottom line is that enterprise DNS security needs to be made a greater priority, for the sake of the organization and its ability to withstand future denial-of-service attacks, as well as for the sake of the Net as a whole. This will be no small task. It is estimated that there are more than 11 million DNS servers on the Internet today, at least half of which allow recursive queries and more than 30% allow zone transfers or synchronization among domain zones. Not all of the world's DNS servers are insecure, but even if 90% were secure, that would leave over a million to worry about.

More information:

  • Learn more about how to protect DNS servers.
  • Security luminary Roger Thompson explains how hijacked DNS servers could allow an Internet assault.
  • This was last published in May 2008

    Dig Deeper on Data security strategies and governance

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.