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:

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.

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.

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.

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.

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

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.

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.

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.

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.

ZSKs

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

RRSIG chains

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

Signature Validity Periods

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

KSK Characteristics

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

ZSK Characteristics

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

NSEC3

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

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.

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:

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.

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:

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:

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

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:

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:

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:

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:

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:

Matching of serial numbers

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.

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:

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.

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

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:

$Id: 200910.html,v 1.5 2009/12/30 21:18:34 wessels Exp $