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:
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.
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.
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:
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:
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.
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.
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|
|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%|
|Mikrotik DSL/cable||10,515||1.41%||5||< 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%|
|Microsoft Windows DNS 2003||559||0.07%||314||0.13%|
|JHSOFT simple DNS plus||464||0.06%||2,242||0.89%|
|DJ Bernstein TinyDNS||340||0.05%||6,428||2.56%|
|Paul Rombouts pdnsd||241||0.03%||2||< 0.01%|
|Axis video server||220||0.03%||2||< 0.01%|
|Microsoft Windows DNS NT4||181||0.02%||71||0.03%|
|Max Feoktistov small HTTP server||174||0.02%||0||0%|
|Nortel Networks Instant Internet||99||0.01%||0||0%|
|Michael Tokarev rbldnsd||59||0.01%||0||0%|
|Ascenvision SwiftDNS||57||0.01%||4||< 0.01%|
|No match found||217,520||29.07%||12,539||5.00%|
|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.
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.
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.
The following table shows the software running on open resolvers that respond to recursive queries.
|Server software||Dataset I||Dataset II|
|VeriSign ATLAS||5,765||0.97%||2||< 0.01%|
|robtex Viking DNS module||3,465||0.58%||17||0.02%|
|Microsoft Windows DNS 2000||1,820||0.31%||174||0.03%|
|ATOS Stargate ADSL||1,250||0.21%||0||0%|
|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%|
|DJ Bernstein TinyDNS||125||0.02%||1||< 0.01%|
|Nortel Networks Instant Internet||96||0.02%||0||0%|
|No match found||202,108||33.91%||3,751||5.25%|
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|
|Monotonically decreasing||0||0%||3||< 0.01%|
|No obvious pattern||379,151||89.84%||46,043||65.86%|
The following table shows the distribution of server version with poor source port randomization:
|Server software||Dataset I||Dataset II|
|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%|
|No match found||1,398||3.26%||1,143||4.79%|
The following tests are particular to the second data set since they require knowledge of a zone for which a server is authoritative.
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.
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.
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|
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.
The following table shows the distribution of the number of key signing keys (KSKs) found for each zone.
|No KSK (ZSKs only)||9||5.4%|
The following table shows the distribution of the number of zone signing keys (ZSKs) found for each zone.
The following table shows the distribution of the number of RRSIG chains found for each zone.
|No RRSIG chains (unsigned)||6||3.6%|
|One RRSIG chain||161||96.4%|
The following table shows the distribution of the signature validity periods found for each zone.
|Validity Period (days)||Count||Percent|
The following tables shows the distribution of KSK algorithms, key sizes, and exponent sizes.
|Key Size (octets)||Count||Percent|
|Exponent Size (octets)||Count||Percent|
The following tables shows the distribution of ZSK algorithms, key sizes, and exponent sizes.
|Key Size (octets)||Count||Percent|
|Exponent Size (octets)||Count||Percent|
The following table shows the number of zones using NSEC compared with the number using NSEC3.
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|
|EDNS support — Dataset II|
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:
|With SPF records (total)||403,228||12.2%|
|With Sender ID records||2,011||0.1%|
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.
|With DKIM records||61,652||1.86%|
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:
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|
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
|No authoritative name server||1,365,084||41.2%|
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%|
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 12h||2,393,112||83.3%|
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%|
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%|
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%|
Not-matching serial numbers on different authoritative servers for a zone may indicate a configuration problem.
Note that these results include only zones that responded with at least one valid SOA record.
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:
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.
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.
|United Arab Emirates||1,333||0.18%|
This is the distribution of top 60 countries with responding name servers from Dataset II.
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|
$Id: 200910.html,v 1.5 2009/12/30 21:18:34 wessels Exp $
© 2017 The Measurement Factory.