Following the expansion of IoT systems, spanning from devices to cloud backends, reported IoT CVE vulnerabilities have increased at an alarming pace. Since most IoT attacks exploit known vulnerabilities, understanding known vulnerabilities is vital for defense and security research. In this work, we systematize the prior research on studying IoT vulnerabilities, revealing the absence of consistent IoT definitions, reliable and scalable classification methodologies, and high-quality IoT CVE datasets. To overcome these limitations, we design LLIoT, a novel and LLM-assisted approach that systematically and automatically distinguishes IoT-specific CVEs at large scale, enabling in-depth under-standing of IoT vulnerabilities. First, leveraging the systematization knowledge from the literature, we derive a four-layer IoT ecosystem taxonomy and define classification criteria for distinguishing IoT CVEs. Then, using an expert-validated ground-truth dataset, we demonstrate that LLMs can reliably distinguish IoT from non-IoT CVEs with a high accuracy of 95%, outperforming humans by avoiding cognitive errors and gaps in domain knowledge. Applying LLIoT to CVEs from 2013-2024, we build a dataset of 15,116 IoT-specific vulnerabilities, of which 8,368 are newly classified with respect to previous datasets. Using this dataset, which we share with the research community for further research and reproducibility, we characterize how IoT vulnerabilities differ from traditional IT vulnerabilities. Upon our observation, we provide actionable recommendations for responsible stakeholders.

Load Balancing (LB) is a routing strategy that increases performance by distributing traffic over multiple outgoing paths. In this work, we introduce a novel methodology to detect the influence of LB on anycast routing, which can be used by operators to detect networks that experience anycast site flipping, where traffic from a single client reaches multiple anycast sites. We use our methodology to measure the effects of LB-behavior on anycast routing at a global scale, covering both IPv4 and IPv6. Our results show that LB-induced anycast site flipping is widespread. The results also show our method can detect LB implementations on the global Internet, including detection and classification of Points-of-Presence (PoP) and egress selection techniques deployed by hypergiants, cloud providers, and network operators. We observe LB-induced site flipping directs distinct flows to different anycast sites with significant latency inflation. In cases with two paths between an anycast instance and a load-balanced destination, we observe an average RTT difference of 30 ms with 8% of load-balanced destinations seeing RTT differences of over 100 ms. Being able to detect these cases can help anycast operators significantly improve their service for affected clients.

Remote peering (RP) enables networks to reach Internet Exchange Points (IXPs) without physical presence in the same datacenter/location, offering cost-effective interconnection. However, in the context of anycast, where routing efficiency relies on the assumption that traffic is routed to the geographically nearest instance, RP can undermine this principle by introducing hidden performance costs and inflating paths. This paper presents a hybrid methodology, combining data-plane measurements with control-plane insights, to detect and geolocate RP links at scale using IP-level geolocation, AS-level mapping, and IXP facility data. Using 3 million traceroutes targeting 13,735 anycast /24-prefixes, we quantify the impact of RP on anycast routing.Our analysis shows that whilst RP is widespread, it often connects ASes geographically close to the IXP facility. However, for cases where it is “remote” we find it frequently results in long detours, elevated latency, and sub-optimal anycast site selection. Finally, we identify key ASes and IXP regions that play a central role in driving RP-related detours and locality violations in anycast routing. Our findings demonstrate at Internet scale that RP undermines anycast locality by increasing the likelihood of detours and inflated paths, underscoring the need for improved visibility into interconnection practices that impact latency-sensitive services.

[1.5.4] - 2026-08-10 Changed Fixed --accuracy quadratic cost - candidate_diameter was computed by comparing every pair of surviving candidates. This was expensive for large MIS discs. We now approximate the distance for large MIS discs using a farthest-point sweep. Documentation Added a section on the accuracy trade-off between disc intersection and single-disc (iGreedy) geolocation. Full Changelog: https://github.com/rhendriks/MiGreedy/compare/v1.5.3...v1.5.4

