Configuring 1.1.1.1 from Cloudflare and other DNS services still requires command line skills

Encrypting the 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 service providers to handle network traffic have caused many concerns about confidentiality. Providers (and other unauthorized persons who monitor passing traffic) have long had a tool to easily monitor the behavior of people on the Internet: these are their domain name servers (DNS). Even if they have not yet monetized this data (or did not replace traffic), they probably will soon begin.

DNS is a telephone directory of the Network that issues the actual network IP address associated with the hosting and domain names of sites and other Internet services. For example, it turns arstechnica.com into 50.31.169.131. Your Internet provider offers DNS in a package of services, 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 privacy and security, and in some countries - to avoid content filtering, surveillance and censorship. April 1 (not a joke), the company Cloudflare launched its new, free and high-performance DNS-service designed to improve the privacy of users on the Internet. It also promises to completely hide DNS traffic from prying eyes using encryption.

Named for its IP address, service 1.1.1.1 is the result of a partnership with the APNIC research team, the Asia-Pacific Network Information Center, one of the five regional Internet registrars. Although it is also available as an “open” normal DNS resolver (and very fast), Cloudflare still supports two DNS encryption protocols.

Although it was developed with some unique “buns” from Cloudflare, but 1.1.1.1 is not the first encrypted DNS service. Quad9 , OpenDNS from Cisco, service 8.8.8.8 from Google, and many smaller services that support various full DNS encryption schemes work successfully. But encryption does not necessarily mean that your traffic is invisible: some DNS services with encryption still write your requests to the log for various purposes.

Cloudflare promised not to log DNS traffic and hired a third-party firm to audit it. Jeff Huston from APNIC reported that APNIC is going to use data for research purposes : the 1.0.0.0/24 and 1.1.1.0/24 ranges were initially configured as addresses for “black” traffic. But APNIC will not get access to encrypted DNS traffic.

It is not as easy for users to connect DNS encryption 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 - lately in all the news they are talking about turning user data into a product - I decided to see how DNS-based encryption works for Cloudflare. As a result, my internal laboratory rat won - and I found that I was testing and sorting clients for several DNS providers through three DNS encryption protocols: DNSCrypt, DNS over TLS and DNS over HTTPS. They all work, but I warn you: although the procedure becomes simpler, you can hardly explain the DNS encryption to your parents by phone (unless they are experienced Linux command line users).


How DNS works

Why do we do 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 visited sites even when working through a third-party DNS — and use this data to their advantage, including filtering content and collecting data for advertising purposes.


What is the typical data exchange between a device and a DNS resolver?

“We have a last-mile problem in the DNS,” said Cricket Liu, the chief DNS architect at Infoblox, which deals with information security. “Most of our security mechanisms address communications between servers.” But there is a problem with surrogates of resolvers on various operating systems. In reality, we cannot protect them. ” The problem is especially noticeable in countries where the authorities are more hostile to the Internet.

To some extent, using a DNS that does not keep logs helps. But it still does not prevent an attacker from filtering requests for content or intercepting addresses using packet capture or deep packet inspection. In addition to passive wiretapping, there is a threat of more active attacks on your DNS traffic - DNS server spoofing by the provider or special services with redirection to your own server to track or block traffic. Something similar (although, apparently, not maliciously) seems to be happening with random traffic redirection to the address 1.1.1.1 from the AT & T network , judging by the messages on the DSLReports forums.

The most obvious way to evade surveillance is to use a VPN. But while VPNs hide the contents of your traffic, a DNS query may be required to connect to a VPN. And during a VPN session, DNS queries can also sometimes be sent by web browsers or other software outside the VPN tunnel, creating “DNS leaks” that reveal the sites visited.

This is where DNS encryption protocols come into play: these are DNSCrypt (among others, it is supported by OpenDNS from Cisco), DNS by TLS (supported by Cloudflare, Google, Quad9, OpenDNS) and DNS by HTTPS (supported by Cloudflare, Google and the adult lock service) CleanBrowsing content). Encryption ensures that traffic does not scan and does not change, and that requests will not receive and will not process a fake DNS server. It protects against MiTM attacks and espionage. A DNS proxy with one of these services (directly on the device or on a “server” on the local network) will help prevent DNS leaks through VPNs, since a proxy server will always be the fastest DNS server available.

