Public DNS Resolvers Meet Content Delivery Networks: A Performance Assessment of the Interplay

TL;DR

This study assesses how public DNS resolvers affect CDN performance, revealing differences in latency, cache hit rates, and IPv6 penalties, with implications for end-user experience and resolver choices.

Contribution

It provides a comprehensive reassessment of DNS-CDN interplay considering recent developments like IPv6, ECS, and anycast, highlighting performance disparities among resolvers.

Findings

Cloudflare DNS has lower latency and higher cache hit rates.

Google DNS and OpenDNS lag behind in DNS latency but improve CDN mapping quality.

IPv6 introduces latency penalties that can affect dual-stacked clients.

Abstract

This paper investigates two key performance aspects of the interplay between public DNS resolution services and content delivery networks -- the latency of DNS queries for resolving CDN-accelerated hostnames and the latency between the end-user and the CDN's edge server obtained by the user through a given resolution service. While these important issues have been considered in the past, significant developments, such as the IPv6 finally getting traction, the adoption of the ECS extension to DNS by major DNS resolution services, and the embracing of anycast by some CDNs warrant a reassessment under these new realities. Among the resolution services we consider, We find Google DNS and OpenDNS to lag behind the Cloudflare resolver and, for some CDNs, Quad9 in terms of DNS latency, and trace the cause to drastically lower cache hit rates. At the same time, we find that Google and OpenDNS have largely closed the gap with ISP resolvers in the quality of CDNs'client-to-edge-server mappings as measured by latency, while the Cloudflare resolver still shows some penalty with Akamai, and Quad9 exhibits a noticeable penalty with three of the four CDNs in the study, keeping up only for Cloudflare CDN that does not use DNS to map clients to servers. Finally, in several locations, we observe IPv6 penalty in the latency of client-to-CDN-edge-server mappings produced by the resolvers. Moreover, this penalty does not rise above typical thresholds employed by the Happy Eyeballs algorithm for falling back to IPv4 communication. Thus, dual-stacked clients in these locations may experience suboptimal performance.