Residential proxies (RESIP) enable the tunneling of traffic through non-data center Internet connections. Previous research has focused on malicious software on end-user devices that made them part of RESIP networks. This study investigates RESIP networks that users voluntarily join in exchange for monetary rewards, aiming to understand the activities facilitated through these services. We developed a testbed environment to operate and monitor eight different residential proxy applications over 7.5 months, enabling us to collect and analyze 368 GB of proxied network traffic, the majority of which is encrypted.In this work, we highlight three distinct case studies that suggest these proxies are used in practices not advertised by the RESIP providers and in one case, shed light on the scale of the proxied campaigns. Firstly, we discuss the use of RESIPs on two dating apps, Tinder and happn, highlighting their likely role in facilitating fraudulent activities. Secondly, an analysis of metadata suggests that RESIPs may play a crucial part in phishing campaigns. Thirdly, a collaboration with a leading technology company in the travel industry allows us to analyze the behavior of web scrapers.Our results underscore the need for enhanced detection mechanisms to mitigate fraud and protect users.

With the growing number of Federated Learning (FL) applications in smart homes, it becomes crucial to manage communication and computation resources within the smart home so that FL applications can complete their training on time. While computation offloading has relieved the challenge of timely completion of applications in case of high competition for local resources, privacy of the smart home data remains a critical concern. This paper introduces ERAFL, a resource allocation and computation offloading algorithm running on a home gateway. Unlike privacy-oblivious prior works, ERAFL considers privacy-sensitivity level of FL training data in offloading decision, prioritizing local processing of more sensitive data, e.g., biological personal data. Moreover, in case of insufficient local resources, ERAFL offloads a part of data and accelerates training by leveraging parallel training on the cloud and the edge device. It also imposes limits on the amount of offloaded data or performs the training either locally or remotely to ensure model accuracy. Our simulation results show that ERAFL can satisfy more FL training tasks and reduce data privacy leakage in comparison to the baselines that do not consider partial offloading, privacy sensitivity of application data or resource allocation.

The Border Gateway Protocol (BGP) is known to have several security weaknesses. Two major threats are BGP prefix hijacking and BGP route leaks. A hijack refers to the illegitimate announcement of another Autonomous System’s (AS) IP prefix space while a route leak is the accidental forwarding of a route to a peer that should not have received such an announcement. The Resource Public Key Infrastructure (RPKI) provides origin validation and is able to mitigate a subset of prefix hijacking attacks. Route leaks and forged-origin prefix hijacks are not yet properly addressed. Autonomous System Provider Authorization (ASPA) and AS-Cones are two path plausibility algorithms proposed within the Internet Engineering Task Force (IETF) to mitigate these issues. This work implements ASPA and AS-Cones in a simulation testbed. We compare deployment strategies and recommend to start deploying both algorithms in a top-down manner, starting with the AS with the highest connectivity. While AS-Cones requires less ASes to participate it shows similar benefits in route leak mitigation. Only ASPA can mitigate the forged-origin prefix hijack and results heavily depend on the victim AS to participate in ASPA object creation.

Internet eXchange Points (IXPs) provide an infrastructure where content providers and consumers can freely exchange network traffic. The main incentive for connecting to an IXP is to decrease costs and improve the user experience by having content closer to consumers. Despite these benefits, several small Content Delivery Networks (CDNs) avoid exchanging traffic on IXPs due to the poor routing quality via IXP paths. In this paper, we investigate how traffic asymmetry affects the quality of paths. IXP asymmetry occurs when traffic is sent (or received) via a direct IXP peering but received (or sent) on an alternative path outside the IXP. We employ a new method to quantify a symmetry rate for an IXP, which we evaluate on five IXPs. Our method covers three times more ASes than alternatives, such as using RIPE ATLAS. Our results show that IXPs have 15% asymmetric paths at a distance of one AS hop, i.e., when sending traffic to a given peer on the IXP, 15% of this traffic will be responded via a transit AS that does not use the IXP path. We also identify deaf neighbors, i.e., ASes that never return traffic to the IXP. We identify egress-only paths as a major cause of asymmetries and show that this occurs only for a small number of ASes. We also quantify the impact of traffic asymmetry at IXPs in terms of latency and show that traditional traffic engineering on IXP prefixes can actually make route quality worse.

