Non-UO Recursive Domain Name Server Access to be Curtailed February 1

Jose Dominguez
Senior Network Engineer, Network Services
jad@network-services.uoregon.edu

Joe St Sauver, Ph.D.
Director, User Services and Network Applications
joe@uoregon.edu

Before explaining what this means, let's talk about who will not be affected by this change so that if you're among the 99% of our users who won't be affected you can just skip the rest of this article (parts of which are a bit technical).

If you are one of the rare people who have manually configured your computer to use the UO's name servers from an off-campus location, name service via those UO servers will no longer work for you as of February 1. On or before that time, you'll need to reconfigure your system to use appropriate name servers instead of "bootlegging" name service from the UO's name servers.

All other users will notice no difference when this change is made.

How Do I Know If I'm Using UO DNS Servers?

To help you identify whether or not you are using one of our DNS servers, here are their names:

For more information about how to verify whether or not you're using the UO's DNS servers, you can visit http://micro.uoregon.edu/dns/

What Is a Recursive DNS Query?

When a query is made to our DNS servers, every attempt will be made to return an IP address regardless of whether or not we are authoritative for the domain queried. This means that our DNS servers will proceed to traverse the DNS tree, recursively making queries to other DNS servers, in order to obtain an answer before responding to the client.

Why Might Someone Bootleg Name Service from the UO?

In most cases, we think that those who are bootlegging name service from the UO are doing so because their appropriate name servers--the ones that are provided for their use by their ISP--were broken or otherwise had problems. For example, on a couple of occasions in April 2005, Comcast had problems with its name servers [1]. As a stopgap measure, some Comcast users configured their systems to use other name servers (such as the UO's name servers) instead. Although Comcast's name server problems are now in the ancient past, those workarounds were never removed.

Why Must Our Name Servers Be Secured?

Disabling off-campus recursive access to the UO's name servers helps to protect the UO (and the Internet as a whole) against two types of name service-related attacks:

1. DDoS attacks. Name servers can be used as distributed denial of service (DDoS) attack amplifiers (the attacker sends a small spoofed UDP name service query to an open name server, forging the victim's IP address; the open name server then returns a large "answer" to the forged IP address--even though the victim didn't actually make the DNS query in the first place). If this is done on an ongoing basis with a large number of open name servers, it can flood the victim's IP address with responses from thousands (or tens of thousands) of name servers, thereby exhausting the victim's available network bandwidth).[2] Attacks of this sort can result in multi-Gbps flow volumes.
2. Cache poisoning attacks. Attackers can generate spoofed traffic to open recursive DNS servers that can result in so-called "cache poisoning" attacks, whereby vulnerable caching name servers can be made to return bogus results for a user's name service queries.[3]

In a nutshell: The attacker "primes" the caching name server to respond to queries with an IP address of his/her choice, rather than the real/normal IP address for that site. The innocent victim asks the caching name server for the IP address of a site of interest, such as the IP address of their bank's website. If the domain name of that site happens to be one that the attacker has poisoned, the victim is automatically and transparently misdirected to a website of the attacker's choice rather than to their bank's real web page, and confidential data can then be stolen (some refer to this type of attack as "pharming").

A variant of this attack uses cache poisoning to redirect queries for popular sites (such as google.com or hotmail.com) to a site that contains a virus or other malware. If your caching name server has been poisoned, when you try to visit one of these popular sites you can unknowingly be redirected to another site that stealthily tries to infect your PC with malware.

While blocking off campus recursive access to the UO's name servers won't completely eliminate the possibility of their participating in such an attack, eliminating recursive access will substantially reduce the likelihood of their being abused.

The UO Is Not Alone When It Comes to DNS-Related Vulnerabilities

We should emphasize that the UO is not unique when it comes to DNS-related vulnerabilities. Studies have shown that as many as 75% of all the 7.5 million or so externally visible DNS servers on the Internet are open or misconfigured, providing recursive name service for arbitrary queries.[4]

The UO is committed to being a good network neighbor and to doing what we can to secure our servers and protect our local users and the Internet at large from possible UO-related DNS-based attacks. We will be taking an important step in that regard on February 1, when we secure the UO's name servers against arbitrary recursive queries as recommended by leading security authorities.[5]

Questions or Concerns?

If you're a UO faculty member, UO student, or UO staff person and have questions about the change that will occur on February 1, 2006, please feel free to contact Network Services (nethelp@ns.uoregon.edu) or call us at (541) 346-4395 with your concerns.

Notes: [back to top]

[1] "Another Broadband Outage Strikes Comcast"
http://news.com.com/Another+broadband+outage+strikes+Comcast/2100-1034_3-5669961.html

[2] "The Continuing Denial of Service Threat Posed by DNS Recursion"
http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf

[3] "DNS Cache Poisoning The Next Generation"
http://www.lurhq.com/dnscache.pdf

[4] "Domain Name Servers: Pervasive and Critical, Yet Often Overlooked"
http://dns.measurement-factory.com/surveys/sum1.html

[5] "SANS Top 20 Vulnerabilities: The Expert Consensus"
http://www.sans.org/top20/#c6 (C6.5, "Do not allow your recursive DNS servers to be used except by your own network blocks except as required.")