surveys

DNS SURVEY: OCTOBER 2009

Goals

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,
  • Whether recursive name servers use predictable ports,
  • 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, DKIM, or DNSSEC.

Datasets

Dataset I — Random IP Addresses

For this Dataset, we probed a random sample of all IPv4 addresses routed on the Internet. We began with an October 2009 snapshot of the global routing table taken from the Route Views project with a total of 2,113,234,810 routed IPv4 addresses. We then eliminated subnets associated with the .mil and .gov domains as well as a few subnets where the operators had previously asked us to be excluded from scans, and then randomly selected 5% of the remaining IP addresses for our survey, leaving us with 94,366,052 addresses to probe.

Dataset II — Second-Level Zones in .com /.net /.org

This Dataset contains name servers authoritative for a registered .com, .net, or .org 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 randomly discovered name servers. Furthermore, this Dataset is used to characterize the adoption of new technologies in the DNS, namely IPv6, DNSSEC, DKIM, and SPF. We obtained zone files from VeriSign and Public Interest Registry (PIR) for .com, .net, and .org containing 82 million, 12.4 million, and 7.8 million domains respectively, and randomly selected 3,308,662 domains to probe.

Results for Dataset I

Number of Name Servers

We sent a simple DNS query to each probe address in the two data sets., which asks for the IPv4 address of a.root-servers.net, 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 94,366,052
Hosts replying 748,378 0.79%

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. 21,996 (2.9%) of replying hosts were ones which we never sent a query to. 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 16,300,000 name servers running on the Internet. Some fraction of these servers can be expected to be part of malware activities as shown by Dagon et al.

Two notable anomalies:

  1. Around 4.4% of all IP addresses in French address blocks replied to probes, more than five times as many as responded on average to all probes globally. This is due what appears to be the the broad deployment of totd ("Trick or Treat Daemon") in France Telecom's network. totd is a DNS proxy that forwards queries from pure IPv6 networks. Over 99.9% of all hosts running totd in France and nearly 92% of all hosts running totd anywhere were in AS 3215, France Telecom's primary AS.

  2. Around 6% of all IP addresses in Spanish address blocks replied to probes, nearly seven times as many as responded on average to all probes globally. This is due what appears to be the the broad deployment of Nominum CNS in Telefonica's network.

Software Versions

For each name server 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 if and only if 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 name server software and versions.

