<div class="headline_area">
                                        <h1 class="entry-title">Ten Million DNS Resolvers on the Internet</h1>
                                        <p class="headline_meta"><a href="http://blog.icann.org/2012/03/ten-million-dns-resolvers-on-the-internet/">http://blog.icann.org/2012/03/ten-million-dns-resolvers-on-the-internet/</a></p><p class="headline_meta">by <span class="author vcard fn">Joe Abley</span> on <abbr class="published" title="2012-03-22">March 22, 2012</abbr></p>
                                </div>
                                
<p>Resolvers are servers on the Internet which use the <a href="http://www.ietf.org/rfc/rfc1035.txt">Domain Name System (DNS) protocol</a>
[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 <a href="http://code.google.com/speed/public-dns/">Google</a> and <a href="http://www.opendns.com/">OpenDNS</a>.
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 <a href="http://www.isc.org/software/bind">ISC BIND9</a> and <a href="http://www.nlnetlabs.nl/projects/unbound/">NLNet Labs’ unbound</a>.</p>
<p>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.</p>
<p><span id="more-3455"></span></p>
<p>Back in 2010, ICANN, VeriSign and NTIA concluded a <a href="http://www.root-dnssec.org/">successful collaboration</a> to deploy <a href="http://www.ietf.org/rfc/rfc4033.txt">DNSSEC</a> [TXT, 52 KB] in the root zone of the DNS. As part of that project, <a href="http://www.root-servers.org/">Root Server Operators</a>
collected DNS requests that were delivered to their individual Root
Server infrastructure, and deposited the resulting data with <a href="http://www.dns-oarc.net/">DNS-OARC</a> for analysis.</p>
<p>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).</p>
<p>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. </p>
<p>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.</p>
<p>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.</p>
<p>So which resolvers won’t we see?</p>
<p>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 <a href="http://en.wikipedia.org/wiki/Middlebox">middleboxes</a> that redirect DNS queries to a central cache, or otherwise change normal priming behaviour.</p>
<p>We won’t necessarily see internal resolvers that are deployed behind a <a href="http://en.wikipedia.org/wiki/Network_address_translation">Network Address Translator (NAT)</a> — at least, in such a situation we might see only some of them.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>What we are left with? That there are at least 10 million DNS resolvers on the Internet today.</p>