Reply to comment:

Geoff Huston
Thanks for your comments. As the article notes one of the major feature of this form of measurement exploiting the features allows for a truly massive number of tests to be perform very quickly, and for these tests to be gathered from all over the Internet. In our case the 7 days of running the ad gathered more than three quarters of a million individual measurements. Obviously the number of sample points will vary country by country, and the ranking for Libya was obtained from 330 separate measurements, while that for Sweden was obtained from 1,307 measurements. The definition of "clients who use DNSSEC-validating resolvers" is a careful definition. If a client has a number of resolvers in its local resolver list, and the first, or initially queried, resolver performs DNSSEC validation, and if the object in question is deliberately configured with a broken DNSSEC validation chain then the resolver will return a SERVFAIL error code to the client, and the client will move on to the next resolver. So it may well be that of the set of resolvers used by a client that only a subset perform DNSSEC validation, in which case the client may still retrieve an object that fails DNSSEC validation. So "clients who do NOT fetch from DNSSEC-invalid domains" is a different (and smaller) quantity that that reported here, namely of "clients who use DNSSEC-validating resolvers". The next question is: how can you tell is a resolver is DNSSEC-validating? Again this is not an easy question to answer definitively. The major indication that the resolver is undertaking DNSSEC validation is the resolver queries for the DNSKEY RR of the domain (and in the case that there is a chain to validation we will also see DS RR retrievals from the parent domain as well. As this information is cached by the resolver (or may be cached) then we will see this DNSKEY RR request once, but for subsequent domain name resolution queries the DNSKEY query will (or may) not be repeated. Now the problem here is: how can you tell the difference between a recursive resolver performing DNSSEC validation and a caching DNS forwarder? From the perspective of the authoritative name server this is not easily possible, as far as I can tell. So Yes, the Google documentation says Public DNS does not DNSSEC validate, but at the same time we see behaviour from many of the DNS resolvers operated by Google that are consistent with these resolvers performing this validation. Whether its them or whether its recursive DNSSEC-validating resolvers that use the Google service as a forwarder is of course hard for us to tell.