In this section, we present our findings on the size and structure of the client-side DNS infrastructure.
3.5.1
Estimating Global ODNS Population
Extrapolating from our limited scans of IP space, we estimate that there are approximately 32M ODNS servers on the Internet today. We arrive at this result from two independent scans. First, we find almost 2M ODNS within a set of 254.7M probed IP addresses in the “Random IP” scan S1 where addresses are chosen randomly from the complete 232
address space. Therefore, we estimate the population size as 2M/254.7M ×232 = 33M ODNS servers across the Internet. Second, from the “Random /24” scan S2, the fraction of productive /24 address blocks (those with at least one ODNS server) is 0.141 and a
productive block contains on average 13 ODNS servers. Therefore, the ODNS population across the entire Internet is0.141×13×224= 31M.
These estimates significantly exceed previous results of complete Internet scans [LL10] and estimates [Sis10], which show around 15M responding DNS resolvers. One of our partialscans (S3) using the “Scan on First Hit” strategy directly identifies 17.6M
1 10 100 1K 10K 0 0.2 0.4 0.6 0.8 1
Number of FDNS servers that use the RDNS server
CDF pe
r RDNS
ser
ver
Figure 3.10: Number of FDNS servers per RDNSiin theS2scan.
ODNS servers—more than found in previous full scans. Additionally, [Opea], a complete Internet scan, reports 33M open resolvers as of May 2013 which agrees with our estimate. The results show the population of ODNS servers on the Internet has increased dramatically since previous studies. We do not have an explanation for this increase, and note that since our scans, [Opea] has observed a drop in the number of open resolvers to approximately 19M at the time of writing.
3.5.2
FDNS Population Size Per-RDNS
We find that many FDNS servers use the same RDNS servers. Figure 3.10 shows the number of FDNS servers per RDNSi server in theS2 dataset. Over 80% of the RDNSi servers are used by more than one FDNS server and 50% of RDNSiservers appear with at least 10 FDNS servers in the dataset. This result indicates that many FDNS servers use the same resolution infrastructure upstream. While expected, it is an important observation to keep in mind when performing measurements.
3.5.3
RDNS Pool Sizes
The ODNS servers we find in both ourS1scan andS2scan utilize RDNS servers in roughly 99% of the cases—i.e., they are in fact FDNS servers. Moreover, approximately 70% of FDNS servers use an RDNS pool in both scans. Per § 3.4.2, we use repeated DNS requests and CNAME chaining triggered by per-ODNS discovery of a new RDNS server to identify RDNS pools used by an FDNS server. Figure 3.11 shows the size distribution of the discovered RDNS pools in theS2 scan. The plot shows that 10% of FDNS servers use RDNS pools consisting of more than 10 servers. Also, note that these pools can encompass multiple providers, e.g., an ISP’s own DNS infrastructure and OpenDNS, which could occur when either the FDNS server is configured to use both, e.g., one as the primary DNS server and the other as the secondary DNS server, or the ISP is utilizing an alternate DNS infrastructure for some queries. The pools we discover are smaller than those discovered by a previous study [Cal12] where roughly 20% of RDNS pools are larger than 10 servers. The difference may be due to the timescale of the experiment. We perform our discovery of RDNS servers immediately after discovering the FDNS server, whereas the previous work continues to probe over an extended period of time (up to 1 billion seconds). If FDNS server to RDNS server assignment changes with time, [Cal12] will discover all RDNS servers used and interpret them as belonging to a single pool, while our measurements will only discover the RDNS servers that are used by the FDNS server at the time that the FDNS server is discovered.
3.5.4
Distance between FDNS servers and RDNS servers
As discussed in § 3.4.1, ODNS servers—and consequently FDNS servers—are predomi- nantly in residential settings and thus close to the client. Several previous studies look at the distance between clients and the RDNS servers that they use because (i) large distances can lead to high DNS latency and (ii) content delivery networks assign clients to replicas that are near the RDNS server based on the assumption that clients are also near to their
1 10 100 1K 0 0.2 0.4 0.6 0.8 1 RDNS pool size CDF pe r FDNS ser ver
Figure 3.11: Distribution of the RDNS pool size for each FDNS in theS2scan. RDNS server.
Prior studies [HMLG11, ARS13, Cal12] consider the physical distance between the clients and their DNS resolvers, finding that some clients are far from the resolvers that they use. We measure the distance between FDNS servers and RDNS servers in terms of latency. For this, we measure (1) the rough-trip-time (RTT) from our measurement point to the FDNS server and (2) the RTT from our measurement point to the RDNS server through the FDNS server. The difference between (2) and (1) is the RTT between the FDNS server and the RDNS server. We cannot measure RTT to the FDNS server by querying for a record previously placed in the FDNS server’s cache because there is no way to determine whether the record is returned via the FDNS server’s cache or an RDNS server’s cache. Fortunately, we found that some FDNS servers respond to ICMP Echo requests. In theS5 scan, we obtained (1) the RTT from our measurement point to the 22% of the FDNS servers that were responsive to a ping.
1 10 100 1K 10K 0 0.2 0.4 0.6 0.8 1
RTT from FDNS to RDNS pool (milliseconds)
CDF pe r FDNS ser ver Min Mean Max
Figure 3.12: Distribution of round trip time between FDNS and RDNS.
server through the FDNS server, we leverage our observation that many FDNS servers use the same RDNS server (§ 3.5.2). Using 2 FDNS servers that both query the same RDNS server upstream, we add a record to the RDNS server’s cache via a probe from the first FDNS server. We then obtain the distance from our measurement point to the RDNS server through the second FDNS server by querying for the same record through the second FDNS server. We also repeat the process by swapping the roles of the two FDNS servers. We perform this measurement for each FDNS pair we discover using the same RDNS during discovery. Using this technique, we are able to obtain the round trip time from FDNS server to RDNS server for 5.6M FDNS/RDNS pairs across 1.3M unique FDNS servers.
In the case of multiple measurements per FDNS/RDNS pair, we choose the mini- mum delay value as it most accurately reflects the actual network delay between the FDNS and RDNS servers. We plot the results in Figure 3.12. The median round trip time is about 10 ms, however nearly 20% of the FDNS servers experience delays in excess of 200 ms to at least one of their RDNS servers. While the delay may be more closely related to net-
work conditions and server load than transmission time and distance, these FDNS servers nevertheless suffer a high cache miss cost.