The ISP Column
A column on all things Internet
Other Formats: PDF   TXT  

Recounting DNSSEC
October 2012

Geoff Huston
George Michaelson

This is a followup article to Counting DNSSEC that reflects some further examination of the collected data. This time I'd like to describe some additional thoughts about the experiment, and some revised results in our efforts to count just how much DNSSEC is being used out there.

And for those looking for just the answers, here's a quick summary of the recount. It appears that as of September 2012 when this experiment was performed some 1.7% of the visible DNS resolvers in the Internet are performing DNSSEC validation, and some 1.6% of all end client systems are exclusively using DNSSEC validating resolvers.

And now the details…

The Experiment

Firstly, I should briefly recap on the experiment itself. We used an online advertisement delivery system as a means of enrolling end user systems to perform a simple DNSSEC capability experiment. Many online advertisement systems support dynamic content, and in this Adobe Flash was used with the code configured to perform the necessary dynamic support for the measurement exercise. We configured the ad to generate two unique URLs for the user's browser to fetch. The URLs are of the form:

The 's' and 'u' fields are dynamically generated, and the combination is unique for each user that is presented with an impression of the ad. This means that every client will generate a query for resolution of a unique DNS name, so that any caching of the outcome of the DNS query for one instance of this experiment will not be used by any other instance of this experiment, even if the users share the same DNS resolver. This form of dynamic DNS label generation also eliminates any URL object caching.

