Check-Repeat: A New Method of Measuring DNSSEC Validating Resolvers Yingdi Yu UCLA yingdi@cs.ucla.edu Duane Wessels Verisign Labs dwessels@verisign.com Matt Larson Verisign Labs mlarson@verisign.com Lixia Zhang UCLA lixia@cs.ucla.edu Abstract—As more and more authority DNS servers turn on DNS security extensions (DNSSEC), it becomes increasingly important to understand whether, and how many, DNS resolvers perform DNSSEC validation. In this paper we present a query- based measurement method, called Check-Repeat, to gauge the presence of DNSSEC validating resolvers. Utilizing the fact that most validating resolver implementations retry DNS queries with a different authority server if they receive a bad DNS response, Check-Repeat can identify validating resolvers by removing the signatures from regular DNS responses and observing whether a resolver retries DNS queries. We tested Check-Repeat in different scenarios and our results showed that Check-Repeat can identify validating resolvers with a low error rate. We also cross-checked our measurement results with DNS query logs from . COM and . NET domains, and confirmed that the resolvers measured in our study can account for more than 60% of DNS queries in the Internet. I. I NTRODUCTION Domain Name System Security Extensions (DNSSEC) pro- vide the much needed cryptographic protection for the critical DNS services, by allowing end hosts to authenticate DNS data. Effective rollout of DNSSEC requires deployment efforts from both data publishers (zone owners) and data consumers (DNS clients). Zone owners must sign their zones and publish their keys, and DNS clients must upgrade their caching resolvers to perform cryptographic verification of the DNS data. Tracking both sides of DNSSEC deployment is important for a number of reasons. For example, it helps with the “chicken-and-egg” problem. When publishers know that con- sumers are configuring validation in their resolvers, they will be increasingly motivated to sign their zones. When consumers know that publishers are increasingly signing their zones, they will be more motivated to enable validation. The publishing side of DNSSEC deployment has been well studied over the last few years [1]. It is relatively easy to determine whether a given zone is signed by simply sending queries to the authoritative DNS servers of the zone. In contrast, it is rather difficult to measure how many caching resolvers have turned on DNSSEC verification. Generally speaking one does not know all the existing caching resolvers around the world, nor can one directly query them externally. To get good measurement results, one must first find a way to capture resolver queries and analyze their behavior. We are particularly interested in understanding DNSSEC deployment at the consumer-side. To gauge the number of caching resolvers that perform DNSSEC validation, which we call DNSSEC validators, or validators in short, we face the following two problems: • How can one gather DNS queries from as many caching resolvers as possible? • For a given resolver, how can one tell whether it performs validation of DNS data? Some previous studies solved the first problem by analyzing the queries received by the authority DNS servers for a popular domain, such as . ORG [2] and . JP [3]. Unfortunately this method can potentially introduce false positive results. As reported by [4], about 1.6% of measured caching resolvers sent DNSKEY query, but did not validate data. Some other studies solved the second problem by combining the observations of end host behavior on both DNS queries and HTTP requests [4], [5]. As we discuss in Section VI, the effectiveness of this approach is confined to the resolvers that query for a specific domain name. Ideally, one wishes to derive a method that can address both problems simultaneously while avoiding the above mentioned negative factors. In this work, we develop a new solution, dubbed Check- Repeat, to address the two problems at once. Our earlier measurements show that most validating resolver implemen- tations (such as BIND and Unbound), upon receiving a bad response [6], will resend a query to another authority server. Utilizing this observation, Check-Repeat first redirects DNS queries from multiple zones to a single, experimental zone named VALIDATORSEARCH. VERISIGNLABS. COM, intention- ally removes the DNSSEC signature records from responses given by that zone, and then observes whether the caching resolvers will resend queries to another server of VALIDA- TORSEARCH. VERISIGNLABS. COM zone. We examine whether a resolver sends both DNSKEY queries and repeated queries as a stronger indicator of performing DNSSEC validation. Sec- tion III provides the full details of Check-Repeat’s operations. We also compared our measurement results with previous studies, and found that the ratio of validators and resolvers measured are consistent. We also evaluated the representa- tiveness of our results by cross-checking them against query logs from the . COM and . NET authority servers. We observed that the set of caching resolvers seen in our measurements accounted for more than 60% of queries to . COM and . NET zones. The full results of our analysis are presented in Sec- tion IV.