However, this protection option is not available to the mass user. None of these protocols is natively supported by any DNS resolver that comes with the OS. All require installation (and probably compiling) of a client application that acts as a local DNS “server”, relaying requests made by browsers and other applications upstream to a secure DNS provider of your choice. And although two of these three technologies are offered for the role of standards, none of the options we have tested has yet been presented in its final form.

Therefore, if you want to plunge into DNS encryption, then it is better to take for a DNS server in the home network Raspberry Pi or another separate device. Because you will surely find that setting up one of the listed clients is already enough hacking to not want to repeat the process again. It's 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 fallout of Windows clients one by one and the hibernation of clients under MacOS.


The DNSCrypt community tried to make an accessible tool for those who do not have command-line skills by launching DNSCloak (left) for iOS and Simple DNSCrypt (for right) under Windows

Encrypted

For the sake of completeness in the historical perspective, we will begin the review with the very first DNS encryption technology - DNSCrypt. First introduced in BSD Unix in 2008, the DNSCrypt tool was originally intended to protect not from eavesdropping, but from DNS spoofing. However, it can be used as part of a privacy management system — especially in combination with a DNS server without logs. As noted by DNSCrypt developer Frank Denis, 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 at the weekend.” The DNSCrypt community has created easy-to-use clients, such as Simple 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 set up an independent network of private DNS servers based on a protocol that helps users evade the use of corporate DNS systems.

“DNSCrypt is not connecting to the servers of a particular company,” said Denis. - We urge everyone to raise their own servers. Make it very cheap and easy. Now that we have secure resolvers, I'm trying to solve the problem of content filtering with respect to confidentiality. ”

For those who want to run a DNS server with DNSCrypt support for their entire network, the best client will be DNSCrypt Proxy 2 . 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's binary directly from the official repository on GitHub. There are versions for Windows, MacOS, BSD and Android.

DNSCrypt's privacy protection experience is embodied in the DNSCrypt Proxy. The program is easily configured, supports access time restrictions, domain templates and blacklists of IP addresses, query logs and other functions of a fairly powerful local DNS server. But to get started, the most basic configuration is enough. There is an example of a TOML configuration file ( Tom's Obvious Minimal Language , created by GitHub co-founder Tom Preston-Werner). You can simply rename it before running the DNSCrypt Proxy - and it will become the working configuration file.

By default, the proxy server uses Quad9 open DNS resolver to search and retrieve from GitHub a curated list of open DNS services. Then connects to the server with the fastest response. If necessary, you can change the configuration and select a specific service. Information about servers in the list is encoded as a “server stamp” . It contains the IP address of the provider, the public key, the information whether the server supports DNSSEC, whether the provider stores logs and blocks any domains. (If you do not want to depend on a remote file during installation, you can run the “stamp calculator” in JavaScript - and generate your own local static list of servers in this format ).

For my DNSCrypt testing, I used Cisco's OpenDNS as a remote DNS service. At the first requests, the DNSCrypt performance turned out to be slightly worse than the regular DNS, but then the DNSCrypt Proxy caches the results. The slowest requests were processed in the region of 200 ms, while the average ones were processed in 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 the slowdown in speed when browsing the web.

The main advantage of DNSCrypt is that it looks like a “regular” DNS. Good or bad, it transmits UDP traffic on port 443 - the same port is used for secure web connections. This gives relatively fast rezolving addresses and reduces the likelihood of blocking on the provider's firewall. To further reduce the likelihood of blocking, you can change the configuration of the client and send requests over TCP / IP (as shown by testing, this minimally affects the response time). So the encrypted DNS traffic for most network filters is similar to HTTPS traffic - at least in appearance.


Showing DNSCrypt traffic and local DNSCrypt Proxy traffic. Wireshark Sniffer says this is HTTPS traffic, because I forced the use of TCP. If you send it via UDP, then Wireshark will see Chrome QUIC traffic.

DNSCrypt, on the other hand, does not rely on trusted certificate authorities for encryption — the client must trust the signature public key issued by the provider. This signature key is used to verify certificates that are retrieved using simple (unencrypted) DNS queries and are used for key exchange 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 link it to your account. This scheme is not used in DNSCrypt 2.

