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 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.
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.
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. 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.
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|
|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%|
|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%|
|JHSOFT simple DNS plus||572||0.09%||13,523||1.28%|
|Microsoft Windows DNS 2003||530||0.09%||1,082||0.10%|
|Axis video server||289||0.05%||0||0%|
|Microsoft Windows DNS 2000||234||0.04%||551||0.05%|
|Microsoft Windows DNS NT4||218||0.04%||825||0.08%|
|No match found||122,155||19.76%||131,746||12.48%|
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|
|DJ Bernstein TinyDNS||379||0.81%||6,066||1.38%|
|JHSOFT simple DNS plus||89||0.19%||5,486||1.25%|
|No match found||3,263||7.00%||73,533||16.74%|
|Dataset I||Dataset II|
|Server sofware||Dataset I||Dataset II|
|JHSOFT simple DNS plus||446||0.65%||4,644||5.36%|
|Microsoft Windows DNS 2003||176||0.26%||549||0.63%|
|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%|
|No match found||12,039||17.64%||1,651||1.91%|
We test for zone transfer by invoking the dig command with the parameters
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.
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:
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 nameserver||378,260||36.2%|
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 NS||1,009,572||96.4%|
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||899,308||86.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 <= refresh||1,005,159||97.0%|
|retry > refresh||31,402||3.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 4w||167,075||16.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 3h||148,956||14.40%|
Note that this only includes zones that responded with at least one valid SOA record.
© 2020 The Measurement Factory.