Access to caching DNS servers to be restricted - details
The Domain Name System (DNS) remains a critical part of both the campus network infrastructure and of the Internet itself. As a distributed database, the DNS has information pertaining to every host on the Internet, and it provides the mechanism for such information to be made available to all Internet-connected hosts. Threats to the overall security of the DNS have long been discussed, but thus far, few have materialized as serious problems. Part of the reason for this has been the responsiveness and proactiveness of the operators of DNS servers.
Two current security threats to the DNS loom. Neither is particularly new, but they have received additional attention of late. They are discussed below, and, in order to understand them better, it is first necessary to understand how the DNS works.
As a distributed database, DNS information is spread throughout the world. It's important to understand that there is no single server anywhere in the world that contains all DNS information. Instead, information for each DNS domain is managed separately, by the administrators of that domain. DNS information for berkeley.edu is managed by IST. We manage this information and make it available on special DNS servers that are registered with the various relevant Internet registrars. Such DNS servers are known as authoritative or iterative servers.
A critical task in finding a particular piece of information, such as the IP address of the host www.berkeley.edu, is to find the proper authoritative DNS server. A separate class of DNS server is charged with locating the proper authoritative server and asking it for the requested information. It may have to make several queries to several DNS servers in order to locate the proper authoritative server and get the information. This problem is compounded by the fact that such DNS servers ordinarily don't have any pre-existing information about which servers are authoritative for which domains, and such information changes frequently anyway. This problem is partly solved by pre-configuring a relatively static set of nameservers called the root nameservers. The other part of the solution is that these servers cache all of the answers they get in their memory, so they will be able to answer users' queries more quickly and with less work. These servers are thus called caching or recursive DNS servers. This wikipedia page shows a typical recursive query.
It is possible to have both authoritative and caching functions running on the same DNS server, and this was typical in the early days of the DNS. More recently it has become a best practice to separate these functions, and IST did this a few years ago. More information on our DNS servers can be found here.
IST provides caching DNS servers for the campus to use, and it is also possible for individual users to set up their own caching DNS servers. There is an advantage to using large central caching DNS servers, in that the busier central servers will have large caches built up, and will able to provide information without doing as many time-consuming lookups. However, under certain circumstances, it is beneficial for a host to run a small caching DNS process. It is therefore important that all such DNS servers are secured, and follow best practices.
Two particular threats against which servers must be secured are as follows:
How to fix the problem
This brings us to the problem of how to combat these attack scenarios. First, older DNS server software is more prone to cache poisoning than more recent releases of such software. It is therefore important that all DNS server operators ensure that their software is fully up-to-date. Second, the most effective way of reducing the threat of both types of attacks is to restrict who can query a given caching DNS server. Most DNS server software allows the administrator to restrict queries to a particular range of IP addresses; while this doesn't eliminate the possibility of either problem, it can drastically reduce its scope and deleterious effects.
Actions to be taken
For the caching DNS servers that IST operates, we will be restricting use of these servers only to on-campus hosts beginning July 1, 2006. This will not affect on-campus users, nor will it affect off-campus users who dial into the campus network, use the campus VPN, or have network service provided by campus, either via T1 lines or Comcast fiber. Essentially, all hosts that have campus IP addresses will continue to use the campus caching DNS servers normally. Users whose Internet service is not provided by campus will no longer be able to use campus DNS servers after this date. Each ISP provides caching DNS services for its customers, as well as instructions on how to use those servers. We recognize that changes of this manner are disruptive, but we believe there is no other choice. Other universities and ISPs are taking the same actions (e.g. the University of Oregon). We have prepared a web page with details on the restrictions we will be imposing and how off-campus users can configure their systems to work with the new restrictions:
For caching DNS servers that are operated by individual campus administrators, IST is asking operators to do the following:
Please note that hosts on campus other than the central caching DNS servers have participated in DDoS attacks as described above. If IST or the System and Network Security group (SNS) detects a host that is participating in such an attack, we will have no choice but to block the host's network connection, as it will be creating an operational problem for either the campus or the victim.
May 25, 2006