From a developer’s point of view, it’s a bit difficult to work with DNSCrypt “DNSCrypt is not particularly well documented, and not so many of its implementations,” says Liu Cricket from Infoblox. In fact, we were able to find only a single client in active development - this 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 libraries is marked as “cryptographically dangerous” because it is very easy to make mistakes with it. But the main cryptographic algorithm used is Curve25519, “is one of the simplest elliptic curves for safe use,” said Denis.

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 take time as well as protection at the IETF meetings,” he said. “I can't afford it, like the other developers who work on it in their spare time. Almost all the ratified DNS-related specifications are actually written by people from the same several companies from year to year. If your business is not related to DNS, then it’s 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) refused DNSCrypt and chose one of the Other IETF-approved technologies: DNS over TLS and DNS over HTTPS. Now DNSCrypt Proxy supports DNS over HTTPS and specifies 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

Crossing with TLS

DNS has TLS (Transport Layer Security) several advantages over DNSCrypt. First is the proposed IETF standard . It also works quite simply in its essence - it accepts requests from the standard DNS format and encapsulates them into encrypted TCP traffic. Aside 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, 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 the work on the latter has not yet been completed.

Although I managed to consistently run Stubby on Debian after a battle with some dependencies, this client crashed regularly in Windows 10 and tends to hang on MacOS. If you're looking for a good guide to installing Stubby on Linux, the best documentation I've found is Frank Santoso's post on Reddit . He also wrote a shell script for installation on the Raspberry Pi.

On the plus side, Stubby allows configurations using multiple DNS-based services over TLS. The YAML configuration file 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 (for example, Cloudflare). At first I used tabs - and everything broke.

DNS clients using TLS, when connected to a DNS server, authenticate using simple public key infrastructure (SPKI). SPKI uses the provider’s local cryptographic hash of the certificate, 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: 1.1.1.1 tls_auth_name: "cloudflare-dns.com" tls_pubkey_pinset: - digest: "sha256" value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc= - address_data: 1.0.0.1 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 via port 853, the server presents its certificate, and the client verifies it with the hash. If everything is in order, then the client and server produce a handshake TLS, exchange keys and start an encrypted communication session. From this point on, data in an encrypted session follows the same rules as in DNS over TCP.

After the successful launch of Stubby, I changed the network settings of the DNS network to send requests to 127.0.0.1 (localhost). Wireshark sniffer shows this switching point well when 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. Digub requests to Cloudflare via Stubby ran for me on average about 50 milliseconds (your results may vary), while simple DNS queries to Cloudflare receive an answer in less than 20 ms.

Part of the slowdown occurs on the server side due to unnecessary use of TCP. Normally, DNS is running on the fast UDP protocol: sent and forgotten, while the TCP message requires a connection negotiation and a packet receipt check. A UDP-based version of DNS over TLS called DNS over Datagram Transport Layer Security (DTLS) is currently in experimental development — it can increase protocol performance.

There is also a problem with certificate management. If the provider deletes the certificate and starts using the new one, there is currently no clean way to update the SPKI data on clients, except for cutting out the old one and inserting the new certificate into the configuration file. Before you figure this out, it would be helpful to use some kind of key management scheme. And since the service runs on the rare port 853, then with a high probability DNS over TLS can be blocked on the firewall.

But this is not a problem for the leader of our hit parade - DNS over HTTPS. It passes through most firewalls, as if those do not exist.


Google and Cloudflare seem to see the future of an encrypted DNS in the same way.

DNS over https: 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 an IETF draft draft , the DoH protocol encapsulates DNS requests into HTTPS packets, turning them into plain, encrypted web traffic.

Requests are sent as HTTP POST or GET with the body in the format of a DNS message (datagram from ordinary DNS requests) or as an HTTP GET request in JSON format (if you are not against a small overhead). And there are no problems with certificate management. As with normal HTTPS web traffic, no authentication is required to connect via DoH, and the certificate is verified by a certification authority.


Fix DNS-transactions through DoH. Only HTTPS, TLS and nothing else are visible

HTTPS is a rather cumbersome protocol for DNS queries, especially in JSON format, so you have to put up with some performance degradation. Required server-side resources will almost certainly make the usual DNS server administrator shed a tear. 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 have eaten a dog on web applications (just a few weeks ago, Facebook engineers released the DoH server concept and client in Python ).