In this experiment we have used two subdomains, both of which are DNSSEC signed, and each zone consists of a single wildcard. The only difference between the two subdomains lies in the DNSSEC configuration. In the case of one subdomain ( the DS records are correctly configured in the zone, while in the case of the other subdomain ( the DS records are deliberately altered. The intended consequence is that DNSSEC validation of domain names in will succeed, while DNSSEC validation in the other subdomain,, will fail.

The experiment script includes a 10 second timer. At the expiration of this timer the client will perform a GET where the parameters to the GET record the locally measured status of the fetches of the above two URLs. This result GET is directed to a URL whose DNS name part is not DNSSEC-signed.

DNSSEC use from the Logs

The experiment was in operation for 17 days, from the 10th of September 2012 until the 27th of September 2012:

      Advertisement Placement Report:4,965,129
      DNS Query Log: Unique Identifiers:3,816,822
      Web Query Logs: Unique Identifiers:2,831,780

The difference between the advertisement placement report and the DNS query log indicates that some 23% of the ads were aborted before the control script had a chance to execute the first DNS query for the experiment. Some 985,042 experiments (or 26% of the DNS-active experiments) were started, but terminated before any web fetches were executed by the client (the difference between the DNS query log total and the Web query log total). In total some 57% of the placed advertisements produced results that were recorded in the web logs.

A further 1,244,299 experiments, or 44% of all the experiments that contacted the web server, did not complete the experiment and did not download the result URL after 10 seconds, or did not download either of the test URLs within the 10 second wait period before downloading the result URL. Both of these are attributable to the user terminating the advertisement before the download of the test URLs had completed.

This left 1,587,481 experiments that downloaded at least one of the test URLs and communicated their results back to the server on the expiration of the 10 second timer. The * is called here "Valid", and the * is termed "Invalid". The breakdown of the combination of fetches of these two objects is as follows:

      Web Queries:  Valid AND Invalid  1,438,291  90%
   Valid and NOT Invalid90,1386%
   NOT Valid and Invalid59,0524%

There were 1,438,291 experiments that download both the DNSSEC-valid and invalid URLs, or 90% of the completed experiments. Some 90,138 experiments, or 6% of the total set of completed experiments that loaded the DNSSEC-Valid URL and did not download the DNSSEC-invalid URL. However, there were a further 59,052 experiments, or 4% of the total set, that behaved contrary to DNSSEC, downloading the DNSSEC-invalid URL, but not downloading the DNSSEC-valid URL.

This data points to some considerable level of variability in browser behavior. All these experiments reported back after 10 seconds as to their status, but it appears that some clients (at least 4%) are taking longer than 10 seconds to complete the 2 download tasks, and the experiment was terminated by the user prior to the completion of the experiment. If the number of incomplete experiments is equally distributed between the two cases of retrieving one but not the other URL, then it appears to indicate that some 2% of experiments did not download the DNSSEC-invalid URL because of the negative DNSSEC-validation outcome, while the other 4% did not perform the download because the experiment did not run to completion. However, this does not appear to be a very satisfactory form of analysis for the numbers, and the 2% outcome of DNSSEC-validating users appears to be a highly approximate calculation.

Is there a way to interpret the log files to provide a better estimate of DNSSEC use in the Internet?

Resolvers and DNSSEC Validation

A more methodical approach is to work through the DNS logs to see if we can assemble the set of DNSSEC-validating resolvers, then compare this proposed set to the web logs to see if the web logs contradict the tentative results from the DNS log analysis.

So the first question is: How can we tell if a DNS resolver is performing DNSSEC validation?

This is an example of the log from the local DNS authoritative name server when a DNSSEC-validating resolver generates queries for the experiment

    15:50:27.130 queries: client 68.x.y.z#62436 (
        query: IN A –ED

    15:50:27.327 queries: client 68.x.y.z#45855 ( query: IN DS -ED

    15:50:27.523 queries: client 68.x.y.z#45824 ( query: IN DNSKEY –ED

    15:50:27.720 queries: client 68.x.y.z#47318 ( query: IN DNSKEY -ED

When the client performs the initial A query with the EDNS0 and DO bits set then the response will include the requested A RR, but will also include the RRSIG RRs, or the signature data, and also the relevant NSEC records and their signatures. The client will then attempt to validate these signatures, and to do so it needs the signing key values, or DNSKEY RR values for the domain. To validate this DNSKEY record it will need the DS RRs for the subdomain, obtained from the parent zone. To validate the RRSIG entries that were retrieved in the DS query it will then need the DNSKEY of the parent zone. This will, in turn, require a fetch of the DS RRs from its parent zone, and so on to the root zone.

The inference to be drawn from the logs of this instance of the test is that if a client is using a DNSSEC-validating DNS resolver, then we should see a DNSKEY query from the resolver.

However it is possible for resolvers to be "chained" so that a number of resolvers can lie behind a resolver (as shown in Figure 1). In such a case the "hidden" validating resolver will generate a DNSKEY query, which will be forwarded through a common Non-validating resolver as a distinct query. If we are using a single rule that a visible Validating Resolver generates DNSKEY queries then we will falsely assume that the common non-validating resolver is a DNSSEC-validating resolver. Is there a way to distinguish between these forms of resolver configurations?

Figure 1: DNS resolver chaining

The first approach to perform this differentiation of resolver types is to look at the time difference between the first query seen from a resolver and the first DNSKEY query. If the resolver that is querying the authoritative nameservers is itself a DNSSEC-validating resolver then a DNSKEY query will follow the A query "almost immediately", while the non-validating resolver will only pass on the DNSKEY query when a "hidden" DNSSEC-validating resolver performs DNSSEC validation.

The distribution of the elapsed time between the first query seen from each resolver and the DNSKEY query is shown in the following figure. The figure shows a pronounced peak at a delay of 200ms (the x axis uses a logarithmic scale in this figure), and there is a visible waning after 3 seconds.

This allows us to refine our assumptions of how to distinguish between a visible DNSSEC-validating resolver and a non-validating resolver to include the consideration that a DNSSEC validating resolver should query for a DNSKEY RR for the domain within 3 seconds of the first query seen from this resolver.

In this experiment we saw 126,780 resolvers, and while 3,367 resolvers performed DNSKEY queries, only 2,277 performed this query within 3 seconds of the resolver's initial query. It seems reasonable to conclude that the remaining 1,090 visible resolvers are non-DNSSEC validating resolvers that may have DNSSEC-validating resolvers chained behind them in some manner.

Figure 2: Distribution of Elapsed time between initial query and DNSKEY query

There is a second filter we can use as well to apply to this candidate set of DNSSEC-validating resolvers. If we look at the each individual experiment (using the unique id generated for each experiment), the DNS logs will reveal which resolvers were used by the end host to resolve the experiment's domain names into IPv4 addresses. DNSSEC-validating resolvers do not return the requested resource record in the case of DNSSEC validation failure. Instead. they return a SERVFAIL error code.

At this stage we have a set of 2,277 visible resolvers whom we suspect are DNSSEC-validating resolvers. We also have a collection of 1,497,343 experiments where the invalid URL was retrieved by the client. If we filter these experiments, and select only those experiments where the client used a single DNS resolver, and further filter this set to retrieve only those experiments where this client loaded the invalid URL, then we have grounds to believe that this single resolver is not a DNSSEC-validating resolver. Some 154 visible DNS resolvers fall into this category.

We now have 2,123 visible DNS resolvers that appear to be performing DNSSEC validation out of a total of 126,780 visible DNS resolvers, or some 1.6% of all visible resolvers.

The initial estimate of 2,316 DNSSEC-validating resolvers out of a total pool of 57,267, or 4.0% of visible resolvers was somewhat optimistic. A revised estimate is somewhat lower, with 2,123 DNSSEC-validating resolvers seen, from a total pool of 126,780 visible resolvers.

What proportion of DNS resolvers are DNSSEC-capable?

2,123 out of 126,780, or 1.7% of the visible DNS resolvers were observed to perform DNSSEC validation

We can also look at the location of these DNS resolvers in terns of the country in which they are located. The Regional Internet Registries all regularly publish address allocation summary reports that include a mapping of IP address to country code. This allows us to map the IP address of the DNS resolver to a country where the address has been associated from the RIRs' reports. There are a large number of resolvers used by just 1 or 2 client systems, and a smaller number of resolvers used in some form of infrastructure mode where many clients use the same resolver. It appears reasonable to weight each resolver's DNSSEC validating capability by the number of unique clients seen who use that resolver, and use the DNSSC validating resolver weighted count as a percentage of the total weighted resolver draft for each country. From this data we can color a map of the world with the amount of DNSSEC-validating resolvers in each country, as show in Figure 3, below. (The data used to generate this map can be found at The 10 countries with the highest levels of weighted DNSSEC resolvers are shown in Table 1. It should be noted that while the experiment covered some 750,000 individual experiments, the distribution of the clients who executed this test was not uniformly spread across all countries. The level of uncertainty in the per country data varies according to the number of tests that were performed by clients in each of these countries.

6130119414422452931%CZCzech Republic
77102815100392425%ZASouth Africa
12121112034184915%PRPuerto Rico
13428727137380114%NZNew Zealand
1524640380132094014295810%USUnited States of America

Table 1: Ranking of 15 Countries with the highest DNSSEC Resolver capability
(Countries with >= 1000 experiment ids)

Figure 3: Proportion of Resolvers that Perform DNSSEC Validation by country
(weighted by the number of clients who use each resolver)

What about the very largest of these DNS resolvers? The following table lists these largest resolvers and their ability to perform DNSSEC validation. Of the largest 26 individual resolvers we saw in this exercise just 1 set of these resolvers that undertook DNSSEC validation, located in AS7922, and operated by Comcast.

   AS NameCountry
no976241AS4766KIXS-AS-KR Korea TelecomRepublic of Korea
no472735AS15169GOOGLE - Google Inc.USA
no411220AS16880Trend MicroUSA
no330663AS3462HINET Data Communication Business GroupTaiwan
no294053AS3786LGDACOM LG DACOM CorporationRepublic of Korea
no274418AS5384Emirates TelecommunicationsUnited Arab Emirates
no228905AS4134CHINANET-BACKBONE No.31,Jin-rong StreetChina
no194865AS9318HANARO-AS Hanaro Telecom Inc.Republic of Korea
no145429AS4837CHINA169-BACKBONE CNCGROUP China169China
yes140211AS7922Comcast Cable CommunicationsUSA
no120063AS4788TM Net, Internet Service ProviderMalaysia
no113965AS3356LEVEL3 Level 3 CommunicationsUS
no107524AS9050RTD ROMTELECOM S.ARomania
no100527AS45595PKTELECOM-AS-PK Pakistan Telecom CompanyPakistan
no87825AS6799OTENET-GR (Hellenic Telecommunications)Greece
no85917AS17676GIGAINFRA Softbank BB Corp.Japan
no83349AS4713OCN NTT Communications CorporationJapan
no82338AS25019SAUDINETSTC-AS Saudi Arabia
no82146AS8781QA-ISP Qatar Telecom (Qtel) Q.S.C.Qatar
no78339AS9737TOTNET-TH-AS-AP TOT Public Company LimitedThailand
no75510AS9299Philippine Long Distance TelephonePhilippines
no71499AS15557LDCOMNET Societe Francaise RadiotelephoneFrance
no69071AS45758TRIPLETNET-AS-AP TripleT InterneThailand
no67079AS8452TE-AS TE-ASEgypt
no58219AS36692OPENDNS - OpenDNS, LLCUSA

Table 2: Ranking of 26 Largest DNS Resolvers by their DNSSEC Resolver capability

The next table shows the 20 largest DNSSEC-validating resolvers.

   AS NameCountry
yes140211AS7922COMCAST-7922 - Comcast Cable CommunicationUSA
yes11355AS5466EIRCOM Eircom LimitedIreland
yes9327AS3301TELIANET-SWEDEN TeliaSonera ABSweden
yes9005AS22047VTR BANDA ANCHA S.A.Chile
yes7390AS16276OVH OVH SystemsFrance
yes5313AS28573NET Servicos de Comunicao S.A.Brazil
yes4758AS1257TELE2European Union
yes3762AS7657VODAFONE-NZ-NGN-AS Vodafone NZ Ltd.New Zealand
yes3684AS23700BM-AS-ID PT. Broadband Multimedia, TbkIndonesia
yes3649AS5713SAIX-NETSouth Africa
yes3448AS15735DATASTREAM-NET GO p.l.c.Malta
yes3411AS2519VECTANT VECTANT Ltd.Japan
yes3177AS29562KABELBW-ASN Kabel BW GmbHGermany
yes2927AS4134CHINANET-BACKBONE No.31,Jin-rong StreetChina
yes2180AS28725CZ-EUROTEL-AS AS of Eurotel PrahaCzech Republic
yes1897AS39651COMHEM-SWEDEN Com Hem SwedenSweden
yes1849AS11992CENTENNIAL-PR - Centennial de Puerto RicoPuerto Rico
yes1832AS12912ERA Polska Telefonia Cyfrowa S.A.Poland
yes1809AS12301INVITEL Invitel Tavkozlesi Zrt.Hungary

Table 3: Table 3 – Ranking of 20 Largest DNSSEC-Validating Resolvers

The full list of the resolvers' DNSSEC capability, per originating AS number can be found at Of note is the diversity of countries in this list.

Counting Clients

Let's now turn our attention from the resolvers to those clients who use these resolvers, and look at the clients and DNSSEC The web logs allow us to link the resolvers' DNSSEC capability to individual end host systems. This allows us to derive a measurement of the level of coverage of DNSSEC validation capability for end users. In the previous report we took the optimistic view that if any of the resolvers used by a client appeared to perform DNSSEC validation then we were prepared to list the client as performing DNSSEC validation. This resulted in a measurement of 69,560 out of 770,934 experiments, or 9.0% of the clients. We can improve this definition by taking a stricter view, namely what proportion of clients are seen to use only those resolvers that perform DNSSEC-validation. This is similar to the question of what proportion of clients will be unable to load a URL where the DNS label fails DNSSEC validation. As indicated at the start of this article the web logs indicate that some 6% of clients load the DNSSEC-valid URL but do not load the DNSSEC-invalid URL. But, also as noted above, the browser behavior introduces a significant level of uncertainty into these results, and the clients that appear to obey DNSSEC-validation outcomes use a mix of resolvers that both do and do not appear to perform DNSSEC validation.

Perhaps the question can be rephrased differently: What proportion of clients exclusively use DNSSEC-validating resolvers:

What proportion of users are using DNSSEC-validating DNS resolvers?

27,838 out of 1,717,906, or 1.6% of the end host systems were observed to perform DNSSEC validation.

The final query relates to the location of the users. for this experiment we used the mapping of IP address to country codes as published by the RIRs and were able to map users to countries.

Where are these users?

Of the 207 unique country codes that were seen in this experiment, some 105 countries contributed 1000 or more experiments. The 25 countries that contributed 1,000 or more experiments with the highest proportion of DNSSEC use is shown in the following table:

   % DNSSEC-
21.95%5702,597Puerto Rico
21.40%7823,655South Africa
15.75%9,14958,074United States of America
14.74%8585,820Czech Republic
7.07%5698,045New Zealand

Table 5: Ranking of 25 Countries with the highest DNSSEC client use

Once again is it possible to feed this data into a map of the world and paint each country with a color that denotes the level of coverage of DNSSEC. This is shown in Figure 4. (The data used to generate this map can be found at

Figure 4: Proportion of Users that use DNSSEC-Validating Resolvers by country

Rather than by country it is also possible to generate the list of DNSSEC-using clients by originating AS. Using a filter of obtaining a minimum of 50 tested clients per originating AS, we obtain the following table of the 25 AS's that have the highest proportion of DNSSEC-using clients.

      Rank  ASDNSSEC
  AS Name, Country
 1AS4414397.54%119122  VIPMOBILE-AS Vip mobile d.o.o., Serbia
 2AS2783197.26%7173  Colombia Movil, Colombia
 3AS4403497.03%261269  HI3G Hi3G Access AB, Sweden
 4AS2872596.83%6163  CZ-EUROTEL-AS AS of Eurotel Praha, Czech Republic
 5AS1560096.49%5557  FINECOM Finecom Telecommunications AG, Switzerland
 6AS2077696.26%180187  OUTREMER-AS Outremer Telecom, France
 7AS1291294.93%712750  ERA Polska Telefonia Cyfrowa S.A., Poland
 8AS3134394.30%248263  INTERTELECOM Intertelecom Ltd, Ukraine
 9AS2951891.87%113123  BREDBAND2 Bredband2 AB, Sweden
 10AS546690.86%16311795  EIRCOM Eircom Limited, Ireland
 11AS3848490.79%6976  VIRGIN-BROADBAND-AS-AP Virgin Broadband VISP, Australia
 12AS2204788.06%20662346  VTR BANDA ANCHA S.A., Chile
 13AS1199287.83%570649  CENTENNIAL-PR - Centennial de Puerto Rico, Puerto Rico
 14AS373787.74%93106  PTD-AS - PenTeleData Inc., USA
 15AS1771187.40%111127  NDHU-TW National Dong Hwa University, Taiwan
 16AS330186.25%508589  TELIANET-SWEDEN TeliaSonera AB, Sweden
 17AS324585.19%4654  DIGSYS-AS Digital Systems Ltd, Bulgaria
 18AS4183383.78%6274  MOSCANET Moscanet (WISE), Lebanon
 19AS847382.26%102124  BAHNHOF Bahnhof Internet AB, Sweden
 20AS792280.43%885511010  COMCAST-7922 - Comcast Cable Communications, Inc., USA
 21AS470480.27%118147  SANYO Information Technology Solutions Co., Ltd., Japan
 22AS571380.09%744929  SAIX-NET, South Africa
 23AS4174980.00%100125  NETCOMPUTERS-AS Net & Computers SRL, Romania
 24AS2485279.44%85107  VINITA VINITA Internet Services, Lithuania
 25AS125776.16%4095372  TELE2, European Union

Table 5 – Ranking of 25 ASs with the highest DNSSEC client use

The complete set of data of DNSSEC use by hosts per originating AS can be found at


Where are we with DNSSEC?

While the most optimistic estimate is that some 9% of clients use a collection of DNS resolvers where one or more of this resolver set appear to undertake DNSSEC validation, if we make the qualifying conditions a little more precise we get a different number.


The views expressed are the author’s and not those of APNIC, unless APNIC is specifically identified as the author of the communication. APNIC will not be legally responsible in contract, tort or otherwise for any statement made in this publication.

About the Author

GEOFF HUSTON B.Sc., M.Sc., has been closely involved with the development of the Internet for many years, particularly within Australia, where he was responsible for the initial build of the Internet within the Australian academic and research sector. He is author of a number of Internet-related books, and has been active in the Internet Engineering Task Force for many years.