The hostilities in Ukraine have driven unprecedented forces, both from third-party countries and in Russia, to create economic barriers. In the Internet, these manifest both as internal pressures on Russian sites to (re-)patriate the infrastructure they depend on (e.g., naming and hosting) and external pressures arising from Western providers disassociating from some or all Russian customers. While quite a bit has been written about this both from a policy perspective and anecdotally, our paper places the question on an empirical footing and directly measures longitudinal changes in the makeup of naming, hosting and certificate issuance for domains in the Russian Federation.

Denial of Service (DDoS) attacks both abuse and target core Internet infrastructures and services, including the Domain Name System (DNS). To characterize recent DDoS attacks against authoritative DNS infrastructure, we join two existing data sets - DoS activity inferred from a sizable darknet, and contemporaneous DNS measurement data - for a 17-month period (Nov. 20 - Mar. 22). Our measurements reveal evidence that millions of domains (up to 5% of the DNS namespace) experienced a DoS attack during our observation window. Most attacks did not substantially harm DNS performance, but in some cases we saw 100-fold increases in DNS resolution time, or complete unreachability. Our measurements captured a devastating attack against a large provider in the Netherlands (TransIP), and attacks against Russian infrastructure. Our data corroborates the value of known best practices to improve DNS resilience to attacks, including the use of anycast and topological redundancy in nameserver infrastructure. We discuss the strengths and weaknesses of our data sets for DDoS tracking and impact on the DNS, and promising next steps to improve our understanding of the evolving DDoS ecosystem.

Given the importance of privacy, many Internet protocols are nowadays designed with privacy in mind (e.g., using TLS for confidentiality). Foreseeing all privacy issues at the time of protocol design is, however, challenging and may become near impossible when interaction out of protocol bounds occurs. One demonstrably not well understood interaction occurs when DHCP exchanges are accompanied by automated changes to the global DNS (e.g., to dynamically add hostnames for allocated IP addresses). As we will substantiate, this is a privacy risk: one may be able to infer device presence and network dynamics from virtually anywhere on the Internet --- and even identify and track individuals --- even if other mechanisms to limit tracking by outsiders (e.g., blocking pings) are in place.

Due to the COVID-19 pandemic, smartphone-based proximity tracing systems became of utmost interest. Many of these systems use Bluetooth Low Energy (BLE) signal strength data to estimate the distance between two persons. The quality of this method depends on many factors and, therefore, does hardly deliver accurate results. We present a multi-channel approach to improve proximity classification, and a novel, publicly available data set that contains matched IEEE 802.11 (2.4 & 5 GHz) and BLE signal strength data, measured in four different environments. We utilize these data to train machine learning models. The evaluation showed significant improvements in the distance classification and consequently also the contact tracing accuracy. However, we also encountered privacy problems and limitations due to the consistency and interval at which such probes are sent. We discuss these limitations and sketch how our approach could be improved to make it suitable for real-world deployment.

Clouds are likely to be well-provisioned in terms of network capacity by design. The rapid growth of cloud-based services means an increased availability of network infrastructure for all types of customers. However, it could also provide attackers opportunity to misuse cloud infrastructure to bring about attacks, or to target the cloud infrastructure itself.

