We meet the service from Cloudflare at addresses 1.1.1.1 and 1.0.0.1, or “the public DNS regiment has arrived!”

Cloudflare company presented public DNS to the following addresses:

• 1.1.1.1
• 1.0.0.1
• 2606: 4700: 4700 :: 1111
• 2606: 4700: 4700 :: 1001

It is alleged that the privacy first policy is being used, so that users can rest assured about the content of their requests.

The service is interesting because besides the usual DNS it provides the ability to use the DNS-over-TLS and DNS-over-HTTPS technologies, which will greatly prevent the providers from listening in on the request paths of your requests - and collecting statistics, monitoring, managing the advertisement. Cloudflare claims that the date of the announcement (April 1, 2018, or 04/01 in American notation) was not chosen by chance: on what day of the year should we present the “four units”?

As the audience of Habr is technically savvy, the traditional section "why do we need DNS?" I will put it at the end of the post, and here I will explain more practical things:

How to use the new service?

The simplest thing is to specify the addresses of the DNS servers listed above in your DNS client (or as upstream in the settings of your local DNS server). Does it make sense to replace the usual values ​​of Google DNS (8.8.8.8, etc.), or slightly less common Yandex public DNS servers (77.88.8.8 and others like them) with Cloudflare servers - they will decide for you, but the speed chart says for a beginner answers, according to which Cloudflare is running faster than all competitors (to clarify: the measurements were made by the external service, and the speed to a specific client, of course, may differ).

It is much more interesting to work with new modes in which the request flies to the server via an encrypted connection (in fact, the answer is returned via it), mentioned DNS-over-TLS and DNS-over-HTTPS. Unfortunately, they are not supported out of the box (the authors believe that this is for now), but it’s easy to organize in their software (or even on their hardware):

DNS over HTTPs (DoH)

As the name implies, the conversation goes over the HTTPS channel, which implies

1. the presence of a touchdown point (endpoint) - it is located at https://cloudflare-dns.com/dns-query , and
2. a client who can send requests and receive responses.

Requests can be either in the Wireformat DNS format defined in RFC1035 (sent using the HTTP POST and GET methods), or in JSON format (using the HTTP GET method). For me personally, the idea of ​​making DNS requests through HTTP requests seemed unexpected, but there is a rational grain: this request will pass many traffic filtering systems, parsing answers is quite simple, and making requests is even easier. The customary libraries and protocols are responsible for security.

Examples of requests, directly from the documentation:

GET request in the format of DNS Wireformat

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x7f968700a400) GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2 Host: cloudflare-dns.com User-Agent: curl/7.54.0 Accept: */* * Connection state changed (MAX_CONCURRENT_STREAMS updated)! HTTP/2 200 date: Fri, 23 Mar 2018 05:14:02 GMT content-type: application/dns-udpwireformat content-length: 49 cache-control: max-age=0 set-cookie: \__cfduid=dd1fb65f0185fadf50bbb6cd14ecbc5b01521782042; expires=Sat, 23-Mar-19 05:14:02 GMT; path=/; domain=.cloudflare.com; HttpOnly server: cloudflare-nginx cf-ray: 3ffe69838a418c4c-SFO-DOG { [49 bytes data] 100 49 100 49 0 0 493 0 --:--:-- --:--:-- --:--:-- 494 * Connection #0 to host cloudflare-dns.com left intact 0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77 0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8 0000030 22 0000031 

POST request in Wireformat DNS format

 $ echo -n 'q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | base64 -D | curl -H 'Content-Type: application/dns-udpwireformat' --data-binary @- https://cloudflare-dns.com/dns-query -o - | hexdump { [49 bytes data] 100 49 100 49 0 0 493 0 --:--:-- --:--:-- --:--:-- 494 * Connection #0 to host cloudflare-dns.com left intact 0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77 0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8 0000030 22 0000031 

The same, but using JSON

 $ curl 'https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=example.com&type=AAAA' { "Status": 0, "TC": false, "RD": true, "RA": true, "AD": true, "CD": false, "Question": [ { "name": "example.com.", "type": 1 } ], "Answer": [ { "name": "example.com.", "type": 1, "TTL": 1069, "data": "93.184.216.34" } ] } 

Obviously, a rare (if any) home router can work with DNS this way, but this does not mean that support will not appear tomorrow - and, interestingly, here we can fully implement the work with DNS in our application (as it is about to do Mozilla , just on Cloudflare servers).

DNS over TLS

By default, DNS queries are transmitted without encryption. DNS over TLS is a way to send them over a secure connection. Cloudflare supports DNS over TLS on the standard port 853, as prescribed by RFC7858 . It uses a certificate issued for the host cloudflare-dns.com, TLS 1.2 and TLS 1.3 are supported.

The establishment of communication and work on the protocol goes something like this:

• Until a DNS connection is established, the client saves the base64 SHA256-encoded hash of the TLS certificate cloudflare-dns.com's (called SPKI)
• DNS client establishes a TCP connection with cloudflare-dns.com:853
• DNS client initiates TLS handshake procedure
• During the TLS handshake process, the host cloudflare-dns.com presents its TLS certificate.
• Once the TLS connection is established, the DNS client can send DNS requests on top of the secure channel, which prevents eavesdropping and forging requests and responses.
• All DNS queries sent via a TLS connection must comply with the specification for sending DNS over TCP .

Sample request via DNS over TLS:

 $ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com ;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP) ;; DEBUG: TLS, imported 170 system certificates ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, C=US,ST=CA,L=San Francisco,O=Cloudflare\, Inc.,CN=\*.cloudflare-dns.com ;; DEBUG: SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc= ;; DEBUG: #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA ;; DEBUG: SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR ;; PADDING: 408 B ;; QUESTION SECTION: ;; example.com. IN A ;; ANSWER SECTION: example.com. 2347 IN A 93.184.216.34 ;; Received 468 B ;; Time 2018-03-31 15:20:57 PDT ;; From 1.1.1.1@853(TCP) in 12.6 ms 

This option seems to be better suited for local DNS servers serving the needs of the local network or a single user. True, with the support of the standard is not very good, but - let's hope!

Two words of explanation, what is the conversation

The DNS abbreviation stands for Domain Name Service (so saying "DNS service" is somewhat redundant, the abbreviation already has the word "service"), and is used to solve a simple task - to understand what IP address a particular host name is. Every time a person clicks a link, or enters an address in the address bar of the browser (say, something like " https://habrahabr.ru/post/346430/ "), the person’s computer tries to figure out which server to send a request to. to get the page content. In the case of habrahabr.ru, the response from the DNS will indicate the IP address of the web server: 178.248.237.68, and then the browser will already try to contact the server with the specified IP address.

In turn, the DNS server, after receiving the request “what is the IP address of the host named habrahabr.ru?”, Determines whether it knows something about the specified host. If not, he makes a request to other DNS servers in the world, and, step by step, tries to figure out the answer to the question asked. As a result, after finding the final answer, the found data is sent to the still waiting client, plus stored in the cache of the DNS server itself, which will allow to answer such a question much faster next time.

The usual problem is that, firstly, the data of DNS queries are transmitted in open form (which gives everyone who has access to the traffic flow, isolate DNS queries and the received responses, and then analyze them for their own purposes; this gives The ability to target advertising with accuracy for the DNS client, which is quite a lot!). Secondly, some Internet providers (we will not point with a finger, but not the smallest) tend to display ads instead of one or another of the requested pages (which is implemented very simply: instead of the specified IP address for a request by the host name habranabr.ru, to a person the address of the web server of the provider, where the page containing the advertisement is given, is returned. Third, there are Internet access providers that implement the mechanism for fulfilling the requirements for blocking individual sites by substituting the correct DNS responses for the IP addresses of blocked web resources to the IP address of their server containing stub pages (as a result, access to such sites becomes much more complicated), or to the address of your proxy server that performs filtering.

Here, you probably need to put a picture from the site http://1.1.1.1/ , which is used to describe the connection to the service. The authors, as you can see, are quite confident in the quality of the work of their DNS (however, it is difficult to expect another from Cloudflare)

One can fully understand Cloudflare, the creator of the service: they earn their bread by supporting and developing one of the most popular CDN networks in the world (whose functions include not only content distribution, but also hosting DNS zones), and, by virtue of the desire of those who do not really understand , to teach those whom they do not know , where to go in the global network, quite often suffers from address blocking of their servers from the outside, we will not tell anyone - so the presence of the DNS, which is not influenced by "shouts, whistles and pisulek ", for the company means less harm to their bi znesu. And the technical advantages (a trifle, but nice: in particular, for the clients of the free DNS Cloudflare, the update of the DNS records of resourses hosted on the company's DNS servers will be instant) make using the service described in the post even more interesting.