International audience

Electronic government (e-gov) enables citizens and residents to digitally interact with their government via the Internet. Underpinning these services is the Internet Domain Name Systems (DNS), which maps e-gov domain names to Internet addresses. Structuring DNS with multiple levels of redundancy that can withstand stress events such as denial-of-service (DoS) attacks is a challenging task. While the operator community has established best practices to this end, adopting them all involves expert knowledge and resources. In this work, we obtain and study a list of e-gov domain names used by four countries (The Netherlands, Sweden, Switzerland, and the United States) and measure the DNS structuring of these domains. We show the adoption of best practices, inter-country differences such as the use of anycast, and provide recommendations to improve DNS service robustness.

There have been growing concerns about the concentration and centralization of Internet infrastructure. In this work, we scrutinize the hosting industry on the Internet by using active measurements, covering 19 Top-Level Domains (TLDs). We show how the market is heavily concentrated: 1/3 of the domains are hosted by only 5 hosting providers, all US-based companies. For the country-code TLDs (ccTLDs), however, hosting is primarily done by local, national hosting providers and not by the large American cloud and content providers. We show how shared languages (and borders) shape the hosting market — German hosting companies have a notable presence in Austrian and Swiss markets, given they all share German as official language. While hosting concentration has been relatively high and stable over the past four years, we see that American hosting companies have been continuously increasing their presence in the market related to high traffic, popular domains within ccTLDs — except for Russia, notably.

TheInternet's Domain Name System (DNS) is a part of every web request and e-mail exchange, so DNS failures can be catastrophic, taking out major websites and services. This paper identifies TsuNAME, a vulnerability where some recursive resolvers can greatly amplify queries, potentially resulting in a denial-of-service to DNS services. TsuNAME is caused by cyclical dependencies in DNS records. A recursive resolver repeatedly follows these cycles, coupled with insufficient caching and application-level retries greatly amplify an initial query, stressing authoritative servers. Although issues with cyclic dependencies are not new, the scale of amplification has not previously been understood. We document real-world events in .nz (a country-level domain), where two misconfigured domains resulted in a 50% increase on overall traffic. We reproduce and document root causes of this event through experiments, and demostrate a 500× amplification factor. In response to our disclosure, several DNS software vendors have documented their mitigations, including Google public DNS and Cisco OpenDNS. For operators of authoritative DNS services we have developed and released CycleHunter, an open-source tool that detects cyclic dependencies and prevents attacks. We use CycleHunter to evaluate roughly 184 million domain names in 7 large, top-level domains (TLDs), finding 44 cyclic dependent NS records used by 1.4k domain names. The TsuNAME vulnerability is weaponizable, since an adversary can easily create cycles to attack the infrastructure of a parent domains. Documenting this threat and its solutions is an important step to ensuring it is fully addressed.

IP anycast has become a vital technology for DNS and CDN operators alike. Yet, while big operators have their tools to monitor and configure anycast routing, most of anycast networks are still configured manually. In this paper, we introduce a new approach to anycast management. Our solution is based on active measurements combined with traffic engineering. We propose the concept of a "BGP Cookbook" that allows operators to forecast the effects of routing policy changes over their services. We also introduce a web-based interface, called "BGP Anycast Tuner", that allows operators to gain insight into their service's performance and provides easy management through automation. We evaluate our approach by implementing a prototype running in a testbed composed of 12 anycast sites covering 5 continents. We demonstrate our tool in two different use cases: discovering and fixing a sub-optimal anycast routing issue, and shifting traffic between continents, which is useful during service disruptions.

Concern has been mounting about Internet centralization over the few last years -- consolidation of traffic/users/infrastructure into the hands of a few market players. We measure DNS and computing centralization by analyzing DNS traffic collected at a DNS root server and two country-code top-level domains (ccTLDs) -- one in Europe and the other in Oceania -- and show evidence of concentration. More than 30% of all queries to both ccTLDs are sent from 5 large cloud providers. We compare the clouds resolver infrastructure and highlight a discrepancy in behavior: some cloud providers heavily employ IPv6, DNSSEC, and DNS over TCP, while others simply use unsecured DNS over UDP over IPv4. We show one positive side to centralization: once a cloud provider deploys a security feature -- such as QNAME minimization -- it quickly benefits a large number of users.

The Domain Name System (DNS) is thought of as having the simple-sounding task of resolving domains into IP addresses. With its stub resolvers, different layers of recursive resolvers, authoritative nameservers, a multitude of query types, and DNSSEC, the DNS ecosystem is actually quite complex.

