<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 &quot;LTQC&quot; (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>