ITHI M4: DNS Recursive Server Analysis

Graph showing DNS clients resolvers and servers and traffic observation

The M4 metrics measure the usage of TLDs and leakage of undelegated strings by DNS users. As shown on the figure on the right of this text, this is not the same measure as M3, because most users do not contact the root servers directly. Instead, they will contact a DNS Recursive Resolver, which may be provided by their connectivity provider, by their organization, or by a third party. These recursive resolvers will often respond to queries with cached responses, so the root will only observe a very small fraction of the queries. The goal of M4 is to measure the usersí behavior, which will be done by analyzing traffic at recursive resolvers.

The usage of TLD and leakage of undelegated names is measured in M4 by 4 metrics:

The measurement of M4.1, M4.2 and M4.4 is straightforward, but M4.3 deserves some explanation. The initial implementation would just find the top 128 strings seen at each recursive resolver participating in the study, and list the corresponding names in the summary. Then we would merge statistics from multiple sources, and retain the list of names that were found most frequently. This turned out to be problematic, because the most frequent errors happen when clients look up a local server name using the wrong domain prefix, such as looking for "myserver" instead of "myserver.example.com". The names of local servers tell a lot about the local domains, and we feared that exposing them in statistics would be a privacy violation.

We mitigate that privacy issue by categorizing leaked names as either "local" or "global". We consider that a leaked name is "global" if it belongs to the list of the names most frequently leaked to the root, and we consider the other names as "local". In the summaries, we tabulate all frequently leaked global names individually, but we group all local names under a single category, "local host names".

In addition to measuring name leakage, we also measure DNSSEC deployment with 1 metric:

To compute the metric 4.5, we identify the clients by their IP address, and we weight each client equally. We count a client as "DNS Ready" if it sets the "DNSSEC OK" option (DO) in its queries. There is a slight uncertainty in this measurement, as the traces will not just contain queries sent by the clients, but also queries sent by the recursive resolver itself. However, the number of IP addresses used by clients vastly exceeds the number of addresses used by the resolver, and we can ignore this error.

To compute the metric 4.6, we find the zone associated with queries using the open source Public Suffix List maintained on GitHub by the Public Suffix project. We then look at the subset of queries in which the DO bit was set. If the response included a DNSSEC records such as DNSKEY, RRSIG, NSEC, NSEC3, or DS, we conclude that the corresponding zone is supporting DNSSEC. In constrast, if we find queries in which the DO bit is set but never receive any DNSSEC response, we assume that the zone is probably not supporting DNSSEC.

The current values of the metrics is available here.