The majority of Web content is delivered by only a few companies that provide Content Delivery Infrastructuress (CDIss) such as Content Delivery Networkss (CDNss) and cloud hosts. Due to increasing concerns about trends of centralization, empirical studies on the extent and implications of resulting Internet consolidation are necessary. Thus, we present an empirical view on consolidation of the Web by leveraging datasets from two different measurement platforms. We first analyze Web consolidation around CDIs at the level of landing webpages, before narrowing down the analysis to a level of embedded page resources. The datasets cover 1(a) longitudinal measurements of DNS records for 166.5 M Web domains over five years, 1(b) measurements of DNS records for Alexa Top 1 M over a month and (2) measurements of page loads and renders for 4.3 M webpages, which include data on 392.3 M requested resources. We then define CDIs penetration as the ratio of CDI-hosted objects to all measured objects, which we use to quantify consolidation around CDIs. We observe that CDI penetration has close to doubled since 2015, reaching a lower bound of 15% for all .com , .net , and .org Web domains as of January 2020. Overall, we find a set of six CDIss to deliver the majority of content across all datasets, with these six CDIss being responsible for more than 80% of all 221.9 M CDI-delivered resources (56.6% of all resources in total). We find high dependencies of Web content on a small group of CDIss, in particular, for fonts, ads, and trackers, as well as JavaScript resources such as jQuery. We further observe CDIss to play important roles in rolling out IPv6 and TLS 1.3 support. Overall, these observations indicate a potential oligopoly, which brings both benefits but also risks to the future of the Web.

DDoS attacks threaten Internet security and stability, with attacks reaching the Tbps range. A popular approach involves DNS-based reflection and amplification, a type of attack in which a domain name, known to return a large answer, is queried using spoofed requests. Do the chosen names offer the largest amplification, however, or have we yet to see the full amplification potential? And while operational countermeasures are proposed, chiefly limiting responses to ‘ANY’ queries, up to what point will these countermeasures be effective? In this paper we make three main contributions. First, we propose and validate a scalable method to estimate the amplification potential of a domain name, based on the expected ANY response size. Second, we create estimates for hundreds of millions of domain names and rank them by their amplification potential. By comparing the overall ranking to the set of domains observed in actual attacks in honeypot data, we show whether attackers are using the most-potent domains for their attacks, or if we may expect larger attacks in the future. Finally, we evaluate the effectiveness of blocking ANY queries, as proposed by the IETF, to limit DNS-based DDoS attacks, by estimating the decrease in attack volume when switching from ANY to other query types. Our results show that by blocking ANY, the response size of domains observed in attacks can be reduced by 57%, and the size of most-potent domains decreases by 69%. However, we also show that dropping ANY is not an absolute solution to DNS-based DDoS, as a small but potent portion of domains remain leading to an expected response size of over 2,048 bytes to queries other than ANY.

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.

The deployment of the Resource Public Key Infrastructure (RPKI) is currently gaining traction within the operator community and so are measurement methodologies trying to measure the current deployment status. These methodologies, which are attempting to infer Autonomous Systems (ASs) performing Route Origin Validation (ROV), are applied onto real world data but validation of the results is usually hard as no ground-truth dataset exists. We propose to build such a dataset with the help of Mininet in a way that ROV measurement methodologies can be evaluated within a testbed in which filtering ASs are known to the experimenter. The Mininet topology generator will not only be specific for RPKI measurements but could be used also as an evaluation testbed for any kind of measurements that require a ground-truth dataset. Our framework is fed with real world BGP collector data, renders an abstraction of the acquired topology graph and translates it into a Mininet topology. In our scenario, RPKI filtering is deployed within the topology such that the testbed can later on be used to evaluate existing RPKI ROV measurement methodologies. We therefore plan to contribute an automated Mininet topology generator and insights into the accuracy of current ROV identification methodologies.

The DNS Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System (DNS), the naming system of the Internet. With DNSSEC, signatures are added to the information provided in the DNS using public key cryptography. Advances in both cryptography and cryptanalysis make it necessary to deploy new algorithms in DNSSEC, as well as deprecate those with weakened security. If this process is easy, then the protocol has achieved what the IETF terms "algorithm agility".

