Resolvers are servers on the Internet which use the Domain Name System (DNS) protocol [TXT, 120 KB] to retrieve information from authoritative servers and return answers to end-user applications. They’re often found in enterprise and ISP networks, and there are a number of public resolver services provided by people like Google and OpenDNS. It’s also possible to configure your own computer to be a resolver, or to deploy your own in your own network using free software like ISC BIND9 and NLNet Labs’ unbound.
So, all in all, how many resolvers are there? Given that anybody can run one, it seems like a difficult thing to measure. It turns out, however, that all resolvers that talk directly to authoritative servers on the Internet leave a trail, and with a little data crunching we can come up with a number.
Back in 2010, ICANN, VeriSign and NTIA concluded a successful collaboration to deploy DNSSEC [TXT, 52 KB] in the root zone of the DNS. As part of that project, Root Server Operators collected DNS requests that were delivered to their individual Root Server infrastructure, and deposited the resulting data with DNS-OARC for analysis.
The goal of this data collection exercise was to try and identify any potential problems for DNS clients due to DNSSEC deployment. The by-product of this exercise, however, is a data set which provides insight into DNS traffic between a highly-representative set of DNS resolvers and DNS authority servers (almost all resolvers talk to a root server every once in a while).
One of the data collection exercises carried out had a particularly long time-base. The collection is referred to as "LTQC" (Long-Term Query Collection) and it concerned itself just with priming queries, that is, the initial query that every resolver sends to a root server when it starts up in order to obtain an up-to-date set of DNS root server names.11 of the 13 root servers contributed data to this collection, including L-Root, the root server operated by ICANN. Data was collected between November 2009 and July 2010.
So, here’s our methodology: we look at every request contained in the LTQC packet-capture, and count the number of unique IPv4 and IPv6 source addresses.
During the collection period, we saw 9,945,017 unique source addresses, of which 59,489 (0.60%) were IPv6 and and 9,885,528 (99.40%) were IPv4.
So which resolvers won’t we see?
We won’t see internal resolvers that don’t send queries to authoritative servers on the Internet directly, but instead send them via other intermediate resolvers. Included in this class of resolver are any that are hidden behind middleboxes that redirect DNS queries to a central cache, or otherwise change normal priming behaviour.
We won’t necessarily see internal resolvers that are deployed behind a Network Address Translator (NAT) — at least, in such a situation we might see only some of them.
We won’t see resolvers that started (and primed) before the data collection period started, and then never primed again before the end of that period.
We obviously won’t see any resolvers that were brought live after the collection period ended, and we assume that the number of resolvers is probably increasing due to the general growth of the Internet.
Any resolver that was renumbered during the collection period (and primed before and after the renumbering event) would be counted twice. Intuitively, this seems like a minor effect; we think most resolvers are renumbered fairly infrequently, since they are generally referred to by address rather than name.
Given the expected errors in the number we measured due to the effects described above, it seems appropriate to round the answer to a single significant figure; this at least gives us an order of magnitude for a lower bound.
What we are left with? That there are at least 10 million DNS resolvers on the Internet today.