How to use a personal DNS for root-server attack isolation

Provided a couple of programmers are correct, what started out as an attempt to provide better Domain Name System (DNS) server performance on Windows machines may also be one way to reduce DNS security concerns.

Surprisingly enough, the project is centered on a specially configured derivative of BIND 9.2 (Berkeley Internet Name Domain) localized to the user's machine. This localized DNS—called BIND-PE and available on NTCanuck.com—was initially announced on Gibson Research Corp.'s (GRC) news server, news.grc.com, in a newsgroup related to GRC's Domain Name System Research Utility (DNSRU), which was designed to test the DNS system's performance and expiration rates.

The BIND server is the most frequently used name server on the Internet and provides the mechanism that translates domain names to Internet Protocol addresses for Web browsers and other Internet applications. Ordinarily, an Internet service provider (ISP) provides several name servers for its customers' use. BIND-PE, however, provides an ISP-independent DNS that runs directly on users' computers.

An unfortunate episode spurs the action

My immediate attraction to running a localized DNS was the possibility of avoiding potential local-cache poisoning of my ISP's DNS servers. DNS cache poisoning is an attack exploit on a DNS server that replaces the Internet address mapping of a domain name with the IP address of another computer. I became the victim of a DNS cache poisoning when my attempt to visit the CNN Web site resulted in my browser taking me to a Web site that offered content of an entirely different nature.

1pixclear.gif
Randal Vaughn is a professor of information systems at Baylor University in Waco, Texas.
1pixclear.gif
Randal Vaughn is a professor of information systems at Baylor University in Waco, Texas. He can be reached at Randy_Vaughn@Baylor.edu.

Cache poisoning may not just result in an embarrassing incident such as mine, but it could also be used to redirect your browser from, say, your bank's Web site to some other server that looks enough like your bank to cause you to suffer financial loss. Needless to say, I am highly motivated to prevent this sort of problem in the future. Even so, I felt it worthwhile to consider the performance of localized DNS.

DNSRU came into existence after GRC attempted to dodge a denial-of-service attack by changing its domain IP. Laguna Hills, Calif.-based GRC noticed that DNS servers didn't always properly honor the company's short (10-minute) cache expiration time by returning to GRC's authoritative servers to update their domain IP. The DNSRU tests comprise a number of queries designed to measure a DNS server's responses to cached, uncached and known domain names.

To measure a server, DNSRU assembles several hundred requests for names such as 3bglnvvvzeyrk5f3xqsqrxflqh.computerworld.com and nvtfp1prswuqzfnfcatcgpiufc.com, as well as requests for names of a number of other popular Web sites. Gibson published DNSRU in order to gather test results from a large number of DNS servers. Each DNSRU report includes the IP of the server, the Coordinated Universal Time (UTC) of the test run and performance metrics for the server.

A typical DNSRU test run, such as one run using an ISP's DNS server, produces a summary of the test results such as:

66. xxx.xxx.xxx Min Avg Max Std.Dev Reliab%
Cached Name 0.025 0.038 0.057 0.006 99.0
Uncached Name 0.051 0.097 0.212 0.028 100.0
DotCom Lookup 0.083 0.097 0.150 0.013 100.0

UTC: 2002-12-14, from 22:05:58 to 22:06:53, for 00:55.419

I have masked the true IP of the server in the above DNSRU output to 66.xxx.xxx.xxx in order to protect the DNS.

The same test against using the localized DNS server running on localhost (127.0.0.1) produced:

127. 0. 0. 1 Min Avg Max Std.Dev Reliab%
Cached Name 0.000 0.000 0.002 0.000 100.0
Uncached Name 0.037 0.092 0.210 0.034 99.5
DotCom Lookup 0.065 0.085 0.120 0.010 100.0

UTC: 2002-12-14, from 22:05:05 to 22:05:38, for 00:33.478

Such typical results suggest that localized DNS indeed has a significant performance advantage for cached names and hint of improved performance for "DotCom" lookups, but they don't offer improvement for uncached names over the ISP's DNS. The improved caching times are the result of the localized DNS's implementation of a persistent cache facility. A DNSRU test run consists of several hundred queries. The Reliability column implies that both the ISP's DNS and localized DNS failed to respond to a few queries, which is common to all such test runs. It's interesting to note the localized DNS, BIND-PE, is configured to use root servers maintained by Open Root Server Confederation Inc. (ORSC) rather than the standard roots used by my ISP.

DNSRU's expiration tests depended upon GRC's DNS server providing a specialized name with a time-out of a few seconds. Both the ISP's DNS server and localized DNS performed satisfactorily on the expiration tests. A packet capture of a few DNSRU test runs established that my ISP's standard DNS server generated nearly 1,600 packets per test, whereas localized DNS generated slightly over 1,800 packets on its initial DNSRU test and around 850 packets per test on subsequent tests. DNSRU bypasses Windows' DNS Client cache, so I can conclude that the localized DNS cache is working properly but can't determine if localized DNS offers an overall traffic reduction.

There are, of course, a few potential disadvantages to running a localized DNS. First, a wide distribution of such a tool might eventually render home users vulnerable to specific exploits. The current BIND-PE wouldn't be applicable in commercial settings when they require specific DNS entries. According to Richard Sexton, an ORSC board member, the ORSC root servers used in the default BIND-PE installation will resolve all of the requests to a current top-level domain (TLD). He points out that an ISP using transparent proxy caching could prevent resolving requests to ORSC-supported enhanced TLDs, such as .ocean. In spite of the potential hazards, a wide distribution of localized DNS may make denial-of-service attacks against root servers less likely.

Paul Mockapetris, chief scientist at Nominum Inc. and founder of the DNS system, recently suggested that DNS operators keep a current copy of root zones in order to isolate themselves from future root-server attacks. Sexton points out that if local root zones were a common practice, DNS operators would seldom notice any root-server outages. An obstacle to this approach is the perception that it requires considerable technical expertise.

For the casual computer user, installing a localized DNS would appear to be a daunting experience, and periodic root-zone updates would likely be ignored. The BIND-PE distribution, however, automatically configures the server to run and includes a "root-slave" configuration to make the localized DNS act as an ORSC root-server slave with all the needed TLD information in a local file.

Furthermore, the localized DNS automatically updates Root Zone data. This configuration allows the casual user to have up-to-date personal mirrors of root-server data without an intimidating hurdle of configuration. Such an approach could also be adapted for ISP or corporate DNS servers. The root-slave approach allows DNS operators to avoid the risk of future root-server attacks and, if implemented on a wide scale by individuals using a localized DNS or other DNS operators, it could reduce the motivation for future root-server attacks.

Copyright © 2003 IDG Communications, Inc.

It’s time to break the ChatGPT habit
Shop Tech Products at Amazon