Server software Dataset I Dataset II
BIND 252,186 33.70% 185,173 73.85%
4.9.3-4.9.11 308 0.04% 90 0.04%
8.1-REL — 8.2.1 1,117 0.14% 362 0.14%
8.2.2-P3 — 8.3.0-T2A 241 0.03% 266 0.11%
8.3.0-RC1 — 8.4.7-P1 5,545 0.74% 4,165 1.66%
9.0.0b5 — 9.0.1 1,113 0.14% 9 < 0.01%
9.1.0 — 9.2.0rc3 2,980 0.39% 179 0.07%
9.2.0a1 — 9.2.2-P3 5,514 0.74% 6,504 2.59%
9.2.3rc1 — 9.7.0b1 235,358 31.44% 173,590 69.23%
9.2.[3-8] 23,220 3.10% 38,225 15.25%
9.3.* 57,280 7.65% 70,581 28.15%
9.4.* 37,204 4.97% 15,834 6.32%
9.5.* 15,434 2.06% 8,697 3.47%
9.6.* 9,447 1.26% 2,616 1.04%
9.7.* 350 0.05% 603 0.24%
unknown 142,935 19.09% 37,034 14.77%
Nominum CNS 89,096 11.91% 15 0.01%
Vermicelli totd 79,240 10.59% 32 0.01%
Mikrotik DSL/cable 10,515 1.41% 5 < 0.01%
VeriSign ATLAS 5,785 0.77% 14 0.01%
robtex Viking DNS module 3,635 0.49% 18 0.01%
ATOS Stargate ADSL 3,169 0.42% 0 0%
Microsoft Windows DNS 2000 2,099 0.28% 240 0.10%
Raiden DNSD 1,666 0.22% 4 < 0.01%
bboy.net MyDNS 1,457 0.19% 1,854 0.74%
Alteon ACEswitch 1,021 0.14% 0 0%
Microsoft Windows DNS 2003 559 0.07% 314 0.13%
Cisco CNR 524 0.07% 13 0.01%
JHSOFT simple DNS plus 464 0.06% 2,242 0.89%
DJ Bernstein TinyDNS 340 0.05% 6,428 2.56%
PowerDNS 301 0.04% 1,672 0.66%
Paul Rombouts pdnsd 241 0.03% 2 < 0.01%
SheerDNS 236 0.03% 2,201 0.88%
Axis video server 220 0.03% 2 < 0.01%
Runtop DSL/cable 198 0.03% 14 0.01%
Microsoft Windows DNS NT4 181 0.02% 71 0.03%
Max Feoktistov small HTTP server 174 0.02% 0 0%
NLnetLabs NSD 121 0.01% 67 0.03%
Nortel Networks Instant Internet 99 0.01% 0 0%
Netopia DSL/cable 81 0.01% 0 0%
Michael Tokarev rbldnsd 59 0.01% 0 0%
Ascenvision SwiftDNS 57 0.01% 4 < 0.01%
UltraDNS 52 0.01% 69 0.03%
Nominum ANS 38 0.01% 191 0.08%
Beehive CoDoNS 38 0.01% 0 0%
Miscellaneous 257 0.03% 170 0.07%
Other 294,265 39.33% 49,895 19.90%
No match found 217,520 29.07% 12,539 5.00%
Timeout 76,708 10.25% 37,356 14.90%
No result 37 < 0.01% 0 0%

Note that the remarkable showing of Vermicelli totd is due to its broad deployment in France Telecom's network infrastructure. Similarly, the high ranking of Nominum CNS has a lot to do with its significant deployment in Telefonica's network infrastructure. In the the latter case, the results may be due to a quantity of transparent proxies in front of a smaller number of Nominum CNS resolvers.

Open Resolvers

To test for open recursors we send a unique query for a name in a zone that we control to each name server. If we receive a valid response to this query, we say that the target is an open resolver. In fact, many of the devices we probe might not be resolvers in the strict sense. They might simply be forwarders.

We found 596,025 (79.6%) of the name servers in Dataset I support recursion. Another 12,974 (1.7%) forwarded a query to our authoritative server, but didn't return the response back to us. Extrapolating to the entire address space, we estimate that there are as many as 13,200,000 open resolvers on the Internet, and another 288,000 name servers that send queries to authoritative name servers when presented with a recursive query.

Dataset I Nameservers
Open? Count Percent
YES 608,999 81.4%
NO 139,379 18.6%

The total number of Open resolvers on the Internet seems to be going down over time, but is still quite high. We urge developers and manufacturers to read and implement RFC 5625 - DNS Proxy Implementation Guidelines. Users and administrators should read and implement RFC 5358 - Preventing Use of Recursive Nameservers in Reflector Attacks.

In Dataset II we find that 7.1% of zones have at least one authoritative nameserver that is also an open resolver.

Dataset II Zones Nameservers
Open? Count Percent Count Percent
YES 213,676 7.1% 93,304 24.2%
NO 2,789,674 92.9% 292,802 75.8%

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

