This study, commissioned by Infoblox, aims to measure the number of DNS servers and quantify the spread of several configuration choices. In particular, the study measured:

  • What DNS server software and version is used,
  • Whether recursion is supported,
  • To what degree redundant servers are topologically diversified,
  • Whether servers agree with their parent zone,
  • What TTL and SOA values are used,
  • Whether a zone has a lame server,
  • Whether servers are configured for IPv6, SPF, or DNSSEC.


Dataset I -- Random IP Addresses

For this Dataset, we probed a random subset of all IPv4 addresses in use on the Internet. We began with an October 2008 snapshot of the global routing table taken from the Route Views project with a total of 1,911,124,210 routed IPv4 addresses. We then eliminated .mil/.gov subnets and a few subnets where the operators had previously asked us to be excluded from future scans and then randomly selected 5% of the remaining IPs for our survey, leaving us with 99,295,351 addresses to probe.

Dataset II -- Nameserver authoritative for .com/.net domains

This Dataset contains nameservers authoritative for a registered .com or .net domain. We treat this as a separate Dataset because the authoritative name servers can be assumed to be more stable over time, better maintained, and more heavily used on average than nameservers randomly discovered. Furthermore, this Dataset is used to characterize the adoption of new technologies in the DNS, namely IPv6, DNSSEC, and SPF. From a list we received from Verisign with 182 million .com and 28 million .net domains, we randomly chose a set of one million domains and randomly select one one of the servers authoritative for that domain.


Number of Nameservers

We sent a simple DNS query to each probe address in the two data sets., which asks for the IPv4 address of, and has the RD bit set. A response indicates that there is a DNS server listening on the probe address. We did not implement timeouts and retransmission, so packet loss may affect these measurements. On the other hand, non-DNS responses of services listening on UDP port 53 are counted as DNS servers. The following table summarizes the number of queries and replies:

Dataset I
Hosts queried 99,295,351
Hosts replying 618,312 0.62%

Note that some addresses sent back more than one reply, even though we sent only one query. This happens either because the probe address actually sends multiple responses for a single query, or because the reply source address may be different than the query destination address. We suspect that some ISPs intercept incoming DNS queries and forward them to a central server, but the server responds from its own address.

Based on these numbers we can estimate that there about 11,900,000 nameservers running on the Internet. Our previous estimate was 11,700,000 in October 2007. Some fraction of these servers can be expected to be part of malware activities as shown by Dagon et al.

Software Versions

For each nameserver found, we attempted to determine its server software and version using a combination of two techniques. First, we use the fpdns tool to fingerprint the server, which usually results in a range classification of possible versions, for example "BIND 8.3.0-RC1 -- 8.4.4". Second, we send a version.bind query to the address and refine the fpdns result iff the version reported by version.bind falls in the range of possible versions as determined by fpdns (one exception being newer BIND 9 version that we subsume in the highest BIND classification that fpdns provides). While the version.bind technique is simple, many servers are configured to report no result or an obscured result. Hence, we give preference to the fpdns classification.

Our analysis determined the following distribution of namerserver software and versions.