DNS depends on extensive caching for good performance, and every DNS zone owner must set Time-to-Live (TTL) values to control their DNS caching. Today there is relatively little guidance backed by research about how to set TTLs, and operators must balance conflicting demands of caching against agility of configuration. Exactly how TTL value choices affect operational networks is quite challenging to understand due to interactions across the distributed DNS service, where resolvers receive TTLs in different ways (answers and hints), TTLs are specified in multiple places (zones and their parent's glue), and while DNS resolution must be security-aware. This paper provides the first careful evaluation of how these multiple, interacting factors affect the effective cache lifetimes of DNS records, and provides recommendations for how to configure DNS TTLs based on our findings. We provide recommendations in TTL choice for different situations, and for where they must be configured. We show that longer TTLs have significant promise in reducing latency, reducing it from 183 ms to 28.7 ms for one country-code TLD.

To enhance competition and choice in the domain name system, ICANN introduced the new gTLD program, which added hundreds of new gTLDs (e.g. .nyc, .io) to the root DNS zone. While the program arguably increased the range of domain names available to consumers, it might also have created new opportunities for cybercriminals. To investigate that, we present the first comparative study of abuse in the domains registered under the new gTLD program and legacy gTLDs (18 in total, such as .com, .org). We combine historical datasets from various sources, including DNS zone files, WHOIS records, passive and active DNS and HTTP measurements, and 11 reputable abuse feeds to study abuse across gTLDs. We find that the new gTLDs appear to have diverted abuse from the legacy gTLDs: while the total number of domains abused for spam remains stable across gTLDs, we observe a growing number of spam domains in new gTLDs which suggests a shift from legacy gTLDs to new gTLDs. Although legacy gTLDs had a rate of 56.9 spam domains per 10,000 registrations (Q4 2016), new gTLDs experienced a rate of 526.6 in the same period-which is almost one order of magnitude higher. In this study, we also analyze the relationship between DNS abuse, operator security indicators and the structural properties of new gTLDs. The results indicate that there is an inverse correlation between abuse and stricter registration policies. Our findings suggest that cybercriminals increasingly prefer to register, rather than hack, domain names and some new gTLDs have become a magnet for malicious actors. ICANN is currently using these results to review the existing anti-abuse safeguards, evaluate their joint effects and to introduce more effective safeguards before an upcoming new gTLD rollout.

Hidden behind domain names, there are lucrative (and ingenious) business models that misuse/abuse the DNS namespace and employ a diversified form of monetization. To curb some of those abuses, many research works have been proposed. However, while having a clear contribution and advancing the state-of-the-art, these works are constrained by their limited datasets and none of them present a survey on the forms of DNS abuse. In this paper, we address these limitations by presenting a case study in one top-level domain (TLD) operator (.nl) with diverse longitudinal datasets.We then cover eight business models that DNS abusers employ and their respective monetization form, and discuss how TLD operators can employ these datasets to detect these forms of abuse.

In Internet Domain Name System (DNS), services operate authoritative name servers that individuals query through recursive resolvers. Operators strive to provide reliability by operating multiple name servers (NS), each on a separate IP address, and by using IP anycast to allow NSes to provide service from many physical locations. To meet their goals of minimizing latency and balancing load across NSes and anycast, operators need to know how recursive resolvers select an NS, and how that interacts with their NS deployments. Prior work has shown some recursives search for low latency, while others pick an NS at random or round robin, but did not examine how prevalent each choice was. This paper provides the first analysis of how recursives select between name servers in the wild, and from that we provide guidance to operators how to engineer their name servers to reach their goals. We conclude that all NSes need to be equally strong and therefore we recommend to deploy IP anycast at every single authoritative.

We present nDEWS, a Hadoop-based automatic early warning system of malicious domains for domain name registry operators, such as top-level domain (TLD) registries. By monitoring an entire DNS zone, nDEWS is able to single out newly added suspicious domains by analyzing both domain registration and global DNS lookup patterns of a TLD. nDEWS is capable to detect several types of domain abuse, such as malware, phishing, and allegedly fraudulent web shops. To act on this data, we have established a pilot study with two major .nl registrars, and provide them with daily feeds of their respective suspicious domains. Moreover, nDEWS can also be implemented by other TLD operators/registries.

We present ENTRADA, a high-performance data streaming warehouse that enables researchers and operators to analyze vast amounts of network traffic and measurement data within interactive response times (seconds to few minutes), even in a small computer cluster. ENTRADA delivers such performance by employing a optimized file format and a high-performance query engine, both open-source. ENTRADA has been operational for more than 1.5 years, having ingested more than 100 TB of pcap files from two .nl DNS authoritative servers. As we discuss, we use this data in projects that aim at further increasing the security and stability of the .nl zone. We present in this paper our design choices, experiences, and a performance evaluation of ENTRADA. Finally, we open-source ENTRADA, which can be used “out-of-the-box” by researchers, operators, and registries to deploy their own networking analysis clusters for DNS traffic, and can be easily extended to handle any other structured data.

IP address counts are typically used as a surrogate metric for the number of hosts in a network, as in the case of ISP rankings based on botnet infected addresses. However, due to effects of dynamic IP address allocation, such counts tend to overestimate the number of hosts, sometimes by an order of magnitude. In the literature, the rate at which hosts change IP addresses is referred to as DHCP churn. Churn rates vary significantly within and among ISP networks, and such variation poses a challenge to any research that relies upon IP addresses as a metric. We present the first attempt towards estimating ISP and Internet-wide DHCP churn rates, in order to better understand the relation between IP addresses and hosts, as well as allow us to correct data relying on IP addresses as a surrogate metric. We propose an scalable active measurement methodology and then validate it using ground truth data from a medium-sized ISP. Next, we build a statistical model to estimate DHCP churn rates and validate against the ground truth data of the same ISP, estimating correctly 72.3% of DHCP churn rates. Finally, we apply our measurement methodology to four major ISPs, triangulate the results to another Internet census, and discuss the next steps to more precisely estimate DHCP churn rates.

Malicious hosts tend to be concentrated in certain areas of the IP addressing space, forming the so-called Bad Neighborhoods. Knowledge about this concentration is valuable in predicting attacks from unseen IP addresses. This observation has been employed in previous works to filter out spam. In this paper, we focus on the temporal behavior of bad neighborhoods. The goal is to determine if bad neighborhoods strike multiple times over a certain period of time, and if so, when do the attacks occur. Among other findings, we show that even though bad neighborhoods do not exhibit a favorite combination of days to carry out attacks, 85% of the recurrent bad neighborhoods do carry out a second attack within the first 5 days from the first attack. These and the other findings here presented lead to several considerations on how attack prediction models can be more effective i.e., generating both predictive and short neighborhood blacklists.

It's known fact that malicious IP addresses are not evenly distributed over the IP addressing space. In this paper, we frame networks concentrating malicious addresses as bad neighborhoods. We propose a formal definition and show this concentration can be used to predict future attacks (new spamming sources, in our case), and propose an algorithm to aggregate individual IP addresses can bigger neighborhoods. Moreover, we show how bad neighborhoods are specific according to the exploited application (e.g., spam, ssh) and how the performance of different blacklist sources impacts lightweight spam filtering algorithms.

Internet Bad Neighborhoods have proven to be an innovative approach for fighting spam. They have also helped to understand how spammers are distributed on the Internet. In our previous works, the size of each bad neighborhood was fixed to a /24 subnetwork. In this paper, however, we investigate if it is feasible to aggregate Internet bad neighborhoods not only at /24, but to any network prefix. To do that, we propose two different aggregation strategies: fixed prefix and variable prefix. The motivation for doing that is to reduce the number of entries in the bad neighborhood list, thus reducing memory storage requirements for intrusion detection solutions. We also introduce two error measures that allow to quantify how much error was incurred by the aggregation process. An evaluation of both strategies was conducted by analyzing real world data in our aggregation prototype.

IT security has become over the recent years a major concern for organizations. However, it doesn’t come without large investments on both the acquisition of tools to satisfy particular security requirements and complex procedures to deploy and maintain a protected infrastructure. The scientific community has proposed in the recent past models and techniques to measure the complexity of configuration procedures, aware that they represent a significant operational cost, often dominating total cost of ownership. However, despite the central role played by security within this context, it has not been subject to any investigation so far. To address this issue, we apply a model of configuration complexity proposed in the literature in order to be able to estimate security impact on the complexity of IT procedures. Our proposal has been materialized through a prototypical implementation of a complexity scorer system called Security Complexity Analyzer (SCA). To prove concept and technical feasibility of our proposal, we have used the SCA to evaluate real-life security scenarios.

Important steps have been taken in the recent years towards evaluating the performance of Web services for network management. Due to the lack of specific standards for Web services-based management, previous evaluations have been carried out measuring only the performance of SOAP (the basic Web services protocol) running in network management environments. While the conclusions of the papers published so far indicate the feasibility of employing Web services for network management, there is no evidence that these conclusions also hold for solutions developed according to recent Web services management standards. In this paper we go a step further and present the results of a set of experiments carried out in order to compare the specifications OASIS management Using Web services (MUWS) and DMTF Web services for management (WS-management) against the de facto network management standard, i.e., the simple network management protocol (SNMP). The performance metrics investigated were network usage, response time, and CPU usage.