Anycast addressing - assigning the same IP address to multiple, distributed devices - has become a fundamental approach to improving the resilience and performance of Internet services, but its conventional deployment model makes it impossible to infer from the address itself that it is anycast. Existing methods to detect anycast IPv4 prefixes present accuracy challenges stemming from routing and latency dynamics, and efficiency and scalability challenges related to measurement load. We review these challenges and introduce a new technique we call "MAnycast2" that can help overcome them. Our technique uses a distributed measurement platform of anycast vantage points as sources to probe potential anycast destinations. This approach eliminates any sensitivity to latency dynamics, and greatly improves efficiency and scalability. We discuss alternatives to overcome remaining challenges relating to routing dynamics, suggesting a path toward establishing the capability to complete, in under 3 hours, a full census of which IPv4 prefixes in the ISI hitlist are anycast.

Anycast has become a valuable tool for network operators. It plays a vital role in making the DNS root system globally highly available and resilient to stresses from e.g. DDoS attacks. Content delivery networks use it to direct clients to local caches, and to absorb attack traffic. Yet managing an anycast network is far from simple. Earlier work studying a DDoS attack on the DNS root system, for example, shows that even highly distributed anycast networks can be overwhelmed.To manage an anycast service, it is vital to know the catchment of points of presence (PoPs) of the service. In earlier work, we introduced "Verfploeter" a novel active measurement method to determine anycast catchments using ICMP messages. Unlike previously existing approaches, Verfploeter is unbiased, accurate and can be executed directly by the anycast operator without the need for external vantage points. We demonstrated the efficacy of Verfploeter on a testbed and small anycast service.In this paper, we take the next step and deploy Verfploeter on one of the world’s largest anycast networks, the Cloudflare CDN with 192 PoPs worldwide. We perform real-world case studies on network planning (what happens when PoPs are switched on or off), troubleshooting (reachability issues of an anycasted prefix) and security (detecting spoofed attack traffic). These case studies show that Verfploeter is highly suitable for such a large-scale operation and gives operators vital insights that allow them to improve network management practices of their anycast service.

In 2009 Google launched its Public DNS service, which has since become the largest DNS service in existence. A common problem with public resolvers is that Content Delivery Networks (CDNs) struggle to map end user origin. The EDNS Client Subnet (ECS) extension allows resolvers to reveal part of a client's IP to authoritative name servers, helping CDNs pinpoint client origin. A side effect of ECS is that authoritative name server operators learn where in its network the public resolver handles queries. We leverage this side effect to study Google Public DNS (GPDNS). We perform a longitudinal analysis over data covering 2.5 years and 3.7 billion queries. Our study focuses on three aspects. First, we show that while GPDNS has PoPs in many countries, traffic is frequently routed out of country. This can reduce performance, and expose DNS requests to state level surveillance. We also show that end users are often served by a suboptimal PoP. Second, we show that end users switch to GPDNS en masse when their ISP resolver is unresponsive, and do not switch back. Finally, we also find that many e-mail providers configure GPDNS as resolver on their servers, causing serious privacy concerns due to information leakage.

Despite its critical role in Internet connectivity, the Border Gateway Protocol (BGP) remains highly vulnerable to attacks such as prefix hijacking, where an Autonomous System (AS) announces routes for IP space it does not control. To address this issue, the Resource Public Key Infrastructure (RPKI) was developed starting in 2008, with deployment beginning in 2011. This paper performs the first comprehensive, longitudinal study of the deployment, coverage, and quality of RPKI. We use a unique dataset containing all RPKI Route Origin Authorizations (ROAs) from the moment RPKI was first deployed, more than 8 years ago. We combine this dataset with BGP announcements from more than 3,300 BGP collectors worldwide. Our analysis shows the after a gradual start, RPKI has seen a rapid increase in adoption over the past two years. We also show that although misconfigurations were rampant when RPKI was first deployed (causing many announcements to appear as invalid) they are quite rare today. We develop a taxonomy of invalid RPKI announcements, then quantify their prevalence. We further identify suspicious announcements indicative of prefix hijacking and present case studies of likely hijacks. Overall, we conclude that while misconfigurations still do occur, RPKI is "ready for the big screen," and routing security can be increased by dropping invalid announcements. To foster reproducibility and further studies, we release all RPKI data and the tools we used to analyze it into the public domain.

