DNS is designed to drive Internet traffic, directing users to the IP addresses hosting Internet services. Modern, replicated services use DNS to direct users to desired (low latency, available) servers, and DNS uses caches to limit DNS overhead on users and services. However, little is known about how these interactions play out in practice, partly due to the proprietary nature of traffic traces.
In this talk, we will discuss DNS in the context of the Internet service traffic that it does (and does not) drive for residential users. Our results are based on a trace of 500 apartments, for which we join DNS queries, traffic flows, and services (e.g., Netflix). We find that DNS caching is effective at reducing overhead, with little DNS latency relative to the overall service latency. However, that effectiveness comes at a cost of responsiveness, with significant volumes of traffic using IP addresses from very stale cached DNS records (e.g., 6.5% of flows start more than 1 minute after the DNS TTL expired, and 80% of Microsoft traffic is sent more than 5 minutes after TTL expiration), limiting the agility of services to steer traffic for performance, load balancing, and resilience to failures. This significant staleness occurs before the recursive resolver, meaning client-side caches are to blame. Further, we find that 12% of traffic does not use DNS lookups. We develop inference techniques to identify half of that traffic as peer-to-peer -- 17% of connections overall! -- pointing to a possible resurgence of P2P for emerging use cases.
We will conclude by briefly presenting service redirection techniques we have developed to provide services with better tradeoffs than unicast+DNS redirection (precise steering, but poor responsiveness due to DNS caching and TTL violations) and anycast (imprecise steering but good resilience).