Search for: All records

We propose a new traceroute tool, FlashRoute for efficient large-scale topology discovery. FlashRoute reduces the time required for tracerouting the entire /24 IPv4 address space by a factor of three and half compared to previous state of the art. Additionally, we present a new technique to measure hop-distance to a destination using a single probe and uncover a bias of the influential ISI Census hitlist [18] in topology discovery. 

Content delivery networks (CDNs) commonly use DNS to map end-users to the best edge servers. A recently proposed EDNS0-Client-Subnet (ECS) extension allows recursive resolvers to include end-user subnet information in DNS queries, so that authoritative DNS servers, especially those belonging to CDNs, could use this information to improve user mapping. In this paper, we study the ECS behavior of ECS-enabled recursive resolvers from the perspectives of the opposite sides of a DNS interaction, the authoritative DNS servers of a major CDN and a busy DNS resolution service. We find a range of erroneous (i.e., deviating from the protocol specification) and detrimental (even if compliant) behaviors that may unnecessarily erode client privacy, reduce the effectiveness of DNS caching, diminish ECS benefits, and in some cases turn ECS from facilitator into an obstacle to authoritative DNS servers' ability to optimize user-to-edge-server mappings. 

Authoritative DNS servers are susceptible to being leveraged in denial of service attacks in which the attacker sends DNS queries while masquerading as a victim---and hence causing the DNS server to send the responses to the victim. This reflection off innocent DNS servers hides the attackers identity and often allows the attackers to amplify their traffic by employing small requests to elicit large responses. Several challenge-response techniques have been proposed to establish a requester's identity before sending a full answer. However, none of these are practical in that they do not work in the face of ``resolver pools''---or groups of DNS resolvers that work in concert to lookup records in the DNS. In these cases a challenge transmitted to some resolver $R_1$ may be handled by a resolver $R_2$, hence leaving an authoritative DNS server wondering whether $R_2$ is in fact another resolver in the pool or a victim. We offer a practical challenge-response mechanism that uses challenge chains to establish identity in the face of resolver pools. We illustrate that the practical cost of our scheme in terms of added delay is small.