The DNS Security Extensions (DNSSEC) add authenticity and integrity to the naming system of the Internet. Resolvers that validate information in the DNS need to know the cryptographic public key used to sign the root zone of the DNS. Eight years after its introduction and one year after the originally scheduled date, this key was replaced by ICANN for the first time in October 2018. ICANN considered this event, called a rollover, "an overwhelming success" and during the rollover they detected "no significant outages". In this paper, we independently follow the process of the rollover starting from the events that led to its postponement in 2017 until the removal of the old key in 2019. We collected data from multiple vantage points in the DNS ecosystem for the entire duration of the rollover process. Using this data, we study key events of the rollover. These events include telemetry signals that led to the rollover being postponed, a near real-time view of the actual rollover in resolvers and a significant increase in queries to the root of the DNS once the old key was revoked. Our analysis contributes significantly to identifying the causes of challenges observed during the rollover. We show that while from an end-user perspective, the roll indeed passed without major problems, there are many opportunities for improvement and important lessons to be learned from events that occurred over the entire duration of the rollover. Based on these lessons, we propose improvements to the process for future rollovers.

The domain name system (DNS) is the naming system on the Internet. With the DNS security extensions (DNSSECs) operators can protect the authenticity of their domain using public key cryptography. DNSSEC, however, can be difficult to configure and maintain: operators need to replace keys to upgrade their algorithm, react to security breaches or follow key management policies. These tasks are not trivial. If operators do not time changes to their keys right, caching resolvers may not have access to the correct keys, potentially rendering DNS zones unavailable for minutes or hours. While best current practices give abstract guidelines on how to introduce and withdraw keys, information on how to monitor and control actual rollovers in a live environment is lacking. More specifically, it is challenging for operators to know when to introduce or withdraw keys based on the state of the network. Our main contribution is to help operators answer this question and to address this barrier for deploying DNSSEC. We develop a method with which operators can monitor the replacement of DNSSEC keys, called a rollover. Thereby, they can make confident decisions during the rollover and make sure their zone stays available at all times. We validate the method with an algorithm rollover of the Swedish TLD .se and provide an open source tool with which operators can monitor their rollover themselves.

The security extensions to the DNS (DNSSEC) currently cover approximately 3% of all domains worldwide. In response to the low deployment of DNSSEC, a few top-level domains started offering 'per-domain' economic incentives to encourage adoption of the protocol by offering a yearly discount on each signed domain. However, it remains unclear whether these incentives are well-balanced and foster the overall security of the infrastructure as well as its deployment at scale. In this paper we argue that, in the presence of fixed costs of deployment, misaligned 'per-domain' incentives may have the collateral effect of encouraging large operators to massively deploy unsecure implementations of DNSSEC, whereas smaller operators, for which the effect of the economic incentive is negligible, may not significantly benefit from it. To investigate this, we study the security of DNSSEC deployment at scale, particularly in TLDs that offer economic incentives. We find that the security of DNSSEC implementations in the wild poorly reflects standard recommendations, particularly for tasks that cannot be solved by triggering a flag in the DNS software service (e.g. key rollover). Further, we find that, on average, large operators deploy weak DNSSEC security more frequently than small DNSSEC operators, suggesting that current incentives are ineffective in promoting a secure adoption and in deterring insecure implementations. We conclude the paper with actionable recommendations for TLD registry operators to improve the alignment of economic incentives with secure DNSSEC requirements.

