
Cloudflare introduced public DNS at the addresses:
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
It is claimed that a 'Privacy first' policy is used, so users can rest assured about the content of their queries.
The service is interesting in that, in addition to standard DNS, it offers the ability to use technologies like DNS-over-TLS and DNS-over-HTTPS, which greatly hinders providers from eavesdropping on your requests and gathering statistics, monitoring, and managing advertising. Cloudflare claims that the announcement date (April 1, 2018, or 04/01 in American notation) was chosen purposefully: on what other day of the year could they present 'four ones'?
Since the audience of Habr is technically savvy, I will place the traditional section 'why do we need DNS?' at the end of the post, and here I'll outline more practically useful things:
How to use the new service?
The simplest way is to specify the DNS server addresses provided above in your DNS client (or as upstream in the settings of your local DNS server).servers. Is it worthwhile to replace the familiar values of Google's DNS (8.8.8.8, etc.), or the slightly less common Yandex's public DNS servers (77.88.8.8 and similar) with servers from Cloudflare — you will decide, but for newcomers it speaks to chart response speeds, according to which Cloudflare works faster than all competitors (I will clarify: measurements were made by a third-party service, and the speed to a specific client may of course differ).

Much more interesting is the work with the new modes, in which the request goes through an server encrypted connection (the response is returned over the same), mentioned as DNS-over-TLS and DNS-over-HTTPS. Unfortunately, 'out of the box' they are not supported (the authors believe that this is 'for now'), but organizing their work in your software (or even on your hardware) is not difficult:
DNS over HTTPS (DoH)
As the name suggests, communication occurs over the HTTPS channel, which implies
- the presence of an endpoint — it is located at https://cloudflare-dns.com/dns-query, and
- a client that knows how to send requests and receive responses.
Requests may be in either the DNS Wireformat defined in RFC1035 (using HTTP methods POST and GET), or in JSON format (using the HTTP GET method). Personally, I found the idea of making DNS requests through HTTP requests surprising, but there is a rational kernel to it: such a request will pass through many traffic filtering systems, parsing the responses is quite straightforward, and forming requests is even simpler. Security is handled by familiar libraries and protocols.
Examples of requests directly from the documentation:
GET request in 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 DNS Wireformat
$ 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"
}
]
}
Clearly, it is rare (if not nonexistent) for a home router to work that way with DNS, but that does not mean support won't appear tomorrow — interestingly, we can implement DNS functionality in our application here (as Mozilla is planning to do on the Cloudflare servers)., just like Mozilla is planning to do.
DNS over TLS
By default, DNS queries are sent unencrypted. DNS over TLS is a method of sending them over a secure connection. Cloudflare supports DNS over TLS on the standard port 853, as mandated. RFC7858. A certificate issued for the host cloudflare-dns.com is used, supporting TLS 1.2 and TLS 1.3.
The connection establishment and operation via the protocol occur approximately as follows:
- Before establishing a connection with the DNS server, the client retains the base64-encoded SHA256 hash of the TLS certificate for cloudflare-dns.com (known as SPKI).
- The DNS client establishes a TCP connection with cloudflare-dns.com:853.
- The DNS client initiates the TLS handshake procedure.
- During the TLS handshake, the host cloudflare-dns.com presents its TLS certificate.
- Once the TLS connection is established, the DNS client can send DNS queries over the secure channel, preventing eavesdropping and tampering with queries and responses.
- All DNS queries sent over the TLS connection must adhere to the specifications for sending DNS over TCP..
An example of a query using 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 more suited for local DNS servers serving the needs of a local network or a single user. However, the support for the standard is not very good, but — let’s hope!
A couple of words to clarify what this is about
The abbreviation DNS stands for Domain Domain Name Service (so saying 'DNS service' is somewhat redundant, as the word 'service' is already included in the abbreviation), and is used to solve a simple task — to find out what IP address corresponds to a specific hostname. Every time someone clicks on a link or enters an address in the browser's address bar (let's say something like 'https://habrahabr.ru/post/346430/When a person’s computer tries to determine which server should receive the request for fetching the page content. In the case of habrahabr.ru, the response from DNS will provide the IP address of the web server: 178.248.237.68, and then the browser will attempt to connect to the server at the specified IP address.
In turn, the DNS server, upon receiving the request "what is the IP address of the host named habrahabr.ru?", determines whether it knows anything about the specified host. If not, it queries other DNS servers around the world, step by step trying to find the answer to the question. Ultimately, once the final answer is found, the retrieved data is sent back to the waiting client, and it is also cached in the DNS server itself, which will allow for much faster responses to similar questions in the future.
A common problem is that, firstly, DNS query data is transmitted in plain text (which allows anyone with access to the traffic stream to extract the DNS queries and the responses received, then analyze them for their purposes; this enables targeted advertising with precision to the DNS client, which is quite significant!). Secondly, some internet service providers (we won't point fingers, but they are not the smallest) tend to show ads instead of the requested page (this is implemented quite simply: instead of the specified IP address for the query to the host name habranabr.ru, a random address of the provider's web server is returned, where a page containing advertisements is served). Thirdly, there are internet access providers that implement a mechanism for blocking specific sites by substituting correct DNS responses for the IP addresses of blocked web resources with the IP address of their server containing landing pages (as a result, access to such sites becomes significantly more difficult), or to the address of their proxy server that performs filtering.
Here, a relevant image from the website should probably be placed http://1.1.1.1/, which serves to illustrate the connection to the service. The authors clearly have complete confidence in the quality of their DNS (well, you wouldn't expect anything less from Cloudflare):

It's quite understandable why Cloudflare, the creator of the service, makes their living by supporting and developing one of the most popular CDN networks in the world (which not only provides content delivery but also hosts DNS zones). Given their desire to teach those who aren't very knowledgeable, they aim to instruct those whom they do not know, about where to go in the global network, they often face server address blocks from let's not say who . Therefore, having a DNS that is not influenced by 'shouting, whistling, and scribbles' means less harm to their business. The technical advantages (a small but pleasant detail: for clients using Cloudflare's free DNS, updating DNS records for resources hosted on the company's DNS servers will be instant) make using the service described in the post even more appealing.
Only registered users can participate in the survey. Please log in, please.
Will you use the new service?
- Yes, just by setting it in the OS and/or on the router
- Yes, and I will use the new protocols (DNS over HTTPS and DNS over TLS)
- No, the current servers are sufficient for me (this is a public provider: Google, Yandex, etc.)
- No, I don't even know what I'm using now
- I use my recursive DNS with an SSL tunnel to them
693 users voted. 191 users abstained.
Source: habr.com