Server software Dataset I Dataset II
BIND 9 161,632 27.12% 48,900 68.40%
Nominum CNS 81,553 13.68% 14 0.02%
Vermicelli totd 77,528 13.01% 0 0%
Mikrotik DSL/cable 10,072 1.69% 5 0.01%
VeriSign ATLAS 5,765 0.97% 2 < 0.01%
BIND 8 3,589 0.60% 984 1.38%
robtex Viking DNS module 3,465 0.58% 17 0.02%
Microsoft Windows DNS 2000 1,820 0.31% 174 0.03%
Raiden DNSD 1,642 0.28% 4 0.01%
ATOS Stargate ADSL 1,250 0.21% 0 0%
Cisco CNR 486 0.08% 4 0.01%
Microsoft Windows DNS 2003 478 0.08% 209 0.29%
JHSOFT simple DNS plus 273 0.05% 863 1.21%
Paul Rombouts pdnsd 225 0.04% 2 < 0.01%
Microsoft Windows DNS NT4 156 0.03% 57 0.08%
BIND 4 156 0.03% 40 0.06%
Runtop DSL/cable 137 0.02% 6 0.01%
DJ Bernstein TinyDNS 125 0.02% 1 < 0.01%
Nortel Networks Instant Internet 96 0.02% 0 0%
PowerDNS 80 0.01% 223 0.31%
Miscellaneous 319 0.05% 38 0.05%
Other 245,178 41.14% 19,940 27.89%
Timeout 43,070 7.23% 16,189 22.64%
No match found 202,108 33.91% 3,751 5.25%

Source port randomization

Caching resolvers that send queries from predictable source ports are vulnerable to cache poisoning attacks. We examined the source port characteristics of the open resolvers we found in the course of this survey. The results are summarized in the table below.

Note that servers that were not open resolvers were not amenable to active testing.

Randomization Dataset I Dataset II
Poor 42,85710.16% 23,87234.14%
Same port 32,6167.73% 21,55430.83%
Monotonically increasing 4250.10% 4130.59%
Monotonically decreasing 00% 3< 0.01%
Alternating 8460.20% 3890.56%
Cycling 720.02% 170.02%
Limited range 8,8982.11% 1,4962.14%
No obvious pattern 379,15189.84% 46,04365.86%

The following table shows the distribution of server version with poor source port randomization:

Server software Dataset I Dataset II
BIND 20,899 48.76% 19,176 80.33%
Nominum CNS 5,538 12.92% 5 0.02%
Mikrotik DSL/cable 1,426 3.33% 0 0%
BIND 8 468 1.09% 324 1.36%
Vermicelli totd 604 1.41% 0 0%
ATOS Stargate ADSL 427 1.00% 0 0%
Microsoft Windows DNS 2000 422 0.98% 40 0.17%
Microsoft Windows DNS 2003 142 0.33% 120 0.50%
Microsoft Windows NT4 117 0.27% 41 0.17%
JHSOFT simple DNS plus 116 0.27% 524 2.20%
robtex Viking DNS module 71 0.17% 9 0.04%
DJ Bernstein TinyDNS 55 0.13% 0 0%
Paul Rombouts pdnsd 50 0.12% 0 0%
Raiden DNSD 25 0.06% 0 0%
PowerDNS 17 0.04% 16 0.07%
Miscellaneous 53 0.12% 16 0.08%
Other 12,427 29.00% 3,549 14.87%
No match found 1,398 3.26% 1,143 4.79%
Timeout 11,029 25.73% 2,406 10.08%
Total servers 42,857 23,872

Results for Dataset II — Authoritative Name Servers

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 initiating an AXFR request. If the transfer fails or times out, we interpret this as AXFR being not supported. We find that out of 3,003,350 zones, 473,660 (15.8%) have at least one name server that supports AXFR.

Zones Nameservers
AXFR? Count Percent Count Percent
YES 473,660 15.8% 124,840 32.3%
NO 2,529,690 84.2% 261,266 67.7%

TCP Support?