Snowshoe spam is a type of spam that is notoriously hard to detect. Anti-abuse vendors estimate that 15% of spam can be classified as snowshoe spam. Differently from regular spam, snowshoe spammers distribute sending of spam over many hosts, in order to evade detection by spam reputation systems (blacklists). To be successful spammers need to appear as legitimate as possible, for example, by adopting email best practices, such as the Sender Policy Framework (SPF). This requires spammers to register and configure legitimate DNS domains. Many previous studies have relied on DNS data to detect spam. However, this often happens based on passive DNS data. This limits detection to domains that have actually been used and have been observed on passive DNS sensors. To overcome this limitation, we take a different approach. We make use of active DNS measurements, covering more than 60% of the global DNS namespace, in combination with machine learning to identify malicious domains crafted for snowshoe spam. Our results show that we are able to detect snowshoe spam domains with a precision of over 93%. More importantly, we are able to detect a significant fraction of the malicious domains up to 100 days earlier than existing blacklists, which suggests our method can give us a time advantage in the fight against spam. In addition to testing the efficacy of our approach in comparison to existing blacklists, we validated our approach over a 3-month period in an actual mail filter system at a major Dutch network operator. Not only did this demonstrate that our approach works in practice, the operator has actually decided to deploy our method in production, based on the results obtained.

The Domain Name System (DNS) provides a scalable, flexible name resolution service. Unfortunately, its unauthenticated architecture has become the basis for many security attacks. To address this, DNS Security Extensions (DNSSEC) were introduced in 1997. DNSSEC's deployment requires support from the top-level domain (TLD) registries and registrars, as well as participation by the organization that serves as the DNS operator. Unfortunately, DNSSEC has seen poor deployment thus far: despite being proposed nearly two decades ago, only 1% of .com, .net, and .org domains are properly signed.

The domain name system (DNS) is a core Internet infrastructure that translates names to machine-readable information, such as IP addresses. Security flaws in DNS led to a major overhaul, with the introduction of the DNS security (DNSSEC) extensions. DNSSEC adds integrity and authenticity to the DNS using digital signatures. DNSSEC, however, has its own concerns. It suffers from availability problems due to packet fragmentation and is a potent source of distributed denial-of-service attacks. In earlier work, we argued that many issues with DNSSEC stem from the choice of RSA as default signature algorithm. A switch to alternatives based on elliptic curve cryptography (ECC) can resolve these issues. Yet switching to ECC introduces a new problem: ECC signature validation is much slower than RSA validation. Thus, switching DNSSEC to ECC imposes a significant additional burden on DNS resolvers, pushing load toward the edges of the network. Therefore, in this paper, we study the question: will switching DNSSEC to ECC lead to problems for DNS resolvers, or can they handle the extra load? To answer this question, we developed a model that accurately predicts how many signature validations DNS resolvers have to perform. This allows us to calculate the additional CPU load ECC imposes on a resolver. Using real-world measurements from four DNS resolvers and with two open-source DNS implementations, we evaluate future scenarios where DNSSEC is universally deployed. Our results conclusively show that switching DNSSEC to ECC signature schemes does not impose an insurmountable load on DNS resolvers, even in worst case scenarios.

The Domain Name System Security Extensions (DNSSEC) are steadily being deployed across the Internet. DNSSEC extends the DNS protocol with two vital security properties, authenticity and integrity, using digital signatures. While DNSSEC is meant to solve security issues in the DNS, it also introduces a new one: the digital signatures significantly increase DNS packet sizes, making DNSSEC an attractive vector to abuse in amplification denial-of-service attacks. By default, DNSSEC uses RSA for digital signatures. Earlier work has shown that alternative signature schemes, based on elliptic curve cryptography, can significantly reduce the impact of signatures on DNS response sizes. In this paper we study the actual adoption of ECDSA by DNSSEC operators, based on longitudinal datasets covering over 50% of the global DNS namespace over a period of 1.5 years. Adoption is still marginal, with just 2.3% of DNSSEC-signed domains in the .com TLD using ECDSA. Nevertheless, use of ECDSA is growing, with at least one large operator leading the pack. And adoption could be up to 42% higher. As we demonstrate, there are barriers to deployment that hamper adoption. Operators wishing to deploy DNSSEC using current recommendations (with ECDSA as signing algorithm) must be mindful of this when planning their deployment.

