IP anycast provides DNS operators and CDNs with automatic failover and reduced latency by breaking the Internet into catchments, each served by a di erent anycast site. Unfortunately, understanding and predicting changes to catchments as anycast sites are added or removed has been challenging. Current tools such as RIPE Atlas or commercial equivalents map from thousands of vantage points (VPs), but their coverage can be inconsistent around the globe. This paper proposes Verfploeter, a new method that maps anycast catchments using active probing. Verfploeter provides around 3.8M passive VPs, 430× the 9k physical VPs in RIPE Atlas, providing coverage of the vast majority of networks around the globe. We then add load information from prior service logs to provide calibrated predictions of anycast changes. Verfploeter has been used to evaluate the new anycast deployment for B-Root, and we also report its use of a nine-site anycast testbed. We show that the greater coverage made possible by Verfploeter's active probing is necessary to see routing di erences in regions that have sparse coverage from RIPE Atlas, like South America and China.

Distributed Denial-of-Service (DDoS) attacks continue to be a major threat on the Internet today. DDoS attacks overwhelm target services with requests or other traffic, causing requests from legitimate users to be shut out. A common defense against DDoS is to replicate a service in multiple physical locations/sites. If all sites announce a common prefix, BGP will associate users around the Internet with a nearby site, defining the catchment of that site. Anycast defends against DDoS both by increasing aggregate capacity across many sites, and allowing each site's catchment to contain attack traffic, leaving other sites unaffected. IP anycast is widely used by commercial CDNs and for essential infrastructure such as DNS, but there is little evaluation of anycast under stress. This paper provides the first evaluation of several IP anycast services under stress with public data. Our subject is the Internet's Root Domain Name Service, made up of 13 independently designed services ("letters", 11 with IP anycast) running at more than 500 sites. Many of these services were stressed by sustained traffic at 100× normal load on Nov. 30 and Dec. 1, 2015. We use public data for most of our analysis to examine how different services respond to stress, and identify two policies: sites may absorb attack traffic, containing the damage but reducing service to some users, or they may withdraw routes to shift both good and bad traffic to other sites. We study how these deployment policies resulted in different levels of service to different users during the events. We also show evidence of collateral damage on other services located near the attacks.

The Domain Name System (DNS) is a critical part of network and Internet infrastructure; DNS lookups precede almost any user request. DNS lookups may contain private information about the sites and services a user contacts, which has spawned efforts to protect privacy of users, such as transport encryption through DNS-over-TLS or DNS-over-HTTPS.In this work, we provide a first look on the resolver-side technique of query name minimization (qmin), which was standardized in March 2016 as RFC 7816. qmin aims to only send minimal information to authoritative name servers, reducing the number of servers that full DNS query names are exposed to. Using passive and active measurements, we show a slow but steady adoption of qmin on the Internet, with a surprising variety in implementations of the standard. Using controlled experiments in a test-bed, we validate lookup behavior of various resolvers, and quantify that qmin both increases the number of DNS lookups by up to 26%, and also leads to up to 5% more failed lookups. We conclude our work with a discussion of qmin's risks and benefits, and give advice for future use.

IP anycast is widely being used to distribute essential Internet services, such as DNS, across the globe. One of the main reasons for doing so is to increase the redundancy of the service and reduce the impacts of the growing threat of DDoS attacks. IP anycast can be further used to mitigate DDoS attacks by confining the attack traffic to certain areas. This might cause the targeted service to become unavailable only to a fraction of its users. In this PhD research we aim at investigating how IP anycast can be optimized both statically and dynamically to support the mitigation of DDoS attacks.

In 2009 Google launched its Public DNS service, with its characteristic IP address 8.8.8.8. Since then, this service has grown to be the largest and most well-known DNS service in existence. The popularity of public DNS services has been disruptive for Content Delivery Networks (CDNs). CDNs rely on IP information to geo-locate clients. This no longer works in the presence of public resolvers, which led to the introduction of the EDNS0 Client Subnet extension. ECS allows resolvers to reveal part of a client's IP address to authoritative name servers and helps CDNs pinpoint client origin. A useful side effect of ECS is that it can be used to study the workings of public DNS resolvers. In this paper, we leverage this side effect of ECS to study Google Public DNS. From a dataset of 3.7 billion DNS queries spanning 2.5 years, we extract ECS information and perform a longitudinal analysis of which clients are served from which Point-of-Presence. Our study focuses on two aspects of GPDNS. First, we show that while GPDNS has PoPs in many countries, traffic is frequently routed out of country, even if that was not necessary. Often this reduces performance, and perhaps more importantly, exposes DNS requests to state-level surveillance. Second, we study how GPDNS is used by clients. We show that end-users switch to GPDNS en masse when their ISP's DNS service is unresponsive, and do not switch back. We also find that many e-mail providers configure GPDNS as the resolver for their servers. This raises serious privacy concerns, as DNS queries from mail servers reveal information about hosts they exchange mail with. Because of GPDNS's use of ECS, this sensitive information is not only revealed to Google, but also to any operator of an authoritative name server that receives ECS-enabled queries from GPDNS during the lookup process.