As a result, although ink has not yet dried out on the RFC specifications for DoH, a number of DNS clients using HTTPS are ready for use. True, some of them are sharpened for specific DNS providers. Loss of performance depends on the server and on the quality of a particular client.

For example, take the Cloudflare Argo tunneling client (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 is now supported by CDN.

By default, if you run Argo from the command line (on Linux and MacOS, you need superuser privileges, and on Windows you need to start the client from PowerShell as administrator), then it sends DNS requests to https://cloudflare-dns.com/dns-query . If a normal DNS is not configured, then a small problem is possible, because this address must be resolved to 1.1.1.1, otherwise Argo will not start.

This can be corrected in one of three ways. The first option is to install the device with a local host ( 127.0.0.1 for IPv4 and ::1 for IPv6) as the primary DNS server in the network configuration, and then add 1.1.1.1 as an additional resolver. This is a working version, but it is not perfect in terms of privacy and performance. It is better to add the server URL from the command line when loading:

 $ sudo cloudflared proxy-dns --upstream https://1.0.0.1/dns-query 

If you are sure that you want to switch to Cloudflare's DNS server, which gives the advantage of automatic updating, then you can configure it as a service in Linux using the YAML configuration file containing Cloudflare's IPv4 and IPv6 addresses:

 proxy-dns: true proxy-dns-upstream: - https://1.1.1.1/dns-query - https://1.0.0.1/dns-query 

When configured with the correct upstream addressing, the performance of dig queries through Argo varies widely: from 12 ms for popular domains to as much as 131 ms. Pages with more cross-site content load ... a little longer than usual. Again, your result may be different - it probably depends on your location and connectivity. But this is about what I expected from the gloomy DoH protocol.


Like Cloudflare , we believe that the tunnels illustrate Operation Argo better than Ben Affleck

In order to make sure that the problem is in the DoH protocol, and not in the Cloudflare programmers, I have experienced two other tools. First, a proxy from Google called Dingo . It was written by Pavel Foremsky, an Internet researcher from the Institute of Theoretical and Applied Computer Science of the Polish Academy of Sciences Dingo only works with the Google DoH implementation, but it can be configured to the nearest Google DNS service. This is good, because without this optimization, Dingo gobbled up all DNS performance. Dig queries on average were executed over 100 milliseconds.

While checking the processing of standard requests by the dns.google.com service dns.google.com I came across an alternative to the default address 8.8.8.8 from Google (172.217.8.14, if you know). I added it to Dingo from the command line:

 $ sudo ./dingo-linux-amd64 -port=53 -gdns:server=172.216.8.14 

This reduced the response time by about 20%, that is, up to about the rate of the Argo.

And DNKrypt Proxy 2 unexpectedly showed DoH's optimal performance. After the recent addition of DoH Cloudflare to the supervised 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 under the Cloudflare DoH revolver before running the battery of dig queries.

All requests were processed in less than 45 milliseconds - this is faster than Cloudflare's own client, and with a large margin. With the DoH service from Google, performance was worse: requests were processed on average about 80 milliseconds. This is an indicator without optimization on the nearest DNS server from Google.

In general, the DNSCrypt Proxy performance by 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 particular DoH implementation — maybe because of the use of the standard DNS message format encapsulated in HTTPS instead of the JSON format — either due to the way Cloudflare handles two different protocols.


I'm not Batman, but my threat model is still a bit more complicated than most people

Why so tormented?

I am a professional paranoid. My threat model is different from yours, and I would prefer to keep as much of my actions online as safe as possible. But given the number of current threats to privacy and security due to DNS traffic manipulation, 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 speed of transmission of traffic.

However, it is important to note that DNS encryption alone will not hide your actions on the Internet. 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 language the name of the site you visited. For complete confidentiality, you still need to use VPN (or Tor) to encapsulate traffic in such a way that a provider or any other spying party cannot pull out the metadata from the packets. But none of these services works 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 lot of work, this privacy is still too difficult 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 truly useful, they should be more closely integrated into hardware and software that people buy - home routers, operating systems for personal computers and mobile devices.

Internet providers will certainly 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 anywhere. But it is unlikely that major OS developers strive to reliably protect the DNS in an accessible way for most people, because they are often interested in monetization, as are Internet providers. In addition, these developers may face resistance to change 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 privacy of their data and are ready to work a little for this. I hope the community around DNSCrypt will continue to be active and move things forward.