Server sofware Dataset I Dataset II
BIND 263,011 42.54% 618,949 58.65%
4.9.3-4.9.11 322 0.05% 2,988 0.28%
8.1-REL -- 8.2.1-T4B 1,439 0.23% 5,165 0.49%
8.2.2-P3 -- 8.3.0-T2A 338 0.05% 10,584 1%
8.3.0-RC1 -- 8.4.4 7,000 1.13% 65,233 6.18%
9.0.0b5 -- 9.0.1 306 0.05% 272 0.03%
9.1.0 -- 9.2.0rc3 4,250 0.69% 1,103 0.10%
9.2.0rc4 -- 9.2.2-P3 7,742 1.25% 43,460 4.12%
9.2.3rc1 -- 9.4.0a0 241,614 39.08% 490,144 46.44%
9.2.[3-8] 28,090 4.54% 98,289 9.31%
9.3.* 38,274 6.19% 112,982 10.71%
9.4.* 18,670 3.02% 43,738 4.14%
9.5.* 8,753 1.42% 26,239 2.49%
unknown 147,827 23.91% 208,896 19.79%
Nominum CNS/ANS 72,560 11.74% 4,612 0.44%
vermicelli totd 11,226 1.82% 273 0.03%
VeriSign ATLAS 10,093 1.63% 153 0.01%
Mikrotik dsl/cable 5,442 0.88% 0 0%
ATOS Stargate ADSL 3,578 0.58% 0 0%
robtex Viking DNS module 1,823 0.29% 0 0%
DJ Bernstein TinyDNS 1,226 0.20% 47,632 4.51%
bboy MyDNS 1,219 0.20% 41,927 3.97%
JHSOFT simple DNS plus 572 0.09% 13,523 1.28%
PowerDNS 618 0.10% 48,275 4.57%
Microsoft Windows DNS 2003 530 0.09% 1,082 0.10%
Alteon ACEswitch 511 0.08% 0 0%
Cisco CNR 484 0.08% 270 0.03%
Runtop dsl/cable 479 0.08% 544 0.05%
Raiden DNSD 378 0.06% 2 0%
Beehive CoDoNS 304 0.05% 5 0%
Axis video server 289 0.05% 0 0%
sheerdns 230 0.04% 270 0.03%
Microsoft Windows DNS 2000 234 0.04% 551 0.05%
Microsoft Windows DNS NT4 218 0.04% 825 0.08%
Other 244,354 39.52% 277,227 26.27%
No match found 122,155 19.76% 131,746 12.48%
timeout 120,166 19.43% 131,097 12.42%
no result 1,102 0.16% 13,461 21.07%

It is surprising to see such a large number of home routers being reachable from the Internet on Port 53.


To test for open recursors we send a unique query for a name in a zone that we control to each nameserver. If we receive a valid response to this query, we say that the target is an open resolver.

We found 271,688 nameservers in Dataset I that support recursion. Extrapolating to the entire address space, we estimate that there are 4,300,000 open resolvers on the Internet that reply to a query. Note, that our last year's scan found a significant number of open resolvers that will forward a query, but not respond. These servers are not counted in our current experiment to keep the results consistent with the overall number of name server that we report.

The following table shows the software running on open resolvers that respond to recursive queries.

Server sofware Dataset I Dataset II
BIND 9 41,437 88.86% 262,582 59.78%
BIND 8 831 1.78% 56,947 12.96%
bboy MyDNS 707 1.52% 6,783 1.54%
DJ Bernstein TinyDNS 379 0.81% 6,066 1.38%
sheerdns 234 0.50% 271 0.06%
PowerDNS 160 0.34% 9,429 2.15%
JHSOFT simple DNS plus 89 0.19% 5,486 1.25%
UltraDNS 36 0.08% 5,193 1.18%
Other 3,578 7.67% 79,172 18.02%
Timeout 303 0.65% 7,422 1.69%
No match found 3,263 7.00% 73,533 16.74%

Source port randomization

Servers that send queries from predictable source ports are vulnerable to cache poisoning attacks. We test the degree of randomization using the DNS OARC Porttest. The test distinguishes between great, good, and poor randomization. The results in the following table only include servers for which the porttest yielded a result (e.g., non-recursive servers are excluded from the tests by definition). Furthermore, we executed the porttest only on a subset of servers so to not overload the OARC test server.
Dataset I Dataset II
Poor 6,85123.99% 3,97443.16%
Good 2020.71% 1241.35%
Great 21,50675.30% 5,10955.49%
The following table shows the distribution of server version with poor source port randomization:
Server sofware Dataset I Dataset II
BIND 9 32941 48.26% 69,690 80.41%
Nominum CNS 16,859 24.70% 268 0.31%
Mikrotik dsl/cable 614 0.90% 0 0%
JHSOFT simple DNS plus 446 0.65% 4,644 5.36%
vermicelli totd 212 0.31% 0 0%
Microsoft Windows DNS 2003 176 0.26% 549 0.63%
BIND 8 160 0.23% 804 0.93%
Microsoft Windows DNS 2000 91 0.13% 310 0.36%
ATOS Stargate ADSL 54 0.08% 0 0%
robtex Viking DNS module 53 0.08% 0 0%
PowerDNS 36 0.05% 20 0.02%
Cisco CNR 36 0.05% 1 0.00%
Other 15,824 23.18% 10,711 12.36%
Timeout 3,997 5.86% 9,036 10.43%
No match found 12,039 17.64% 1,651 1.91%
Total servers 68,263 86,666

Results for Dataset II -- Authoritative Nameservers

