Comparison of Subsets of Clients of DNS Root Servers - 2002-08-29

Comparison of Subsets of Clients of DNS Root Servers

Data were collected for approximately 4 days starting Thursday 2002-08-29 21:19:25 in 10 minute intervals from {a,e,f,i,k,m}-root servers using dnsstat, which counts DNS messages and requests on UDP port 53 by src/dst address, opcode, qtype, and qclass. The collectors at {a,e,i,k,m}-root were each run on a host that was connected to a link that carried the root server traffic (either directly or mirrored). At f-root, there are 4 hosts sharing the root server load; on each of them, tcpdump was used to forward data to a nearby host where dnsstat was run.

Table labels:

"(A || PTR) && MX" is the subset of clients which sent at least one A or PTR request and at least one MX request.
"!RD" is the subset of clients whose requests always had the RD (recursion desired) bit set to 0.
"all clients" is the set clients without either of the two above filters applied
"bogus" clients are those which sent one or more "bogus" queries, i.e. a query with an undefined opcode, qtype, or qclass.

Click on any graph to see a larger version.

Summary

The point of this exercise was to try to find the subset of root server clients that are well-behaved aggregating servers.

If the root servers gave only referral responses, we could put an upper bound on the number of queries a well-behaved client should make: Given that there are about 250 top level domains, and apparently most of them have a TTL of 3 days, a well-behaved client should query the roots at most 500 times in 4 days. However, root servers are also authoritative for some zones, so it is difficult to find an upper bound. To get around this issue, we can try looking at responses instead of queries.

I don't think the ((A || PTR) && MX) filter is useful. Intuitively, it just seems too arbitrary, and prone to false positives and false negatives. And, while the accumulation graphs show the expected levelling-off, the number of requests graphs show a large number of clients with an excessive number of queries (but it is hard to tell whether these numbers are too large). The !RD and non-bogus filters probably have very low rate of false negatives, but they also don't eliminiate very many clients, so are insufficient by themselves.

Perhaps a better filter would be all of the bad query checks made by DW for his NANOG presentation: repeated queries, unknown TLD, "A" query for an address, nonprintable QNAME, "PTR" query for an RFC 1918 address, queries with undefined qclass. (This would require a new set of data collected with an enhanced dnsstat, since the current data do not contain this information.) Then there's the question of whether to eliminate clients that made any bad queries, or clients that made nothing but bad queries, or clients that that make mostly bad queries.... Looking at responses instead of queries could help with this issue as well.

Accumulation of unique clients

These graphs show the number of unique clients seen by each individual server and by all servers combined, accumulated over the course of the collection period.

	all clients	(A \|\| PTR) && MX	!RD
with bogus
without bogus

Unique clients per interval

These graphs show the number of unique clients seen in each 10 minute interval by each server and by all servers combined. Notice the clear diurnal pattern (08-31 and 09-01 was a weekend).

	all clients	(A \|\| PTR) && MX	!RD
with bogus
without bogus

New clients per interval

These graphs show the number of new unique clients seen in each 10 minute interval by each server and by all servers combined; that is, clients that had not been seen in any previous interval.

	all clients	(A \|\| PTR) && MX	!RD
with bogus
without bogus

Requests per interval

These graphs show the number of queries seen by individual servers. Note that some clients byte-swap the 16-bit QDCOUNT field, so the value 1 is incorrectly written as 256. Queries in such messages are counted here even though they should probably be ignored, since the DNS server rejects these messages.

	all clients	(A \|\| PTR) && MX	!RD
with bogus
without bogus

Number of requests sent by clients

These graphs show the CDF or CCDF of the number of request messages sent by clients to each server.

If the root servers gave only referral responses, we could put an upper bound on the number of queries a well-behaved client should make: Given that there are about 250 top level domains, and apparently most of them have a TTL of 3 days, a well-behaved client should query the roots at most 500 times in 4 days. Any graph here with a large fraction of clients making more than 500 queries means the filter used to create the graph was ineffective at filtering out badly behaved clients.

CDF, lin/lin

	all clients	(A \|\| PTR) && MX	!RD
with bogus
without bogus

CDF, log/lin

	all clients	(A \|\| PTR) && MX	!RD
with bogus
without bogus

Overlap of client sets

Intersections and unions of client sets of pairs of root servers, with union of all servers for comparison.

	all clients	(A \|\| PTR) && MX	!RD
with bogus
without bogus

unions

	all clients	(A \|\| PTR) && MX	!RD
with bogus
without bogus

Request Opcodes, Types, and Classes

Request opcodes, types, and classes seen at all monitored servers, in full view and zoomed in. "Unknown" includes all requests with a non-standard opcode, type, or class; "other" includes all sets that had counts lower than the count of the lowest explicitly named sets. Opcodes QUERY, IQUERY, STATUS, NOTIFY, UPDATE are abbreviated to their first letter in the legends.

	all clients	(A \|\| PTR) && MX	!RD
with bogus	List of query types and counts	List of query types and counts	List of query types and counts
without bogus	List of query types and counts	List of query types and counts	List of query types and counts