DNS project - Year 2 Report
Goals
The main goal of our DNS project is to supply the research community with
the best available, operationally relevant and methodologically
sound DNS measurement data. We also develop tools, models, and
analysis methodologies for use by DNS operators and researchers.
Activities
The DNS project spent its 2nd year focused on acquiring operationally
relevant DNS data and making that data available to the research
community.
-
DNS Root Servers Trace Collection
We conducted two large scale experiments collecting data from
the DNS root servers. In September 2005, anycast instances of the
C, E, and F-root servers participated in the first "Day in the Life
of the DNS Root Servers" data collection
event. The second collection took place in January 2006 and involved
anycast instances of the C, F, and K root servers. The
total volume of data (in compressed format) is 360 GB. This unique
data set represents the most comprehensive measurements of the root
servers and affords researchers an unprecedented insight into the
specifics of root server operations.
Analysis of the collected DNS traffic showed that the current
method for limiting the catchment areas of local instances appears
to be successful.
To determine whether clients actually use the instance closest to them,
we examined client locations for each root instance, and the geographic
distances between a server and its clients. We found that frequently the
choice, entirely determined by BGP routing, is not the geographically
closest one. Since additional distance between a client and a server
causes higher latency, such clients might benefit from examination and
optimization of routing for their local DNS root server instances.
Instance selection by BGP is highly stable. Over a two-day
period <2% of both C-root and F-root clients and <5% of K-root
clients experienced a change in instance of the anycast node
they were using. Most DNS traffic is still using mostly the
stateless UDP protocol for connections, so that the
vast majority of clients would not be harmed by such changes,
apart from the unavoidable delay created by BGP convergence.
However, emerging DNS technologies to support security and
other extensions to the original DNS architecture will require
the use of TCP (stateful) connections, which could encounter
problems in the face of anycast instability.
Overall, anycasting the DNS root nameservers not only extended
the architectural limit of thirteen (13) DNS root servers,
but also appears work well to improve the global robustness,
resilience, and performance of the DNS.
-
Influence map of DNS root servers
Based on available data from anycast instances of the C, F,
and K root servers, we developed a visualization that illustrates
the geographical diversity of DNS root server clients and
differences in deployment strategies of different root server nodes.
The visualization
consists of two world maps for each root, both of which project
the world as viewed from the North Pole. Each individual
anycast instance is placed on the map at the 'center of
influence' of its observed clients. To determine this location,
we consider each of a server's clients as a point with mass=1
and use those client locations to compute the centroid.
Thus, anycast root nodes that serve a primarily local clientele
remain closer to their actual geographic locations on our map,
while nodes that tend to serve a more geographically distant client set
are displaced on our maps toward the regions where they have
the most clients. In both maps, the location of each node
reflects the centroid (center of influence) of its clients'
geographic locations rather than the actual geographic location
of the server.
Wedges fanning out from each server in the larger Location Map
indicate the direction, distance, and number of clients
observed within the bounding angle of the wedge. A smaller
Displacement Map depicts servers whose actual location and
centroid are markedly different.
-
RFC1918 updates
We completed analysis of
the properties and sources of spurious RFC1918 updates that
the root servers deflect to a specially created
protective system of name servers known as AS112. (The so
called RFC1918 or private addresses are intended strictly for
use inside networks and should not leak to the outside world.)
We conducted laboratory experiments to verify the behavior
of the most recent Windows versions.
Analysis of update logs collected at two independent AS112
servers showed that leakage of DNS updates is a global network
pollution problem,
with update volume exceeding millions per hour. We applied
three signature techniques to two short packet traces and
found that over 97% of DNS updates come from various types
of Windows systems and over 99% of unique IP addresses in our
traces have at least one Windows machine at or behind it.
Windows 2000 accounts for the majority of the update packets
while Windows XP is more stringent in sending private DNS
updates. Our long term data did not reveal an obvious
decreasing trend in RFC1918 update rates due to the evolution
of operating system. Users, software vendors, and system administrators
should all take responsibility for the behavior of their
systems and
mitigate polluting behavior with
appropriate actions
-
DNS Statistics Collector (dsc)
Under subcontract to CAIDA, Duane Wessels of
The Measurement Factory developed the
DNS Statistics Collector (dsc) tool during
the first year of this project; dsc runs on selected instances of the
C, E and F root servers, and is used by some of the OARC members
to measure their own DNS infrastructure. With support from
this project OARC is making
7-days delayed dsc statistics from the F-root publicly available.
We also installed a dsc collector and presenter
on our primary nameserver (ns1.caida.org), a single
processor Pentium-4 class server running FreeBSD 5.4. It
serves about 5 domains and about 40 local machines. Using the
default collector settings, we monitor what types of clients
our nameserver has, where those clients are located, and what
types of queries the server processes.
-
Open resolvers surveys
We initiated an ongoing survey that looks for open DNS
resolvers. Open resolvers threaten the normal DNS functioning
since they allow resource squatting, are easy to poison, and
can be used in widespread Distributed Denial of Service (DDoS) attacks.
Through a subcontract The Measurement Factory developed a web interface for immediate real-time testing of individually entered addresses. We probe each of our target
IP addresses no more than once every three days.
Since June 2006 we are archiving daily reports showing the number
of open resolvers for each autonomous system number. As an example
of this data, the report from Friday, June 22, 2007 includes 10,948
autonomous systems with 300,511 open resolvers.
-
Longitudinal DNS RTT data
Using NeTraMet traffic meters installed at various locations in the US, New
Zealand, and Japan, we continued monitoring requests to, paired with
responses from, root/gTLD
servers generated by campus (i.e. large enterprise) networks.
The resulting dataset is available for researchers. It contains
information useful for evaluating performance conditions and
trends on the global Internet.
DNS RTTs are influenced by several factors, including remote
server load, network congestion, route instability,
and local effects such as link or equipment failures.
-
Anycast Simulation
In collaboration with Prof. G. Riley (Georgia Tech University),
we began laboratory simulations to study the effectiveness of
anycast deployment for DNS root servers. The goal is to
determine the impact of BGP (mainly BGP convergence) on anycast
deployment as well as possible effects from scaling up anycast
deployment on DNS performance.
In our experiments, we simulate a realistic AS level Internet topology
using data from CAIDA and the RouteViews project.
We apply BGP++'s configuration generator to convert
the inferred AS relationships to configuration files for our simulation.
Next we model two kinds of failures.
- Silent link failure:
Silent link failures can be detected by triggering BGP holdtime
timers. Although such failures could occur on any segment of
the chosen best AS path, we restrict the current simulation
to a single failure of the last hop AS link. In this failure
mode, the client would still communicate with the same server
(if it is up) through a different path.
- Explicit withdrawal of an anycast prefix by an advertising AS:
This failure makes the server unreachable which would cause the
client to switch to a different anycast server node in this scenario.
The Georgia Tech team has initial results obtained for a small-sized AS topology for the BGP-ANYCAST simulations. In the link down case,
the distribution of requests among server nodes changed
insignificantly: the clients could still reach the same servers
through other links. In the explicit prefix withdrawal case,
the network quickly converged to a new state since the simulated
graph was small and well-connected. The requests were re-distributed
to other nodes, with only one flip for affected clients.
Major Milestones
- DNS Root servers traces
-
- RFC1918 analysis
-
- RTT data
-
- Surveys
-
- Outreach
-
Student Involvement
Ziqian Liu, a visiting scientist from China, collaborated with CAIDA
researchers in analysis of 48-hour tcpdump traces from 53 anycast
root servers (4 from c-root, 33 from f-root, 16 from k-root). He
examined geographical and topological coverage from each instance
and analyzed the stability of client-to-server affinity.
Two graduate students from Georgia Tech, Sunitha Beeram and Talal Jaafar,
worked on laboratory simulations of the anycast deployment effectiveness.
|
|
Cooperative Association for Internet Data Analysis (CAIDA)