Subscribe to the gold package and get unlimited access to Shamra Academy
Register a new userOblivious DNS: Practical Privacy for DNS Queries
106
0
0.0
(
0
)
Added by
Paul Schmitt
Publication date
2018
fields
Informatics Engineering
and research's language is
English
Ask ChatGPT about the research
No Arabic abstract
Virtually every Internet communication typically involves a Domain Name System (DNS) lookup for the destination server that the client wants to communicate with. Operators of DNS recursive resolvers---the machines that receive a clients query for a domain name and resolve it to a corresponding IP address---can learn significant information about client activity. Past work, for example, indicates that DNS queries reveal information ranging from web browsing activity to the types of devices that a user has in their home. Recognizing the privacy vulnerabilities associated with DNS queries, various third parties have created alternate DNS services that obscure a users DNS queries from his or her Internet service provider. Yet, these systems merely transfer trust to a different third party. We argue that no single party ought to be able to associate DNS queries with a client IP address that issues those queries. To this end, we present Oblivious DNS (ODNS), which introduces an additional layer of obfuscation between clients and their queries. To do so, ODNS uses its own authoritative namespace; the authoritative servers for the ODNS namespace act as recursive resolvers for the DNS queries that they receive, but they never see the IP addresses for the clients that initiated these queries. We present an initial deployment of ODNS; our experiments show that ODNS introduces minimal performance overhead, both for individual queries and for web page loads. We design ODNS to be compatible with existing DNS protocols and infrastructure, and we are actively working on an open standard with the IETF.
rate research
Read More
The Domain Name System (DNS) was created to resolve the IP addresses of the web servers to easily remembered names. When it was initially created, security was not a major concern; nowadays, this lack of inherent security and trust has exposed the global DNS infrastructure to malicious actors. The passive DNS data collection process creates a database containing various DNS data elements, some of which are personal and need to be protected to preserve the privacy of the end users. To this end, we propose the use of distributed ledger technology. We use Hyperledger Fabric to create a permissioned blockchain, which only authorized entities can access. The proposed solution supports queries for storing and retrieving data from the blockchain ledger, allowing the use of the passive DNS database for further analysis, e.g. for the identification of malicious domain names. Additionally, it effectively protects the DNS personal data from unauthorized entities, including the administrators that can act as potential malicious insiders, and allows only the data owners to perform queries over these data. We evaluated our proposed solution by creating a proof-of-concept experimental setup that passively collects DNS data from a network and then uses the distributed ledger technology to store the data in an immutable ledger, thus providing a full historical overview of all the records.
Virtually every connection to an Internet service is preceded by a DNS lookup which is performed without any traffic-level protection, thus enabling manipulation, redirection, surveillance, and censorship. To address these issues, large organizations such as Google and Cloudflare are deploying recently standardized protocols that encrypt DNS traffic between end users and recursive resolvers such as DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH). In this paper, we examine whether encrypting DNS traffic can protect users from traffic analysis-based monitoring and censoring. We propose a novel feature set to perform the attacks, as those used to attack HTTPS or Tor traffic are not suitable for DNS characteristics. We show that traffic analysis enables the identification of domains with high accuracy in closed and open world settings, using 124 times less data than attacks on HTTPS flows. We find that factors such as location, resolver, platform, or client do mitigate the attacks performance but they are far from completely stopping them. Our results indicate that DNS-based censorship is still possible on encrypted DNS traffic. In fact, we demonstrate that the standardized padding schemes are not effective. Yet, Tor -- which does not effectively mitigate traffic analysis attacks on web traffic -- is a good defense against DoH traffic analysis.
DNS is a vital component for almost every networked application. Originally it was designed as an unencrypted protocol, making user security a concern. DNS-over-HTTPS (DoH) is the latest proposal to make name resolution more secure. In this paper we study the current DNS-over-HTTPS ecosystem, especially the cost of the additional security. We start by surveying the current DoH landscape by assessing standard compliance and supported features of public DoH servers. We then compare different transports for secure DNS, to highlight the improvements DoH makes over its predecessor, DNS-over-TLS (DoT). These improvements explain in part the significantly larger take-up of DoH in comparison to DoT. Finally, we quantify the overhead incurred by the additional layers of the DoH transport and their impact on web page load times. We find that these overheads only have limited impact on page load times, suggesting that it is possible to obtain the improved security of DoH with only marginal performance impact.
In spite of the availability of DNSSEC, which protects against cache poisoning even by MitM attackers, many caching DNS resolvers still rely for their security against poisoning on merely validating that DNS responses contain some unpredictable values, copied from the re- quest. These values include the 16 bit identifier field, and other fields, randomised and validated by different patches to DNS. We investigate the prominent patches, and show how attackers can circumvent all of them, namely: - We show how attackers can circumvent source port randomisation, in the (common) case where the resolver connects to the Internet via different NAT devices. - We show how attackers can circumvent IP address randomisation, using some (standard-conforming) resolvers. - We show how attackers can circumvent query randomisation, including both randomisation by prepending a random nonce and case randomisation (0x20 encoding). We present countermeasures preventing our attacks; however, we believe that our attacks provide additional motivation for adoption of DNSSEC (or other MitM-secure defenses).
We investigate defenses against DNS cache poisoning focusing on mechanisms that can be readily deployed unilaterally by the resolving organisation, preferably in a single gateway or a proxy. DNS poisoning is (still) a major threat to Internet security; determined spoofing attackers are often able to circumvent currently deployed antidotes such as port randomisation. The adoption of DNSSEC, which would foil DNS poisoning, remains a long-term challenge. We discuss limitations of the prominent resolver-only defenses, mainly port and IP randomisation, 0x20 encoding and birthday protection. We then present two new (unilateral) defenses: the sandwich antidote and the NAT antidote. The defenses are simple, effective and efficient, and can be implemented in a gateway connecting the resolver to the Internet. The sandwich antidote is composed of two phases: poisoning-attack detection and then prevention. The NAT antidote adds entropy to DNS requests by switching the resolvers IP address to a random address (belonging to the same autonomous system). Finally, we show how to implement the birthday protection mechanism in the gateway, thus allowing to restrict the number of DNS requests with the same query to 1 even when the resolver does not support this.
Log in to be able to interact and post comments
comments
Fetching comments
Sign in to be able to follow your search criteria
