Amount of Traffic

The first step in our study was to get an idea of the traffic each server is supporting. The amount of traffic in the root server is, of course, the highest. Figure 2 shows a dissection of the traffic for 5 minutes.

Figure 2: Root Server Traffic Dissection

[width=0.4,height=0.3] figures/pktdist_f.ps

The first interesting number is the total amount of traffic. During the short lapse of our trace, the root server (one of the busiest ones on the Internet) managed 30000 packets per minute: half of them where queries and the other half answers. In [DOK92] the root server dealt with 30000 packets per hour, which makes a 60-fold increase in 7 years.

Another interesting point is the behavior of a root server: it never pursues a query recursively (we see that there are no queries where the root server is the source). In fact, all what a root server knows is, for every domain name, which name server (name and address) is responsible for it. It doesn't support recursion, so unless the name you requested corresponds to one of the name servers the root server knows, you won't get your final answer from it. This seems to be coherent with the root servers role:

• they have to answer a huge amount of queries, so their information should be as static as possible.
• they must generate the minimum possible traffic for every query they receive. This means only one packet per query (the answer itself).

In an analogous way we studied a ccTLD main server. The behavior is the same than in the root server case, but the amount of traffic 7700 packets per minute, which is five times smaller than for the root server. The ccTLD studied doesn't support recursion either, so the number of queries and answers is the same.

A more interesting case is a second-level domain server (in this case ns1.berkeley.edu, one of the two main servers for the berkeley.edu domain). This name server, apart from serving as authoritative server for Berkeley's domain, is used as a local name server. Therefore, it has to support recursive queries (no resolver implements recursive queries currently). Figure 3 shows a dissection of the traffic for 5 minutes.

Figure 3: Second-level Authoritative Domain Server Traffic Dissection

[width=0.4,height=0.3,angle=-90] figures/pktdist_ns1.berkeley.edu.ps

An interesting point about this dissection is that the traffic is huge (2800 packets per minute), and an important part of it (34%) has been generated by the server itself in order to answer queries from resolvers.

As a last example, figure 4 shows the dissection of the traffic for one full day in another university name server. This case is interesting because the name server crashed for almost five and a half hours.

Figure 4: Second-level Authoritative Domain Server Traffic Dissection

[width=0.4,height=0.3,angle=-90] figures/pktdist_usc.edu.ps

An important DNS features is dynamic adaptation. If a name server requests some information to a server and doesn't receive an answer, it should try with other name servers for the same domain or at least back off before requesting again. In our case, we see that there is not a diminishing in the number of queries, but until further study we refrain from associating it to bad behaving systems (it could be that the population associated to this university name server is so huge that it requires a large amount of time for all of them realizing their name server crashed).