The Domain Name System’s (DNS) critical role in the Internet ecosystem makes it an attractive target to attackers and the unauthenticated design of its original protocol poses inherent susceptibility to a variety of attacks.
To address its security challenges, DNS Security Extensions (DNSSEC) were introduced to augment the authenticity and integrity of the original DNS design, where each DNS record (set) is signed by the signer’s private key and the signature (RRSIG record) is validated via the signer’s public key (DNSKEY record). The DNSKEY record itself is further verified via the signature provided by its parent zone, until a well-known DNSKEY record at the root zone (the trust anchor) has been reached.
Although it has been widely supported among TLD operators, recent work revealed that the insufficient support in DNS registrars largely contributes to poor DNSSEC deployment.
Read: Why DNSSEC deployment remains so low
Similarly, the adoption of DNSSEC is particularly low among the world’s largest websites — none of the top 25 sites supported DNSSEC in 2016; the results remain today. This is intriguing considering they are inclined to maintain a highly secure infrastructure.
In this post, I will provide an overview of the work my colleagues at the University of Delaware and George Mason University and I are studying, examining the fundamental discrepancy between DNSSEC deployment and the wide use of (DNS-based) Content Delivery Networks (CDNs).
CDN and its mapping system
CDNs deliver a large fraction of Internet content to end-users with high availability, performance, and scalability.
Typically, CDNs place a large number of edge servers at geographically distributed edge networks, enabling content caching and proximal access for end-users. User requests for content hosted by CDNs are served at the edge server via request redirection. To do so, the majority of today’s CDNs leverage a mapping system as a core component that uses DNS to redirect a client’s request to a proximal server.
Traditionally, the IP of the client’s DNS resolver is used as an approximation to determine a client’s location as the mapping system has no way to learn this. With EDNS-Client-Subnet (ECS) enabled, the mapping system can use each client’s IP prefix to assign proximal edge servers.
The DNS-based mapping system provides fast, accurate, and fine-grained control for request redirection. However, maintaining a DNS-based mapping system requires extra operational support. As a result, anycast has also been leveraged by some CDN platforms to simplify the task of routing each client’s request to an appropriate server, by which multiple distributed endpoints announce the same IP address and end-users will be directed to different topographically-close locations via BGP routing.
Why DNSSEC deployment remains so slow (and hard) in CDNs
As part of our study, we focused on the DNS mapping-based CDNs that are used by a significant proportion of top websites. A resolution process for CDN-enabled domains typically involves a CNAME chain and a dynamic mapping record:
$ DNS resolution from US east coast www.nbc.com. CNAME www.nbc.com.edgekey.net. www.nbc.com.edgekey.net. CNAME e4204.dscb.akamaiedge.net. e4204.dscb.akamaiedge.net. A 23.281.40.171 $ DNS resolution from US west coast www.nbc.com. CNAME www.nbc.com.edgekey.net. www.nbc.com.edgekey.net. CNAME e4204.dscb.akamaiedge.net. e4204.dscb.akamaiedge.net. A 95.100.196.195
Specifically, the customer domain delegates its DNS resolution to a CDN-provisioned domain via CNAME. Afterwards, CDN’s nameservers take over the resolution. Finally, an A record is dynamically generated by the mapping system, where the IP address is associated with one of the proximal edge servers according to its real-time performance such as responsiveness and capacity. As a result, it is infeasible to predetermine or predict the server assignment and provide a DNSSEC signature in advance.
The limitation here is that traditional RSA-based DNSSEC signatures are mostly precomputed, largely because signing with RSA is prohibitively expensive and cannot be done in real-time.
In addition, the CNAME record in the context of redirection introduces further difficulty for DNSSEC. As such, even the domain owner can legitimately sign the CNAME record for their original sites:
www.whitehouse.gov. CNAME wildcard.whitehouse.gov.edgekey.net. www.whitehouse.gov. RRSIG CNAME [timestamp] [signature of CNAME record]
The following resolution still poses the risk of the unsigned, dynamic records generated by CDNs.
wildcard.whitehouse.gov.edgekey.net. CNAME e4036.dscb.akamaiedge.net. e4036.dscb.akamaiedge.net. A 23.218.37.1
It is worth noting that anycast-based CDNs (for example, Cloudflare) announce static (identical) A records and thus are immune to the problems caused by the dynamics of a mapping system.
Live signing by ECDSA: a solution?
Although alternatives exist, RSA is the widely adopted algorithm by signers.
Recently, the ECDSA algorithm has been attracting significant attention in DNSSEC, given its reduced signature size to mitigate DNSSEC amplification attacks. For example, Cloudflare has launched universal ECDSA-based DNSSEC support for its customer domains. Furthermore, the significantly reduced computational overhead enables ECDSA to sign the records in real-time (live signing), providing a potential solution for DNS-based CDNs signing the dynamically generated records at the edge of the Internet. Problem solved?
Read: DNSSEC and ECDSA
Given the live-signing of ECDSA and the dynamic records from the mapping system, there will be multiple valid records with different IP addresses but legitimate signatures over the Internet. This then poses a risk of replay attack: a man-in-the-middle attacker can fetch a legitimate record in advance, and easily inject it into a resolver’s cache. As a result, client requests will be redirected to a server chosen by the attacker, and client access can be interrupted if the server becomes heavily loaded or unresponsive.
For more details check out our paper which was published at USENIX Security’18.
Shuai Hao is an Assistant Professor of Computer Science at Old Dominion University in Norfolk, Virginia, US, working on the measurement and security of Internet infrastructure.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.