Figure 1 - uploaded by Zhou Li
Content may be subject to copyright.
Source publication
DNS is a critical service for almost all Internet applications. DNS queries from end users are handled by recursive DNS servers for scalability. For convenience, Internet Service Providers (ISPs) assign recursive servers for their clients automatically when the clients choose the default network settings. On the other hand, users should also have t...
Contexts in source publication
Context 1
... a client requests resolution of a domain, the res- olution is typically executed by a recursive DNS resolver at first, which can be either assigned by ISP or specified by Internet users. Illustrated in Figure 1, the recursive resolver iteratively contacts root, TLD and SLD name- servers to resolve a domain name, and eventually returns the answer to the client. Therefore, intercepting DNS traffic to a recursive resolver directly affects the domain resolution process for users. ...
Context 2
... total, out-of-band requests of 14,590 reso- lutions (84.63%, of 17,239 replicated requests) arrive at our authoritative nameservers faster than in-band ones. Zooming into ASes, Figure 10 presents the top 10 ASes with most replicated requests to Google. While repli- cated requests from most ASes arrive faster, in AS4812 (China Telecom Group), all out-of-band requests lag be- hind. ...
Context 3
... illustrated in Section 3.2, TTL values re- turned by our authoritative nameservers are randomly se- lected from 1 to 86400. However, for our clients, we find that about 20% of the TTL values are replaced, mostly with a smaller value, as shown in Figure 11(a). By scat- tering each request onto Figure 11(b), we find that there are preferred values for modified TTL, such as 1800, 3600 and 7200. ...
Citations
... However, our study reveals that a significant number of transparent proxies deviate from this standard. These proxies perform DNS resolutions to obtain the destination IP address but ignore the destination IP address in the request, leading to privacy and security risks similar to the case of DNS resolution interception presented in [35]. Transparent proxy administrators should exercise great caution when configuring the proxy server to avoid unintended consequences. ...
Transparent web proxies have been widely deployed on the Internet, bridging the communications between clients and servers and providing desirable benefits to both sides, such as load balancing, security monitoring, and privacy enhancement. Meanwhile, they work silently as clients and servers may not be aware of their existence. However, due to their invisibility and stealthiness, transparent proxies remain understudied for their behaviors, suspicious activities, and potential vulnerabilities that could be exploited by attackers. To better understand transparent proxies, we design and develop a framework to systematically investigate them in the wild. We identify two major types of transparent web proxies, named FDR and CPV, respectively. FDR is a type of transparent proxy that independently performs Forced DNS Resolution during interception. CPV is a type of transparent proxy that presents Cache Poisoning Vulnerability. We perform a large-scale measurement to detect each type of transparent web proxy and scrutinize their security implications. In total, we observe 32,246 FDR and 11,286 CPV cases through our acquired vantage points. We confirm that these two types of transparent proxies are distributed globally-FDRs are observed in 98 countries and CPVs are observed in 51 countries. Our work highlights the issues of vulnerable transparent proxies and provides insights for mitigating such problems.
... For open resolvers distributed in the Internet, attackers can directly send DNS queries targeting the resolver from any location [101]. For DNS resolvers that serve limited networks, such as those located in home or enterprise networks, attackers can collect vantage points from large-scale measurement platforms [99] or residential proxy networks [73], [79] to generate DNS queries. For stub resolvers, an attacker can employ online advertisements and spam emails that embed the attacker's controlled domain and direct clients to launch DNS queries. ...
... • DNSCONSUMING circumvents query-limits and renders resolvers to consume more CPU resources like [4], since one attack query could trigger such as 100 resolver queries (see Section 5.3). Although DNSCON-SUMING requires on-path attackers, these attackers have limited packet operating capabilities and can only control their own domains to send responses and trigger vulnerabilities, in contrast to traditional on-path packet interception that can observe and modify all packets except those sent to their own nameservers [73]. ...
DNS can be compared to a game of chess in that its rules are simple, yet the possibilities it presents are endless. While the fundamental rules of DNS are straightforward, DNS implementations can be extremely complex. In this study, we intend to explore the complexities and vulnerabilities in DNS response pre-processing by systematically analyzing DNS RFCs and DNS software implementations. We present the discovery of three new types of logic vulnerabilities, leading to the proposal of three novel attacks, namely the TuDoor attack. These attacks involve the use of malformed DNS response packets to carry out DNS cache poisoning, denial-of-service, and resource consuming attacks. By performing comprehensive experiments, we demonstrate the attack's feasibility and significant real-world impacts of TuDoor. In total, 24 mainstream DNS software, including BIND, PowerDNS, and Microsoft DNS, are affected by TuDoor. Attackers can instigate cache poisoning and denial-of-service attacks against vulnerable resolvers using a handful of crafted packets within 1 second or circumvent the query limit to deplete resolution resources (e.g., CPU). Besides, to determine the vulnerable resolver population in the wild, we collect and evaluate 16 popular Wi-Fi routers, 6 prevalent router OSes, 42 public DNS services, and around 1.8M open DNS resolvers. Our measurement results indicate that TuDoor could exploit 7 routers (OSes), 18 public DNS services, and 424,652 (23.1%) open DNS resolvers. Following the best practice of responsible disclosure, we have reported these vulnerabilities to all affected vendors, and 18 of them, including BIND, Chrome, Cloudflare, and Microsoft, have acknowledged our findings and discussed mitigation solutions with us. Furthermore, 33 CVE IDs are assigned to our discovered vulnerabilities, and we provide an online detection tool as one of the mitigation measures. Our research highlights the urgent need for standardization of DNS response pre-processing logic to enhance the security of DNS.
... The Domain Name System (DNS) provides translation between human-readable domain names and numerical addresses and is relied on by many fundamental Internet security mechanisms such as certificate issuance [95], email authentication [84,92], and malicious domain takedown [5]. Unfortunately, almost all DNS messages are designed to be sent unencrypted, which are vulnerable to manipulation [63]. ...
... We find that, although not being studied by prior works systemically, CDNSes have been extensively used in practice. Enterprises or ISPs may use them for access control [7], speeding up domain resolution [90], and reducing operational cost (e.g., to reduce out-of-band traffic [63]). In Section 6.3, we interviewed two ISPs to get an in-depth understanding of how CDNS is used. ...
In this paper, we report MaginotDNS, a powerful cache poisoning attack against DNS servers that simultaneously act as recursive resolvers and forwarders (termed as CDNS). The attack is made possible through exploiting vulnerabilities in the bailiwick checking algorithms, one of the cornerstones of DNS security since the 1990s, and affects multiple versions of popular DNS software, including BIND and Microsoft DNS. Through field tests, we find that the attack is potent, allowing attackers to take over entire DNS zones, even including Top-Level Domains (e.g., .com and .net). Through a large-scale measurement study, we also confirm the extensive usage of CDNSes in real-world networks (up to 41.8% of our probed open DNS servers) and find that at least 35.5% of all CDNSes are vulnerable to MaginotDNS. After interviews with ISPs, we show a wide range of CDNS use cases and real-world attacks. We have reported all the discovered vulnerabilities to DNS software vendors and received acknowledgments from all of them. 3 CVE-ids have been published, and 2 vendors have fixed their software. Our study brings attention to the implementation inconsistency of security checking logic in different DNS software and server modes (i.e., recursive resolvers and forwarders), and we call for standardization and agreements among software vendors.
... Also, the DNS is one of the most numerous Internet servers. For handling the response of thirty millions of DNS servers, we use scalable open source software of Libevent [8] and MongoDB [14]. Figure 2 depicts the overview of our system. ...
... Pearce et al. [17] present new patterns in DNS manipulations by Iris, which is a scalable method to measure global DNS resolutions. Liu et al. [14] perform a large-scale analysis of on-path DNS interception handled by recursive DNS servers. They leverage 148,378 residential and cellular IP addresses. ...
Recently, TI (Threat Intelligence) has acquired a significant presence in cyber security. A common form of TI is IoC (an indicator of compromise). This paper presents a novel application of geospatial analysis to refine IoC further. First, we cope with open-source IoC of Russian malicious cyber activity. In the first phase of analysis, we detected 30,285,322 DNS servers on the Internet and measured the geospatial distance between the DNS server and each IP address of IoC. By doing this, we can expose the nearest DNS servers to IP addresses in IoC. Second, based on the first phase result, we compared the distance of the DNS server and gateway ISP detected by tracer-oute. Among 294 IP addresses of IoC, We have detected 104 DNS servers nearer than the gateway ISP, which is helpful for the classification of IoC. Finally, we have characterized IP addresses in IoC by three distance ranges (0-400, 400-800, and 800-1200km). We have found that the distance range is informative for characterizing IP addresses of IoC. Furthermore, experimental results demonstrate apparent features of communication line usage type (such as Fixed Line and Web Hosting) by three distance ranges. We believe these three kinds of insights will shed new light on further refinement of the indicator of compromise .
... A large body of work exists on measuring and analyzing the client-side DNS infrastructure. Several researchers measured the population of open resolvers using an Internet-wide active measurement method over the past decades and discussed the malicious behavior of open resolvers and the structure of the client-side DNS infrastructure [11][12][13][14][15][16][17]. For example, Alzoubi et al. [14] proposed the LDNS by presenting a large-scale measurement of hosts sharing the same local DNS servers. ...
The centralization of the global DNS ecosystem may accelerate the creation of an oligopoly market, thereby, increasing the risk of a single point of failure and network traffic manipulation. Earlier studies have revealed the level of centralization in terms of the market share of public DNS services and DNS traffic seen by major CDN providers. However, the level of centralization in the infrastructure of the DNS Ecosystem is not well understood. In this paper, we present a novel and lightweight measurement approach that effectively discovers resolver pools from a single probing point. We conduct an Internet-wide active measurement on the client-side as well as the server-side DNS infrastructure to assess the level of DNS centralization in terms of the supporting infrastructure. Our measurement results show that the DNS infrastructure is much more centralized than previously believed. Over 90% of forwarding resolvers are backed by less than 5% (4071) of indirect resolvers. Merely 0.45% (12,679) of all name servers across 1138 gTLDs, operated by just 10 DNS providers, provide authoritative domain resolution service for 48.5% (more than 100 million) of domain names. We also investigated several leading DNS providers in IP infrastructure, load distribution, and service geo-distribution. The findings of our measurements provide novel insights into the centrality of the DNS infrastructure, which will help the Internet community promote the understanding of the DNS ecosystem.
... Importantly, they do not inject spoofed responses, but rather let those alternative resolvers respond to end clients directly. More intrusive DNS interceptors, such as national censors, impersonate intended query destinations and actively inject bogus responses [38]. DNS interception is often accomplished at Customer Premises Equipment [51] and can be detected by issuing CHAOS-class or other DNS queries with the NSID option enabled. ...
... More broadly, various types of DNS manipulation have been extensively studied in the literature. Censors [7,23,27,[46][47][48]50,57,58], transparent forwarders [33,45], rogue DNS servers [19], and middleboxes [16,38,51,60,61]-all interfere with the normal DNS resolution process. Particular attention has been paid to the GFW of China [3][4][5]11,22,28,39], known to intercept DNS traffic and inject bogus responses. ...
DNS is a protocol responsible for translating human-readable domain names into IP addresses. Despite being essential for many Internet services to work properly, it is inherently vulnerable to manipulation. In November 2021, users from Mexico received bogus DNS responses when resolving whatsapp.net. It appeared that a BGP route leak diverged DNS queries to the local instance of the k-root located in China. Those queries, in turn, encountered middleboxes that injected fake DNS responses. In this paper, we analyze that event from the RIPE Atlas point of view and observe that its impact was more significant than initially thought—the Chinese root server instance was reachable from at least 15 countries several months before being reported. We then launch a nine-month longitudinal measurement campaign using RIPE Atlas probes and locate 11 probes outside China reaching the same instance, although this time over IPv6. More broadly, motivated by the November 2021 event, we study the extent of DNS response injection when contacting root servers. While only less than 1% of queries are impacted, they originate from 7% of RIPE Atlas probes in 66 countries. We conclude by discussing several countermeasures that limit the probability of DNS manipulation.
... Theoretically, an attacker can keep the malicious DNS answer in the cache for a very long time by setting a tremendous TTL value (2 31 −1 seconds, around 68 years). However, previous research has shown that most recursive resolvers may not strictly comply with the TTL mechanism [83], [96], [123], and DNS operators might adopt a maximum TTL limitation [22], [73], [113], [141]. As a result, resolvers can overwrite the original TTL value when it exceeds the maximum value allowed. ...
In this paper, we propose Phoenix Domain, a general and novel attack that allows adversaries to maintain the revoked malicious domain continuously resolvable at scale, which enables an old, mitigated attack, Ghost Domain. Phoenix Domain has two variations and affects all mainstream DNS software and public DNS resolvers overall because it does not violate any DNS specifications and best security practices. The attack is made possible through systematically “reverse engineer” the cache operations of 8 DNS implementations, and new attack surfaces are revealed in the domain name delegation processes. We select 41 well-known public DNS resolvers and prove that all surveyed DNS services are vulnerable to Phoenix Domain, including Google Public DNS and Cloudflare DNS. Extensive measurement studies are performed with 210k stable and distributed DNS recursive resolvers, and results show that even after one month from domain name revocation and cache expiration, more than 25% of recursive resolvers can still resolve it. The proposed attack provides an opportunity for adversaries to evade the security practices of malicious domain take-down. We have reported discovered vulnerabilities to all affected vendors and suggested 6 types of mitigation approaches to them. Until now, 7 DNS software providers and 15 resolver vendors, including BIND, Unbound, Google, and Cloudflare, have confirmed the vulnerabilities, and some of them are implementing and publishing mitigation patches according to our suggestions. In addition, 9 CVE numbers have been assigned. The study calls for standardization to address the issue of how to revoke domain names securely and maintain cache consistency.
... Currently, there are 13 root servers worldwide [2]. To relieve the resolution pressure on the root servers, improve the resolution capability and Internet access experience in all regions of the world, as well as reduce DNS attacks [3][4][5]30], the 13 root servers deploy a large number of root instances using anycast [6,21,26]. All root servers update the duplicate root zone data files synchronously. ...
DNS root servers are located at the top of the domain name system and are the cornerstone of the Internet. Currently, root servers deploy numerous root instances using anycast technology. Introducing root instances can improve the parsing performance of root servers and the user access experience. However, we found that some root instances do not show optimal performance, and users cannot access the closest root instance when accessing the root instance or even cross-border access. This paper deploys three types of operator detection points in 31 provincial-level administrative regions in mainland China. Each detection point requests the NS record of the top-level domain name from the root instance server introduced in China to obtain the access data of the root instance server hit by domestic users. At the same time, we propose two methods to determine whether users have achieved the optimal choice of root instance, including the method based on the shortest AS path and the method based on geographical distance. In these two methods, we analyze the optimal selection of root instances for each root server. Finally, we analyze the cross-border access of users and find that China Telecom users are more likely to access the root instance across borders.
... Some papers measure which resolvers are used by introducing observer-controlled authoritative servers and zones. These are combined with advertisement campaigns [22], visits to selfowned websites [23] or a large number of remotely controlled clients in various world regions that send DNS requests [24]. Approaches relying on data from browsers or the installation of specific apps will not capture any traffic from unsupported device types, such as IoT devices, home routers etc., which is central to our paper. ...
DNS hijacking represents a security threat to users because it enables bypassing existing DNS security measures. Several malware families exploit this by changing the client DNS configuration to point to a malicious DNS resolver. Following the assumption that users will never actively choose to use a resolver that is not well-known, our paper introduces the idea of detecting client-based DNS hijacking by classifying public resolvers based on whether they are well-known or not. Furthermore, we propose to use NetFlow-based features to classify a resolver as well-known or malicious. By characterizing and manually labelling the 405 resolvers seen in four weeks of NetFlow data from a national ISP, we show that classification of both well-known and malicious servers can be made with an AUROC of 0.85.
... In a large-scale survey by Chung et al. in 2017 [28], 88% of all DNSSEC-enabled recursive DNS resolvers returned supposedly DNSSEC-verified responses, without actually verifying the certificate chain. If the certificate chain from the DNS root certificate is not verified before an entry is cached, then DNSSEC does not provide any security and is vulnerable to the same attacks as regular DNS, while Fig. 3. DNS is a prime example of the benefits of PILA as it is (1) unauthenticated, (2) interception and redirection of requests are widespread [29], and (3) DNS servers are mostly identified by their local end-host, i.e., IP, addresses. It is important to note that DNS PILA operates between the client and resolver, unlike DNSSEC, where authoritative nameservers publish DNSSEC entries which are distributed by resolvers. ...
In a world with increasing simplicity to store, transfer, and analyze large volumes of data, preserving data confidentiality and integrity of Internet traffic by default becomes more and more important. Unfortunately, a large gap exists between low-security opportunistic encryption and trust-on-first-use (TOFU) protocols, and high-security communication, such as TLS using server certificates or DNSSEC. Our goal is to reduce this gap and provide a base layer for authentication and secrecy that is strictly better than TOFU security. We achieve this by integrating the authentication method PILA into the future Internet architecture SCION. This combines PILA’s address-based authentication, which leverages irrefutable cryptographic proof of misbehavior, and the flexibility of SCION’s control-plane PKI and its per-AS independent addressing scheme. In this work, two concrete issues of PILA are addressed: (1) the reliance on the hierarchical RPKI which introduces a single global trust root, i.e., a single point of failure regarding the security of PILA, and (2) the necessity of an out-of-band communication to prevent downgrade attacks, which can incur a latency overhead and might be used as a resource exhaustion attack vector. We describe how PILA in combination with SCION mitigates these issues and analyze the security of the system. Finally, we discuss several interesting use cases including the SSH, TLS, and DNS protocols.