The domain name system (DNS) is a core component of the Internet. It performs the vital task of mapping human readable names into machine readable data (such as IP addresses, which hosts handle e-mail, and so on). The content of the DNS reveals a lot about the technical operations of a domain. Thus, studying the state of large parts of the DNS over time reveals valuable information about the evolution of the Internet. We collect a unique long-term data set with daily DNS measurements for all the domains under the main top-level domains (TLDs) on the Internet (including .com, .net, and .org, comprising 50% of the global DNS name space). This paper discusses the challenges of performing such a large-scale active measurement. These challenges include scaling the daily measurement to collect data for the largest TLD (.com, with 123M names) and ensuring that a measurement of this scale does not impose an unacceptable burden on the global DNS infrastructure. The paper discusses the design choices we have made to meet these challenges and documents the design of the measurement system we implemented based on these choices. Two case studies related to cloud e-mail services illustrate the value of measuring the DNS at this scale. The data this system collects is valuable to the network research community. Therefore, we end this paper by discussing how we make the data accessible to other researchers.

In 2012, the Dutch National Research and Education Network, SURFnet, observed a multitude of Distributed Denial of Service (DDoS) attacks against educational institutions. These attacks were effective enough to cause the online exams of hundreds of students to be cancelled. Surprisingly, these attacks were purchased by students from Web sites, known as Booters. These sites provide DDoS attacks as a paid service (DDoS-as-a-Service) at costs starting from 1 USD. Since this problem was first identified by SURFnet, Booters have been used repeatedly to perform attacks on schools in SURFnet's constituency. Very little is known, however, about the characteristics of Booters, and particularly how their attacks are structure. This is vital information needed to mitigate these attacks. In this paper we analyse the characteristics of 14 distinct Booters based on more than 250 GB of network data from real attacks. Our findings show that Booters pose a real threat that should not be underestimated, especially since our analysis suggests that they can easily increase their firepower based on their current infrastructure.

The Domain Name System (DNS) is part of the core infrastructure of the Internet. Tracking changes in the DNS over time provides valuable information about the evolution of the Internet's infrastructure. Until now, only one large-scale approach to perform these kinds of measurements existed, passive DNS (pDNS). While pDNS is useful for applications like tracing security incidents, it does not provide sufficient information to reliably track DNS changes over time. We use a complementary approach based on active measurements, which provides a unique, comprehensive dataset on the evolution of DNS over time. Our high-performance infrastructure performs Internet-scale active measurements, currently querying over 50% of the DNS name space on a daily basis. Our infrastructure is designed from the ground up to enable big data analysis approaches on, e.g., a Hadoop cluster. With this novel approach we aim for a quantum leap in DNS-based measurement and analysis of the Internet.

Over the past five years we have witnessed the introduction of DNSSEC, a security extension to the DNS that relies on digital signatures. DNSSEC strengthens DNS by preventing attacks such as cache poisoning. However, a common argument against the deployment of DNSSEC is its potential for abuse in Distributed Denial of Service (DDoS) attacks, in particular reflection and amplification attacks. DNS responses for a DNSSEC-signed domain are typically larger than those for an unsigned domain, thus, it may seem that DNSSEC could actually worsen the problem of DNS-based DDoS attacks. The potential for abuse in DNSSEC-signed domains has, however, never been assessed on a large scale.