The following tests are particular to the second data set since they require knowledge of a zone for which a server is authoritative.

Zone transfer (AXFR)

We test for zone transfer by invoking the dig command with the parameters
dig @ +short +time=2 axfr
If the transfer fails or times out, we interpret this as AXFR being not supported. We find that out of 12,850 zones, 3,955 (30.78%) zones support AXFR.


In this part of the survey, we are interested in finding out how many zones have at least one nameserver with an IPv6 address. While Verisign does not allow insertion of AAAA glue records in the COM/ZONE files, zone owners may elect to add them to their own zones.

To make the comparison, we ask for the IPv4 and IPv6 addresses (AAAA records) of all authoritative nameservers for each zone in Dataset II.

Among 161,300 zones we scanned, we found only 711 (0.44%) zones that report at least one IPv6-addressed nameserver.

Note that because the probed nameservers come from domains in the COM and NET zones, this data is not necessary an accurate reflection of worldwide IPv6 adoption for DNS nameservers.


DNSSEC is an evolving protocol. The first version (RFC 2535, March 1999) defines the KEY, SIG, and NXT record types. The second version (RFC 4035, March 2005) essentially obsoletes the first-generation RR types and adds four new ones: DNSKEY, NSEC, RRSIG, and DS. We queried the set of nameservers for both old and new RR types.

In Dataset II, we found only 45 DNSSEC records.

DNSSEC adoption is still very small -- similar to last year's level. This trend surprises since DNS security had been taken more seriously after the recent problems with DNS poisoning.

Our results are limited to .com and .com zones and probably under-represents DNSSEC adoption across the whole Internet, since some European CCTLDs have been more proactive in encouraging the use of DNSSEC.


Sender Policy Framework (SPF) is an anti-spam technique by which organizations can list valid sources of email (i.e., IP addresses) from their domain. To publish SPF information, an organization creates a TXT record in their zone file. Mail transfer agents may lookup SPF information when receiving email messages. In addition to the TXT record format, SPF now also has its own DNS RR, type 99.

Within data set II, we found 176,496 (16.72%) servers with TXT-based SPF records or with type 99 records.

Are a zone's nameservers topologically dispersed?

RFC 2182 states: secondary servers must be placed at both topologically and geographically dispersed locations on the Internet, to minimize the likelihood of a single failure disabling all of them. While we do not test for geographic diversity, we can easily examine the topologic aspects of a zone's nameservers. Our assumption that topologic locality implies geographic locality is is true in most, but not quite all cases. The following table shows the percentage of zones having all their authoritative nameservers within the given CIDR-sized subnets:

CIDR MaskPercentageCumulative

Matching of authoritative NS records

Here we examine whether delegation NS records (listed in the parent zone) match the authoritative NS records (found in the zone itself). We distinguish between match, not match, and the case where the supposedly-authoritative nameservers (learned from the parent zone) did not return any NS records for the zone

No authoritative nameserver378,26036.2%

Matching of TTL records across NS records

Here we consider two slightly different cases. The first table shows the percentage of zones where the authoritative nameservers return NS records with mis-matched TTLs. This includes all NS records from all nameservers for a zone. The first column is the number of unique TTLs returned:

Same for all NS1,009,57296.4%

Conformity of SOA records

The SOA record are supposed to be within certain ranges. We test what fraction of servers adhere to the suggested values.


RFC 1912 suggests that the SOA Refresh value should be at least 20 minutes and no longer than 12 hours. The following table shows the distribution of Refresh values:

20m to 12h899,30886.61%


RFC 1912 suggests that the SOA Retry value is typically less than the Refresh value. The following table shows the distribution of Retry values:

retry <= refresh1,005,15997.0%
retry > refresh31,4023.0%


RFC 1912 suggests that the SOA Expire value should be at least 2 weeks and no longer than 4 weeks. The following table shows the distribution of Expire values:

2w to 4w167,07516.26%


RFC 2308 suggests that the SOA Minimum value (aka the negative caching TTL) should be at least 1 hour and no longer than 3 hours. Common nameserver implementations usually enforce their own negative caching limits of 3 hours or less. The following table shows the distribution of Minimum values:

1h to 3h148,95614.40%

Matching of serial numbers

Not-matching serial numbers on different authoritative servers for a zone indicate a configuration problem.

Note that this only includes zones that responded with at least one valid SOA record.

© 2016 The Measurement Factory.