A Longitudinal, End-to-End View of the DNSSEC Ecosystem Taejoong Chung, Northeastern University; Roland van Rijswijk-Deij, University of Twente and SURFnet bv; Balakrishnan Chandrasekaran, TU Berlin; David Choffnes, Northeastern University; Dave Levin, University of Maryland; Bruce M. Maggs, Duke University and Akamai Technologies; Alan Mislove and Christo Wilson, Northeastern University https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/chung This paper is included in the Proceedings of the 26th USENIX Security Symposium August 16–18, 2017 • Vancouver, BC, Canada ISBN 978-1-931971-40-9 Open access to the Proceedings of the 26th USENIX Security Symposium is sponsored by USENIX A Longitudinal, End-to-End View of the DNSSEC Ecosystem Taejoong Chung Roland van Rijswijk-Deij Northeastern University University of Twente and SURFnet Balakrishnan Chandrasekaran David Choffnes Dave Levin TU Berlin Northeastern University University of Maryland Bruce M. Maggs Alan Mislove Duke University and Akamai Technologies Northeastern University Christo Wilson Northeastern University Abstract To address these problems, DNS Security Extensions (DNSSEC) [20] were introduced nearly two decades ago. The Domain Name System’s Security Extensions At its core, DNSSEC is a hierarchical public key infras- (DNSSEC) allow clients and resolvers to verify that tructure (PKI) that largely mirrors the DNS hierarchy and DNS responses have not been forged or modified in- is rooted at the root DNS zone. To enable DNSSEC, the flight. DNSSEC uses a public key infrastructure (PKI) owner of a domain signs its DNS records and publishes to achieve this integrity, without which users can be sub- the signatures along with its public key; this public key is ject to a wide range of attacks. However, DNSSEC can then signed by its parent domain, and so on up to the root operate only if each of the principals in its PKI prop- DNS zone. A resolver validates a signed DNS record erly performs its management tasks: authoritative name by recursively checking the associated signatures until it servers must generate and publish their keys and signa- reaches the well-known root zone trusted key. tures correctly, child zones that support DNSSEC must Largely in response to powerful attacks such as the be correctly signed with their parent’s keys, and resolvers Kaminsky Attack [28], DNSSEC adoption has increased must actually validate the chain of signatures. recently. As of early 2017, more than 90% of top- This paper performs the first large-scale, longitudi- level domains (TLDs) and 47% of country-code TLDs nal measurement study into how well DNSSEC’s PKI is (ccTLDs) are DNSSEC-enabled [26, 47]. Widely-used managed. We use data from all DNSSEC-enabled sub- DNS resolvers now attempt DNSSEC validation by de- domains under the .com, .org, and .net TLDs over a fault, e.g., as of January 2012 Comcast (one of the period of 21 months to analyze DNSSEC deployment largest ISPs in the US) requests and validates DNSSEC and management by domains; we supplement this with records for all queries [32], and Google (which operates active measurements of more than 59K DNS resolvers the largest public DNS resolver) did the same in March worldwide to evaluate resolver-side validation. 2013 [22].1 Our investigation reveals pervasive mismanagement of But like any PKI, DNSSEC can only function cor- the DNSSEC infrastructure. For example, we found that rectly when all principals—every signatory from root 31% of domains that support DNSSEC fail to publish to leaf, and the resolver validating the signatures— all relevant records required for validation; 39% of the fulfill their respective responsibilities. Unfortunately, domains use insufficiently strong key-signing keys; and DNSSEC is complex, creating many opportunities for although 82% of resolvers in our study request DNSSEC mismanagement. On the server side, a single error such records, only 12% of them actually attempt to validate as a weak key, an expired signature, or a broken signature them. These results highlight systemic problems, which chain can weaken or totally compromise the integrity of motivate improved automation and auditing of DNSSEC a large number of domains. On the client side, misman- management. aged or buggy DNS resolvers can obviate all server-side efforts by simply failing to catch invalid or missing sig- 1 Introduction natures. Surprisingly little is known about how well the The Domain Name System (DNS) [36] provides a DNSSEC PKI ecosystem is managed. While there have scalable, flexible name resolution service. Unfortu- 1It is important to note that these resolvers still accept responses nately, DNS has long been fraught with security issues without DNSSEC records, as the vast majority of domain administra- such as DNS spoofing and cache poisoning [3, 28, 46] tors have yet to deploy DNSSEC. USENIX Association 26th USENIX Security Symposium 1307 been many studies of DNSSEC, we find that no prior ef- solvers request DNSSEC records during their queries, forts had the data to allow them to study the DNSSEC only 12% of them actually validate the records (de- PKI at scale—across many domains and resolvers— feating the purpose of DNSSEC). This finding moti- and longitudinally—by monitoring their behavior over vates the need to reexamine approaches using query time. For example, server-side studies have shown in- logs from authoritative name servers as a lens to mea- stances of mismanagement, but only for samples of do- sure DNSSEC adoption by resolvers [21, 23]. main names [12–14]. Likewise, prior studies of DNS resolvers have used ad campaigns, which do not per- In summary, our results paint a distressing picture mit repeated, controlled measurements of resolvers over of widespread mismanagement of keys and DNSSEC time [7, 33, 47]. What has made large-scale, longitu- records that violate best practices in some cases, and dinal studies of DNSSEC so challenging is a dearth of completely defeat the security guarantees of DNSSEC DNSSEC record datasets and a lack of vantage points in others. On a more positive note, our findings demon- from which to repeatedly measure resolver behavior. strate several areas of improvement where management In this paper, we present a comprehensive study of the of the DNSSEC PKI can be automated and audited. To entire DNSSEC ecosystem—encompassing signers, au- this end, we publicly release all of our analysis code and 2 thoritative name servers, and validating DNS resolvers— data (where possible ) to the research community at to understand how DNSSEC is (mis)managed today. To https://securepki.org study server-side behavior, our work relies on 21 months of daily snapshots, and three months of hourly snap- thereby allowing other researchers and administrators to shots, of DNSSEC records for all signed .com, .net, reproduce and extend our work. and .org second-level domains. To study client-side behavior, we leverage the Luminati HTTP/S proxy ser- 2 Background vice [35], which allows us to perform repeated, con- trolled tests from 403,355 end hosts—thereby studying We begin by presenting an overview of both DNS and 59,513 distinct DNS resolvers—around the world. DNSSEC. Our analysis reveals troubling, persistent mismanage- ment in the DNSSEC PKI: DNS and DNSSEC DNS uses records to map domain names to values (e.g., an A record maps a domain name • First, we find that nearly one-third of DNSSEC- to an IPv4 address; an NS record maps a domain name enabled domains produce records that cannot be val- to the authoritative name server for a domain). DNS is idated due to missing or incorrect records. 1.7% designed to encourage caching, and every DNS record of signed domains fail to provide RRSIGs for SOA contains a time-to-live (TTL), specifying how long the records, while 30% of signed domains do not have DS records can be cached for. The original DNS proto- records. The vast majority of these missing records col did not include security, allowing an adversary to are due to large hosting providers that fail to publish forge DNS responses to carry out attacks. DNS Security the correct records for domains they manage. Addi- Extensions (commonly referred to as DNSSEC) are de- tionally, we find that 0.6% of signed domains provide signed to address this vulnerability [4–6, 19]. DNSSEC incorrect RRSIGs for both SOA and DNSKEY records. provides integrity for DNS records using three primary • Second, we identify four large providers that use the record types3: same keys to sign all of their managed domains. This unnecessary key reuse makes all of the domains vul- DNSKEY records, which are public keys used in nerable to the compromise of a single shared key. For DNSSEC. Typically, each zone uses two DNSKEY example, we find that a single key is shared by over records to sign DNS records, as discussed below. 132K domains. RRSIG (Resource Record Signature) records, which are • Third, we observe widespread use of 1024-bit RSA cryptographic signatures of other records. Each keys, which are now considered “weak” (smaller RRSIG is a signature over all records of a given than the NIST-recommended minimum size of 2048 type for a certain name; this set is called an RRSet. bits [1]). 39% of domains use weak Key Signing Keys (KSKs), and over 90% of domains use weak Zone 2Our .com, .org, and .net zone files are collected under agree- ment with the zone operators; while we are not permitted to release Signing Keys (ZSKs). DNSSEC is designed to be re- this data, we provide links where other researchers can obtain access silient against weak and stolen keys via frequent key themselves. rotation, but we find that 70% of domains never ro- 3There are other record types for expressing the non-existence of tated their KSK during our 21-month study.