How to hide DNS queries from the prying eyes of the provider
Configuring 184.108.40.206 from Cloudflare and other DNS services still requires command line skills
Encryption of traffic between your device and the DNS service will prevent unauthorized persons from monitoring traffic or changing the address. The
death of network neutrality and the weakening of the rules for Internet providers to process network traffic have caused many concerns about privacy. Providers (and other unauthorized persons who monitor the passing traffic) have long had a tool that makes it easy to track the behavior of people on the Internet: these are their domain name servers (DNS). Even if they still haven’t monetized this data (or replaced traffic), they will probably start soon.
DNS is a Network telephone directory that provides the actual network IP address associated with hosting and domain names for sites and other Internet services. For example, it turns arstechnica.com into 220.127.116.11. Your ISP offers DNS in a service package, but it can also log DNS traffic - in fact, record the history of your actions on the Internet.
“Open” DNS services allow you to bypass the services of providers for the sake of confidentiality and security, and in some countries to avoid filtering content, surveillance and censorship. April 1 (no joke) Cloudflare launched its new, free and high-performance DNS-service, designed to increase user privacy on the Internet. He also promises to completely hide DNS traffic from prying eyes, using encryption.
Named for its IP address, service 18.104.22.168 is the result of a partnership with the APNIC research group, the Asia-Pacific Network Information Center, one of the five regional Internet registrars. Although it is also available as an “open” regular DNS resolver (and very fast), Cloudflare also supports two DNS encryption protocols.
Although developed with some unique “goodies” from Cloudflare, 22.214.171.124 is by no means the first DNS service with encryption. Successfully work Quad9, Cisco’s OpenDNS, Google’s 126.96.36.199 service and many smaller services with support for various DNS encryption schemes. But encryption does not necessarily mean that your traffic is invisible: some encrypted DNS services still log your requests to the log for various purposes.
Cloudflare promised not to log DNS traffic and hired a third-party audit firm. APNIC's Jeff Huston said APNIC intends to use the data for research purposes : ranges 188.8.131.52/24 and 184.108.40.206/24 were initially configured as addresses for black traffic. But APNIC will not gain access to encrypted DNS traffic.
For users, connecting DNS encryption is not as simple as changing the address in the network settings. Currently, no OS directly supports DNS encryption without additional software. And not all services are the same in terms of software and performance.
But given the importance of the issue - recently, all the news has been talking about turning user data into a product - I decided to see how Cloudflare's DNS encryption works. As a result, my internal laboratory rat won - and I found that I was testing and disassembling clients for several DNS providers through three DNS encryption protocols: DNSCrypt, DNS over TLS, and DNS over HTTPS. All of them are functional, but I warn you: although the procedure becomes simpler, it is unlikely that you can explain the encryption of DNS to parents over the phone (unless they are experienced Linux command-line users).
How DNS works
Why are we doing this?
There are many reasons for better protection of DNS traffic. Although web traffic and other communications can be protected by cryptographic protocols such as Transport Layer Security (TLS), almost all DNS traffic is transmitted unencrypted. This means that your provider (or someone else between you and the Internet) can register the sites you visit even when working through a third-party DNS - and use this data to your advantage, including filtering content and collecting data for advertising purposes.
What does a typical data exchange between the device and the DNS resolver look like?
“We have a“ last mile ”problem in the DNS,” said Cricket Liu, chief DNS architect at Infoblox, an information security company. - Most of our security mechanisms address the issues of communication between servers. But there is a problem with surrogates for resolvers on various operating systems. In reality, we cannot protect them. ” The problem is especially noticeable in countries where authorities are more hostile to the Internet.
To some extent, the use of DNS, which does not maintain logs, helps. But all the same, this does not prevent the attacker from filtering requests by content or intercepting addresses using packet interception or deep packet inspection. In addition to passive wiretapping, there is a threat of more active attacks on your DNS traffic - spoofing of the DNS server by the provider or special services with redirection to your own server to monitor or block traffic. Something similar (though apparently not maliciously) seems to be happening with a random redirection of traffic to 220.127.116.11 from the AT&T network , judging by the posts on the DSLReports forums.
The most obvious way to evade snooping is to use a VPN. But while VPNs hide the contents of your traffic, you may need a DNS query to connect to a VPN. And during a VPN session, DNS queries can also sometimes be routed by web browsers or other software outside the VPN tunnel, creating "DNS leaks" that reveal the sites visited.
This is where the DNS encryption protocols come into play: DNSCrypt (among others, it is supported by Cisco's OpenDNS), TLS DNS (supported by Cloudflare, Google, Quad9, OpenDNS) and HTTPS DNS (supported by Cloudflare, Google and the “adult” blocking service CleanBrowsing Content) Encryption ensures that the traffic is not scanned and not changed, and that the fake DNS server does not receive or process requests. This protects against MiTM attacks and spying. A DNS proxy from one of these services (directly on the device or on a “server” in the local network) will help prevent DNS leaks through the VPN, since the proxy server will always be the fastest DNS server available.
However, this security option is not available to the mass user. None of these protocols is natively supported by any DNS resolver that comes bundled with the OS. All of them require the installation (and probably compilation) of a client application that acts as a local DNS “server”, relaying requests made by browsers and other applications upstream to the secure DNS provider of your choice. And although two of the three of these technologies are proposed for the role of standards, none of the options we tested are yet to be presented in their final form.
Therefore, if you want to immerse yourself in DNS encryption, it is better to take a Raspberry Pi or other separate device for the DNS server in the home network. Because you will probably find that setting up one of these clients is already enough hacking to not want to repeat the process again. It is easier to request DHCP settings on the local network - and point all computers to one successful installation of the DNS server. I repeated this to myself many times during testing, observing the fall of clients one by one under Windows and the immersion in hibernation of clients under MacOS.
The DNSCrypt community has tried to make an affordable tool available for those without command line skills by releasing DNSCloak (left) for iOS and Simple DNSCrypt (right) for Windows
For the sake of completeness, in a historical perspective, we begin the review with the very first DNS encryption technology - DNSCrypt. First introduced in 2008 at BSD Unix, the DNSCrypt tool was originally designed to protect against DNS spoofing rather than wiretapping. However, it can be used as part of a confidentiality system - especially in combination with a log-free DNS server. According to Frank Denis, DNSCrypt developer, many more servers support DNSCrypt than any other type of DNS encryption.
“DNSCrypt is a little more than just a protocol,” says Frank Denis. “Now the community and active projects characterize it much better than my original protocol, developed over the weekend.” The DNSCrypt community has created easy-to-use clients such asSimple DNSCrypt for Windows and a client for Apple iOS called DNS Cloak , which makes DNS encryption more accessible to non-technical people. Other activists have raised an independent network of private DNS servers based on a protocol that helps users evade the use of corporate DNS systems.
“DNSCrypt is not a connection to the servers of a particular company,” Denis said. - We urge everyone to raise their own servers. To do this is very cheap and easy. Now that we have secure resolvers, I’m trying to solve the problem of filtering content based on confidentiality. ”
For those who want to run a DNS server with DNSCrypt support for their entire network, DNSCrypt Proxy 2 is the best client.. The old version of DNSCrypt Proxy is still available as a package for most major Linux distributions, but it is better to download the new version binary directly from the official repository on GitHub. There are versions for Windows, MacOS, BSD and Android.
The privacy experience of the DNSCrypt community is embodied in the DNSCrypt Proxy. The program is easy to configure, supports access time limits, domain templates and a blacklist of IP addresses, a query log and other functions of a fairly powerful local DNS server. But to get started, the most basic configuration is enough. There is an example configuration file in TOML format ( Tom's Obvious Minimal Languagecreated by GitHub co-founder Tom Preston-Werner). You can simply rename it before starting DNSCrypt Proxy - and it will become a working configuration file.
For my DNSCrypt testing, I used Cisco's OpenDNS as a remote DNS service. At the first queries, the performance of DNSCrypt turned out to be slightly worse than that of ordinary DNS, but then DNSCrypt Proxy caches the results. The slowest requests were processed in the 200 ms region, while the average ones took about 30 ms. (Your results may vary depending on the provider, recursion when searching for a domain, and other factors). In general, I did not notice a slowdown when browsing the web.
The main advantage of DNSCrypt is that it looks like a “normal” DNS. For better or worse, it transmits UDP traffic on port 443 — the same port is used for secure web connections. This gives a relatively quick address resolution and reduces the likelihood of blocking on the provider's firewall. To further reduce the likelihood of blocking, you can reconfigure the client and send requests over TCP / IP (as testing has shown, this minimally affects the response time). So encrypted DNS traffic for most network filters is similar to HTTPS traffic - at least in appearance.
DNSCrypt traffic and local DNSCrypt Proxy traffic are shown. Sniffer Wireshark says it's HTTPS traffic because I forced TCP usage. If you let it through UDP, then Wireshark will see Chrome QUIC traffic
On the other hand, DNSCrypt does not rely on trusted certificate authorities for encryption - the client must trust the public signature key issued by the provider. This signature key is used to verify certificates that are retrieved using regular (unencrypted) DNS queries and are used to exchange keys using the X25519 key exchange algorithm . In some (older) DNSCrypt implementations, there is a condition for a client-side certificate that can be used as an access control scheme. This allows them to log your traffic no matter what IP address you came from and associate it with your account. Such a scheme is not used in DNSCrypt 2.
From a developer's point of view, it’s a little difficult to work with DNSCrypt. “DNSCrypt is not particularly well documented, and there are not many implementations of it,” says Infoblox Cricket Liu. In fact, we could only find the only client in active development - it is DNSCrypt Proxy, and OpenDNS stopped supporting its development.
An interesting choice of cryptography in DNSCrypt may scare some developers. The protocol uses Curve25519 (RFC 8032), X25519 (RFC 8031) and Chacha20Poly1305 (RFC 7539). One implementation of the X24419 algorithm in Pyca Python cryptographic librariesmarked as "cryptographically dangerous" because it is very easy to make a mistake with the settings. But the main cryptographic algorithm used by Curve25519 is “one of the simplest elliptic curves for safe use,” Denis said.
The developer says that DNSCrypt was never considered an IETF standard because it was created by volunteers without a corporate “roof”. Presenting it as a standard “would require time as well as protection at IETF meetings,” he said. “I can’t afford it, like other developers who work on it in their free time. Almost all ratified DNS-related specifications are actually written by people from the same several companies from year to year. If your business is not connected with DNS, then it is really hard to get a vote. ”
Although several DNS services use DNSCrypt(for example, CleanBrowsing to block “adult” content and Cisco OpenDNS to block malicious domains), the new privacy-oriented DNS providers (including Google, Cloudflare and Quad9) abandoned DNSCrypt and chose one of the other technologies approved by the IETF group: DNS over TLS and DNS over HTTPS. Now DNSCrypt Proxy supports DNS over HTTPS and indicates Cloudflare, Google and Quad9 in the default settings.
TLS became a priority for CloudFlare when it was necessary to strengthen the encryption of web traffic to protect against snooping
Crossbreeding with TLS
DNS over TLS (Transport Layer Security) has several advantages over DNSCrypt. The first is the proposed IETF standard . It also works quite simply by its very nature - it accepts queries in the standard DNS format and encapsulates them in encrypted TCP traffic. Apart from TLS-based encryption, this is essentially the same as sending DNS over TCP / IP instead of UDP.
There are several working clients for DNS over TLS. The best option I found is called Stubby, and it was developed as part of the DNS Privacy Project . Stubby is distributed as part of the Linux package, but there is also a version for MacOS (installed using Homebrew) and a version for Windows, although work on the latter has not yet been completed.
Although I was able to stably run Stubby on Debian after battling some dependencies, this client crashed regularly on Windows 10 and tends to crash on MacOS. If you are looking for a good guide on installing Stubby on Linux, then the best documentation I found is Frank Santoso's post on Reddit . He also wrote a shell script to install on the Raspberry Pi.
The good news is that Stubby allows configurations using multiple DNS-based services over TLS. The configuration file on YAML allows you to configure several IPv4 and IPv6 services and includes settings for SURFNet, Quad9, and other services. However, the YAML implementation used by Stubby is space-sensitive, so be careful when adding a new service (like Cloudflare). At first I used tabs and broke everything.
When connecting to a DNS server, DNS clients over TLS authenticate using a Simple Public Key Infrastructure (SPKI). SPKI uses a local cryptographic hash of the certificate of the provider, usually on the SHA256 algorithm. In Stubby, this hash is stored as part of the server description in the YAML configuration file, as shown below:
upstream_recursive_servers: #IPv4 #Cloudflare DNS over TLS server - address_data: 18.104.22.168 tls_auth_name: "cloudflare-dns.com" tls_pubkey_pinset: - digest: "sha256" value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc= - address_data: 22.214.171.124 tls_auth_name: "cloudflare-dns.com" tls_pubkey_pinset: - digest: "sha256" value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
After establishing a TCP connection between the client and the server through port 853, the server presents its certificate, and the client checks it against the hash. If everything is in order, then the client and server handshake TLS, exchange keys and start an encrypted communication session. From this moment, the data in the encrypted session follows the same rules as in DNS over TCP.
After successfully launching Stubby, I changed my DNS network settings to forward requests to 127.0.0.1 (localhost). The Wireshark sniffer shows this switch point well when the DNS traffic becomes invisible. Switching from normal DNS traffic to TLS encryption
Although DNS over TLS can work like DNS over TCP, but TLS encryption has a slight effect on performance. Dig queries to Cloudflare via Stubby took about 50 milliseconds on average (your results may vary), while simple DNS queries to Cloudflare can be answered in less than 20 ms.
Partial slowdowns occur on the server side due to excessive use of TCP. Usually, DNS works using the fast UDP protocol: sent and forgot, while a TCP message requires a negotiation of the connection and verification of the receipt of the packet. A UDP-based version of TLS DNS called DNS over Datagram Transport Layer Security (DTLS) is currently under experimental development — it can increase protocol performance.
There is also a problem with certificate management here. If the provider deletes the certificate and starts using the new one, then there is currently no clean way to update the SPKI data on clients, except to cut the old one and insert the new certificate into the configuration file. Before you figure it out, it would be useful to use some kind of key management scheme. And since the service runs on a rare port 853, it is highly likely that DNS over TLS can be blocked on the firewall.
But this is not a problem for the leader of our charts - DNS over HTTPS. It passes through most firewalls, as if they did not exist.
Google and Cloudflare seem to see the future of encrypted DNS equally
HTTPS DNS: DoH!
Both Google and Cloudflare seem to see the DNS protocol over HTTPS, also known as DoH, as the most promising option for DNS encryption. Published as a draft of the IETF standard , the DoH protocol encapsulates DNS queries into HTTPS packets, turning them into regular encrypted web traffic.
Requests are sent as HTTP POST or GET with the body in the format of a DNS message (datagrams from ordinary DNS queries) or as an HTTP GET request in JSON format (if you do not mind a small overhead). And there are no problems with certificate management. As with normal HTTPS web traffic, authentication is not required to connect via DoH, and the certificate is verified by a certification authority.
Fixing a DNS transaction through DoH. Only HTTPS, TLS and nothing else
is visible. HTTPS is a rather cumbersome protocol for DNS queries, especially in JSON format, so you have to put up with some performance degradation. The necessary resources on the server side will almost certainly make the administrator of a regular DNS server cry. But the simplicity of working with well-understood web protocols makes the development of both client and server code for DoH much more accessible for developers who eat a dog on web applications (just a few weeks ago, Facebook engineers released the DoH server and client concept in Python ).
As a result, although ink has not dried out on the RFC specifications for DoH, a number of DNS clients over HTTPS are ready to go. True, some of them are tailored for specific DNS providers. Loss of performance depends largely on the server and on the quality of a particular client.
For example, take the Argo tunneling client from Cloudflare (aka cloudflared ). This is a multifunctional tunneling tool designed primarily to establish a secure channel for connecting web servers to the Cloudflare CDN network. HTTPS DNS is just another service that CDN now supports.
By default, if you run Argo from the command line (on Linux and MacOS, you need superuser privileges for this, and on Windows you need to run the client from PowerShell as an administrator), then it sends DNS queries to
https://cloudflare-dns.com/dns-query. If normal DNS is not configured, then a small problem is possible, because this address must resolve in 126.96.36.199, otherwise Argo will not start.
This can be fixed in one of three ways. The first option: install the device with the local host (
127.0.0.1for IPv4 and
::1IPv6) as the main DNS server in the network configuration, and then add 188.8.131.52 as an additional resolver. This is a working option, but it is not ideal in terms of privacy and performance. It is better to add the server URL from the command line at boot:
$ sudo cloudflared proxy-dns --upstream https://184.108.40.206/dns-query
If you are sure that you want to switch to Cloudflare’s DNS server, which offers the advantage of automatic updating, you can configure it as a service on Linux using the YAML configuration file containing Cloudflare’s IPv4 and IPv6 DNS addresses:
proxy-dns: true proxy-dns-upstream: - https://220.127.116.11/dns-query - https://18.104.22.168/dns-query
When configured with the correct upstream addressing, the performance of dig-requests through Argo varies widely: from 12 ms for popular domains right up to 131 ms. Pages with lots of cross-site content loading ... a little longer than usual. Again, your result may be different - it probably depends on your location and connectedness. But that's about what I expected from the grim DoH protocol.
Like Cloudflare , we believe that the tunnels illustrate the Argo operation better than Ben Affleck.
In order to make sure that the problem is in the DoH protocol, and not in Cloudflare programmers, I tried two other tools. Firstly, a proxy from Google called Dingo. It was written by Pavel Foreszki, an Internet researcher at the Institute of Theoretical and Applied Informatics of the Polish Academy of Sciences. Dingo only works with the DoH implementation from Google, but it can be configured to the nearest Google DNS service. This is good because without this optimization, Dingo gobbled up all the DNS performance. Dig queries averaged over 100 milliseconds.
While checking the processing of standard requests by the service,
dns.google.comI came across an alternative to the default address 22.214.171.124 from Google (126.96.36.199, if you know). I added it to Dingo from the command line:
$ sudo ./dingo-linux-amd64 -port=53 -gdns:server=188.8.131.52
This reduced the response time by about 20%, that is, to about the same indicator as Argo.
And DNSCrypt Proxy 2 unexpectedly showed optimal DoH performance. After recently adding DoH Cloudflare to the curated list of public DNS services, DNSCrypt Proxy almost always connects to Cloudflare by default due to the low latency of this server. To make sure, I even manually configured it for the Cloudflare resolver for DoH before starting the battery of dig-requests.
All requests were processed in less than 45 milliseconds - this is faster than Cloudflare's own client, and by a wide margin. With Google’s DoH service, performance was worse: requests were processed on average about 80 milliseconds. This is an indicator without optimization for the nearest DNS server from Google.
In general, the performance of DNSCrypt Proxy for DoH is almost indistinguishable from the DNS resolver for TLS, which I checked earlier. In fact, it is even faster . I'm not sure if this is due to some special DoH implementation - maybe due to the use of the standard DNS message format encapsulated in HTTPS instead of the JSON format - or whether it is related to how Cloudflare handles two different protocols.
I'm not Batman, but my threat model is still a bit more complicated than most people
Why be so tormented?
I am a professional paranoid. My threat model is different from yours, and I would rather keep as much of my online activities safe as possible. But given the number of current threats to privacy and security due to manipulation of DNS traffic, many people have good reason to use some form of DNS encryption. I was pleased to find that some implementations of all three protocols do not have a very negative effect on the transmission speed of traffic.
However, it is important to note that DNS encryption alone will not hide your online activities. If several sites are hosted on the server, then the TLS extension called Server Name Indicator (SNI) used in HTTPS connections can still show in plain text the name of the site you visited. For complete confidentiality, you still need to use a VPN (or Tor) to encapsulate traffic so that the provider or some other snooping party cannot pull the metadata from the packets. But none of these services work with Tor. And if a government agency works against you, then you can’t be sure of anything.
Another problem is that although the great guys from the DNSCrypt community have done a great job, such privacy is still too complicated for ordinary people. Although some of these DNS clients for encryption turned out to be relatively easy to configure, none of them can be called guaranteed simple for normal users. To make these services really useful, they should be more tightly integrated into the hardware and software that people buy - home routers, operating systems for personal computers and mobile devices.
Internet providers will probably try to more actively monetize normal DNS traffic, and government agencies and criminals who seek to use it to the detriment of the user will not disappear. But it is unlikely that major OS developers seek to reliably protect DNS in a way that is accessible to most people, because they are often interested in monetization, as are Internet service providers. In addition, these developers may face resistance to changes from some governments that want to maintain DNS monitoring capabilities.
So in the near future, these protocols will remain a tool for those few people who really care about the confidentiality of their data and are ready to work a little for this. I hope the community around DNSCrypt will continue its activity and move the situation forward.