ProHoster > Blog > Administration > We meet the service from Cloudflare at addresses 1.1.1.1 and 1.0.0.1, or “the public DNS shelf has arrived!”
We meet the service from Cloudflare at addresses 1.1.1.1 and 1.0.0.1, or “the public DNS shelf has arrived!”
Cloudflare Company presented public DNS at addresses:
1.1.1.1
1.0.0.1
2606: 4700: 4700 :: 1111
2606: 4700: 4700 :: 1001
The policy is said to be "Privacy first" so that users can have peace of mind about the content of their requests.
The service is interesting in that, in addition to the usual DNS, it provides the ability to use technologies DNS-over-TLS и DNS-over-HTTPS, which will greatly prevent providers from eavesdropping on your requests along the path of requests - and collect statistics, monitor, manage advertising. Cloudflare claims that the date of the announcement (April 1, 2018, or 04/01 in American notation) was not chosen by chance: what other day of the year will the “four units” be presented?
Since Habr's audience is technically savvy, the traditional section "why do you need DNS?" I will put it at the end of the post, but here I will state more practically useful things:
How to use the new service?
The simplest thing is to specify the above DNS server addresses in your DNS client (or as upstream in the settings of the local DNS server you use). Does it make sense to replace the usual values Google DNS (8.8.8.8, etc.), or slightly less common Yandex public DNS servers (77.88.8.8 and others like them) to the servers from Cloudflare - they will decide for you, but speaks for a beginner schedule response speed, according to which Cloudflare is faster than all competitors (I’ll clarify: the measurements were taken by a third-party 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 over an encrypted connection (in fact, the response is returned through it), the mentioned DNS-over-TLS and DNS-over-HTTPS. Unfortunately, they are not supported “out of the box” (the authors believe that this is “yet”), but it is not difficult to organize their work in your software (or even on your hardware):
DNS over HTTPs (DoH)
As the name suggests, communication takes place over an HTTPS channel, which means
the presence of a landing point (endpoint) - it is located at the address https://cloudflare-dns.com/dns-queryand
a client that can send requests and receive responses.
Requests can either be in the DNS Wireformat format defined in RFC1035 (sent using the POST and GET HTTP methods), or in JSON format (using the GET HTTP method). For me personally, the idea of making DNS requests via HTTP requests seemed unexpected, but there is a rational grain in it: such a request will pass many traffic filtering systems, parsing responses is quite simple, and generating requests is even easier. The usual libraries and protocols are responsible for security.
Request examples, straight from the documentation:
Obviously, a rare (if at least one) home router can work with DNS in this way, but this does not mean that support will not appear tomorrow - and, interestingly, here we can quite implement working with DNS in our application (as already going to make 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 standard port 853 as prescribed RFC7858. This uses a certificate issued for the cloudflare-dns.com host, TLS 1.2 and TLS 1.3 are supported.
Establishing a connection and working according to the protocol goes something like this:
Before establishing a DNS connection, the client stores a base64 encoded SHA256 hash of cloudflare-dns.com's TLS certificate (called SPKI)
DNS client establishes a TCP connection to cloudflare-dns.com:853
DNS client initiates TLS handshake
During the TLS handshake process, the cloudflare-dns.com host presents its TLS certificate.
Once a TLS connection is established, the DNS client can send DNS queries over a secure channel, which prevents requests and responses from being eavesdropped and spoofed.
All DNS queries sent over a TLS connection must comply with the sending DNS over TCP.
An example of a 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 work best for local DNS servers serving the needs of a 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 of what the conversation is about
The abbreviation DNS stands for Domain Name Service (so saying “DNS service” is somewhat redundant, the abbreviation already contains the word “service”), and is used to solve a simple task - to understand what IP address a particular host name has. Every time a person clicks on a link, or enters an address in the browser's address bar (say, something like "https://habrahabr.ru/post/346430/"), the human computer is trying to figure out which server to send a request to get the page's content. In the case of habrahabr.ru, the response from DNS will contain an indication of the web server IP address: 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, having received 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 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, upon finding the final answer, the found data is sent to the client still waiting for them, plus it is stored in the cache of the DNS server itself, which will allow you to answer a similar question much faster next time.
A common problem is that, first, the DNS query data is transmitted in the clear (which gives anyone with access to the traffic flow the ability to isolate the DNS queries and the responses they receive and then parse them for their own purposes; this gives the ability to target ads with accuracy for a DNS client, which is quite a lot!). Secondly, some ISPs (we won’t point fingers, but not the smallest ones) tend to show ads instead of one or another requested page (which is implemented quite simply: instead of the specified IP address for a query by the habranabr.ru host name, a random person Thus, the address of the provider's web server is returned, where the page containing the advertisement is served). Thirdly, there are Internet access providers that implement a mechanism for fulfilling the requirements for blocking individual sites by replacing the correct DNS responses about the IP addresses of blocked web resources with the IP address of their server containing stub pages (as a result, access to such sites noticeably more complicated), or to the address of your proxy server that performs filtering.
This should probably be a picture from the site. http://1.1.1.1/, used to describe the connection to the service. The authors seem to be quite confident in the quality of their DNS (however, it’s hard to expect anything else from Cloudflare):
One can fully understand Cloudflare, the creator of the service: they earn their bread by maintaining and developing one of the most popular CDN networks in the world (which functions include not only distributing content, but also hosting DNS zones), and, due to the desire of those , who is not well versed, teach those who they don't know, to that where to go in the global network, quite often suffers from blocking the addresses of their servers from let's not say who - so having a DNS that is not affected by "shouts, whistles and scribbles" for the company means less harm to their business. And technical advantages (a trifle, but nice: in particular, for clients of the free DNS Cloudflare, updating the DNS records of resources hosted on the company's DNS servers will be instant) make using the service described in the post even more interesting.
Only registered users can participate in the survey. Sign in, you are welcome.
Will you use the new service?
Yes, by simply specifying it in the OS and / or on the router
Yes, and I will use new protocols (DNS over HTTPs and DNS over TLS)
No, I have enough current servers (this is a public provider: Google, Yandex, etc.)