Related to this measurement is the number of nameservers that allow TCP transactions at all. We test for TCP support by setting the `usevc' option to Net::DNS::Resolver and then making an SOA query for the zone. We say the nameserver supports TCP if it returns at least one answer RR. Each nameserver is tested only once. The following table summarizes the results.

Zones Nameservers
TCP? Count Percent Count Percent
YES 2,450,483 81.6% 293,190 75.9%
NO 552,867 18.4% 92,916 24.1%

IPv6

In this part of the survey we are interested in how many zones have at least one name server with an IPv6 address. VeriSign began began accepting AAAA glue records for publication in the .com and .net zones in 2002, and PIR began accepting them for the .org zone last year. However, domain name registrars have been slow to extend their systems to accommodate these records. (One of the largest registrars will do so via email only.) Consequently, this statistic may not be a good overall indicator of the deployment of IPv6 in the global DNS.

Zones with IPv6 RRs
TLD Count Percent
.com 17,263 0.6%
.net 3,057 0.8%
.org 2,084 0.8%
Total 22,404 0.7%

DNSSEC

2009 has been a significant year for DNSSEC. In March, the General Services Administration began signing the .gov TLD, and in June, PIR began signing the .org zone. In October, VeriSign announced that DNSSEC would be fully deployed in the root zone by July, 2010. In spite of this progress, few of the TLDs that have begun DNSSEC operations have begun to accept DS resource records from registrants, and only a handful of resolvers worldwide are configured to perform DNSSEC validation. Consequently, DNSSEC deployment is still extremely limited.

In contrast to previous years, we checked for DNSKEY, NSEC, and RRSIG (and NSEC3PARAM) resource records only. We did not check for the obsolete KEY, SIG, and NXT records, which are now practically extinct.

In Dataset II, we found 167 zones with DNSSEC records. This is a significant increase over last year's count of 45, but still represents an infinitesimal presence. DNSSEC deployment will likely gain momentum next year when the root is signed and more TLDs begin accepting and publishing DS resource records; however, real gains may not be seen until VeriSign fully deploys DNSSEC in the .com and .net zones, which is expected sometime in 2011.

KSKs

The following table shows the distribution of the number of key signing keys (KSKs) found for each zone.

Count Percent
No KSK (ZSKs only) 9 5.4%
One KSK 158 94.6%

ZSKs

The following table shows the distribution of the number of zone signing keys (ZSKs) found for each zone.

Count Percent
One ZSK 92 55.1%
Two ZSKs 75 44.9%

RRSIG chains

The following table shows the distribution of the number of RRSIG chains found for each zone.

Count Percent
No RRSIG chains (unsigned) 6 3.6%
One RRSIG chain 161 96.4%

Signature Validity Periods

The following table shows the distribution of the signature validity periods found for each zone.

Validity Period (days) Count Percent
8.04 1 0.6%
10 5 3.0%
24.32 1 0.6%
29.95 1 0.6%
29.96 1 0.6%
29.98 1 0.6%
30 74 44.3%
30.04 4 2.4%
31 64 38.32%
45.04 1 0.6%
63 1 0.6%
75.06 1 0.6%
90 5 3.0%

KSK Characteristics

The following tables shows the distribution of KSK algorithms, key sizes, and exponent sizes.

Algorithm Count Percent
RSA/MD5 1 0.6%
DSA/SHA1 5 3.2%
RSA/SHA1 146 92.4%
RSASHA1-NSEC3-SHA1 6 3.8%
Key Size (octets) Count Percent
64 3 1.9%
128 47 29.7%
160 2 1.3%
163 8 5.1%
256 80 50.6%
304 5 3.2%
512 13 8.2%
Exponent Size (octets) Count Percent
1 3 1.9%
3 139 88.0%
4 9 5.7%
5 7 4.4%

ZSK Characteristics

The following tables shows the distribution of ZSK algorithms, key sizes, and exponent sizes.

Algorithm Count Percent
RSA/MD5 2 0.8%
DSA/SHA1 6 2.5%
RSA/SHA1 228 94.2%
RSASHA1-NSEC3-SHA1 6 2.5%
Key Size (octets) Count Percent
64 13 5.4%
96 1 0.04%
128 204 84.3%
163 3 1.2%
256 10 4.1%
304 5 2.1%
396 1 0.4%
512 5 2.1%
Exponent Size (octets) Count Percent
1 4 1.7%
3 214 88.4%
4 14 5.8%
5 9 3.7%
8 1 0.4%

NSEC3

The following table shows the number of zones using NSEC compared with the number using NSEC3.

Count Percent
NSEC 162 97.0%
NSEC3 5 3.0%

EDNS

We tested name servers in both data sets for EDNS support. EDNS support is a prerequisite for DNSSEC, as replies containing DNSSEC metatdata can easily exceed the traditional DNS message size of 512 octets. In order to properly support DNSSEC, a name server must not only have EDNS0 enabled, but it must have a payload size of at least 1,220 octets.

EDNS support — Dataset I
Payload Size Count Percent
512 1,273 0.17%
800 2 < 0.01%
1000 1 < 0.01%
1024 16 < 0.01%
1200 10 < 0.01%
1252 4 < 0.01%
1280 23,183 3.10%
1300 1 < 0.01%
1420 1 < 0.01%
1460 44 0.01%
1500 1 < 0.01%
2048 2 < 0.01%
4000 92,179 12.32%
4096 35,4281 47.34%
22,528 26 < 0.01%
unsupported 80,699 10.78%
no answer 196,654 26.28%
EDNS support — Dataset II
Payload Size Count Percent
1 1 < 0.01%
512 220 0.09%
800 2 < 0.01%
1024 15 0.01%
1200 1 < 0.01%
1252 7 < 0.01%
1280 26,822 10.70%
1300 3 < 0.01%
1400 4 < 0.01%
1420 1 < 0.01%
1460 33 0.01%
1472 4 < 0.01%
1500 7 < 0.01%
2048 5 < 0.01%
2944 2 < 0.01%
4000 93 0.04%
4096 187,182 74.66%
22,528 36 0.01%
unsupported 13,461 5.37%
no answer 22,830 9.11%

SPF and Sender ID

Sender Policy Framework (SPF) and Sender ID are anti-forgery techniques by which organizations can list valid sources of email (i.e., IP addresses) from their domain. They are described in RFC 4408 and RFC 4406. To enable SPF authorization, an organization publishes an SPF record in their zone, either as an SPF (Type 99) resource record or as a TXT record. Mail transfer agents may then lookup SPF information when receiving email messages. Sender ID is similar but, unlike SPF, has no assigned resource record type.

Within Dataset II, we found the following zones with SPF or Sender ID records:

Zones Count Percent
With SPF records (total) 403,228 12.2%
TXT RRs 395,338 12.0%
SPF RRs 7,890 0.2%
With Sender ID records 2,011 0.1%

DKIM

DKIM is an anti-forgery technique by which organizations can sign mail to be validated against public keys published in their zone. It is described in RFC 4871 To enable DKIM validation, and organization publishes one or more DKIM records as TXT records under the sub-domain _domainkey in their zone, e.g., key1._domainkey.example.com. Unlike SPF and Sender ID, DKIM records cannot be looked up directly without knowing or attempting to guess the key names; however, the presence of the sub-domain _domainkey suggests that DKIM is configured.

Zones Count Percent
With DKIM records 61,652 1.86%

Are a zone's name servers 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 topological aspects of a zone's name servers. Our assumption that topological 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 name servers within the given CIDR-sized subnets:

CIDR Mask Percentage Cumulative
323.1%3.1%
316.8%9.9%
302.3%12.2%
293.2%15.4%
281.1%16.5%
271.4%18.0%
260.5%18.5%
250.9%19.4%
240.5%19.8%
233.2%23.1%
223.0%26.0%
210.7%26.8%
201.6%28.4%
190.6%29.0%
181.6%30.6%
170.4%31.0%
160.1%31.1%

BGP routing interruptions, while infrequent, may be one of the more common reasons for transient unreachability between two hosts. To ensure maximum reachability, a zone's servers should be split across at least two autonomous systems. The following table shows the percentage of zones having all their authoritative name servers within the given number of autonomous systems:

Number of ASes Count Percent
12,238,78673.86%
2688,76622.72%
371,1202.35%
42,6000.09%
520,3040.67%
62840.01%
71750.01%
86< 0.01%
912< 0.01%
unknown9,0960.30%

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 name servers (learned from the parent zone) did not return any NS records for the zone

Match 1,682,771 50.9%
Mismatch 261,292 7.9%
No authoritative name server 1,365,084 41.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 name servers return NS records with mismatched TTLs. This includes all NS records from all name servers for a zone. The first column is the number of unique TTLs returned:

Same for all NS 1,935,120 99.7%
Different 5,702 0.3%

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.

Refresh

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 63,886 2.2%
20m to 12h 2,393,112 83.3%
> 12h 417,841 14.5%

Retry

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 <= refresh 2,834,229 98.6%
retry > refresh 39,326 1.4%

Expire

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

< 2 weeks 2,166,881 75.4%
2 to 4 weeks 284,847 9.9%
> 4 weeks 423,533 14.7%

Minimum

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

< 1 hour 500,731 17.4%
1 to 3 hours 630,109 21.9%
> 3 hours 1,745,513 60.7%

Matching of serial numbers

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

Same 2,822,484 98.2%
Different 50,743 1.8%

Note that these results include only zones that responded with at least one valid SOA record.

How many zones have a lame server?

We test for lameness by sending an SOA query for a zone to an authoritative name server. If the response's RCODE is anything other than zero, we say the name server is lame. Here are the results:

Not Lame 2,840,548 85.9%
Lame 468,114 14.1%

Note this only includes name servers for which we have an IP address. If a zone has three name servers and we have can't get an IP address for one name server, the zone is included in the analysis with the two good name servers. In other words, an unresolvable name server is not counted as a lame server.

Geographic Location

This is the distribution of top 60 countries with responding name servers from Dataset I. Note that the remarkable showing of France in Dataset I is due to the broad deployment of Vermicelli totd in France Telecom's network infrastructure. Similarly, the high ranking of Spain is attributable to the apparent broad deployment of Nominum CNS in Telefonica's network infrastructure. The deployment of consumer broadband routers with DNS proxies may explain the high rank of some other countries in this set.

Dataset I Nameservers
Location Count Percent
United States 96,897 12.95%
France 93,562 12.50%
China 85,596 11.44%
Spain 68,816 9.20%
South Korea 62,717 8.38%
Japan 22,896 3.06%
Italy 20,620 2.76%
Turkey 19,504 2.61%
Brazil 19,416 2.59%
Netherlands 18,042 2.41%
United Kingdom 17,683 2.36%
Germany 17,219 2.30%
Czech Republic 13,859 1.85%
Denmark 13,761 1.84%
Russian Federation 13,167 1.76%
Taiwan 10,241 1.37%
Sweden 9,903 1.32%
Argentina 9,246 1.24%
Peru 8,302 1.11%
Canada 6,929 0.93%
Thailand 6,867 0.92%
Australia 6,817 0.91%
Chile 6,745 0.90%
Poland 6,686 0.89%
Switzerland 6,528 0.87%
India 5,270 0.70%
Vietnam 4,398 0.59%
Malaysia 3,926 0.52%
Ukraine 3,818 0.51%
Norway 3,543 0.47%
Bulgaria 3,236 0.43%
Romania 3,072 0.41%
Belgium 2,978 0.40%
Hungary 2,902 0.39%
Hong Kong 2,678 0.36%
Austria 2,436 0.33%
Portugal 2,414 0.32%
Costa Rica 2,374 0.32%
South Africa 2,364 0.32%
Colombia 2,245 0.30%
Finland 2,061 0.28%
Philippines 1,987 0.27%
Indonesia 1,951 0.26%
New Zealand 1,773 0.24%
Egypt 1,519 0.20%
United Arab Emirates 1,333 0.18%
Saudi Arabia 1,298 0.17%
Greece 1,220 0.16%
Pakistan 1,160 0.16%
Slovakia 1,118 0.15%
Georgia 1,045 0.14%
Israel 903 0.12%
Ireland 902 0.12%
Singapore 897 0.12%
Oman 858 0.11%
Reunion 829 0.11%
Mexico 810 0.11%
Bahrain 783 0.10%
Latvia 693 0.09%
Serbia 686 0.09%

This is the distribution of top 60 countries with responding name servers from Dataset II.

Dataset II Nameservers
Location Count Percent
United States 144,304 55.97%
United Kingdom 12,692 4.92%
Canada 10,662 4.14%
Germany 10,125 3.93%
France 7,402 2.87%
Netherlands 7,284 2.83%
Japan 6,352 2.46%
Spain 6,138 2.38%
Turkey 5,837 2.26%
Australia 3,889 1.51%
Italy 3,644 1.41%
South Korea 3,402 1.32%
Russian Federation 2,274 0.88%
China 2,088 0.81%
Thailand 1,782 0.69%
Sweden 1,774 0.69%
Switzerland 1,657 0.64%
Hong Kong 1,604 0.62%
Brazil 1,444 0.56%
Poland 1,361 0.53%
Argentina 1,079 0.42%
Austria 1,049 0.41%
Belgium 1,037 0.40%
Czech Republic 991 0.38%
Malaysia 980 0.38%
Taiwan 893 0.35%
Ukraine 883 0.34%
Hungary 838 0.33%
Singapore 826 0.32%
Finland 818 0.32%
Bulgaria 803 0.31%
Portugal 781 0.30%
Romania 713 0.28%
Norway 640 0.25%
Israel 638 0.25%
Indonesia 637 0.25%
Denmark 624 0.24%
India 511 0.20%
New Zealand 454 0.18%
Slovenia 431 0.17%
South Africa 392 0.15%
Vietnam 362 0.14%
Ireland 358 0.14%
Mexico 354 0.14%
Greece 284 0.11%
Chile 276 0.11%
Iran 224 0.09%
Slovakia 207 0.08%
Colombia 185 0.07%
Luxembourg 168 0.07%
Panama 165 0.06%
Serbia 163 0.06%
Latvia 160 0.06%
Estonia 153 0.06%
Philippines 135 0.05%
Lithuania 134 0.05%
Venezuela 121 0.05%
Costa Rica 115 0.04%
Iceland 114 0.04%
Croatia 112 0.04%

Notes

Name Servers Density

Note that some name servers are authoritative for many different zones. This may affect certain measurements, such as the topological dispersion. For example, if a company with many zones happens to have all its name servers on the same subnet, that may artificially inflate the percentages in the "Are zone's name servers topologically dispersed?" section.

To get an idea of the how many zones each name server hosts, note that the mean number of zones per name server is 47.5 while the median is 2.0. The following table shows how many zones each of the top 25 name servers are authoritative for:

Name Server Rank Zone Count CDF
1 534,250 4.50%
2 534,005 9.00%
3 525,905 13.44%
4 525,280 17.86%
5 523,525 22.27%
6 193,732 23.91%
7 193,692 25.54%
8 67,170 26.11%
9 66,772 26.67%
10 64,893 27.22%
11 64,813 27.76%
12 63,872 28.30%
13 63,835 28.84%
14 58,408 29.33%
15 53,323 29.78%
16 53,314 30.23%
17 51,960 30.67%
18 51,955 31.10%
19 51,940 31.54%
20 51,920 31.98%
21 51,918 32.42%
22 51,910 32.86%
23 51,690 33.29%
24 51,132 33.72%
25 51,065 34.15%
$Id: 200910.html,v 1.5 2009/12/30 21:18:34 wessels Exp $

© 2017 The Measurement Factory.