Tere tulemast Cloudflare teenusele, aadressidel 1.1.1.1 ja 1.0.0.1, või "avalikke DNS-e on juurde tulnud!"

Ettevõte Cloudflare esitles avalikud DNS-d aadressidel:

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

Kinnitavad, et kasutatakse „Privacy first“ poliitikat, nii et kasutajad võivad olla mures oma päringute sisu pärast.

Teenust iseloomustab see, et koos tavapärase DNS-iga pakub see võimalust kasutada tehnoloogiaid DNS-over-TLS ja DNS-over-HTTPS, mis takistab provideritel päringute teel jälgida teie päringuid — ja koguda statistikat, jälgida, hallata reklaami. Cloudflare kinnitab, et avalikustamise kuupäev (1. aprill 2018, ehk 04/01 Ameerika konventsioonis) valiti mitte juhuslikult: millisel muul päeval aastas esitleda „nelja üht“?

Kuna Habr'i publik on tehniliselt haritud, panen traditsioonilise jaotuse „miks on DNS vajalik?“ postituse lõppu ja räägin siin rohkem praktiliselt kasulikest asjadest:

Kuidas uut teenust kasutada?

Lihtsaim on märkida oma DNS-kliendis (või kasutada upstream'i oma kohaliku DNS-serveri seadistustes) eelnevalt mainitud DNS-aadressidserveritele. Kas on mõtet asendada tuttavad väärtused Google'i DNS (8.8.8.8 jne), või vähem levinud Yandex'i avalikud DNS-serverid (77.88.8.8 ja sarnased) Cloudflare'i serveritega — otsustavad teie, kuid algaja kasuks räägib graafik vastuste kiirusest, mille kohaselt töötab Cloudflare kiiremini kui kõik konkurendid (täpsustan: mõõtmised on tehtud kolmanda osapoole teenuse poolt ja kiirus konkreetse kliendini võib muidugi erineda).

Kaugel huvitavam on töö uute režiimidega, mille korral päring suundub server krüpteeritud ühenduse kaudu (vastus naaseb samuti selle kaudu), nimetatud DNS-over-TLS ja DNS-over-HTTPS. Kahjuks ei toetata neid „kastist välja“ (autorid usuvad, et see on „hetkeks“), kuid nende töö korraldamine oma tarkvaras (või isegi oma seadmes) ei ole keeruline:

DNS over HTTPS (DoH)

Nagu nimest tuleneb, toimub suhtlemine HTTPS-kanali peal, mis eeldab

1. maandumiskohta (endpoint) — see asub aadressil https://cloudflare-dns.com/dns-query, ja
2. klienti, kes oskab saata päringuid ja vastu võtta vastuseid.

Päringud võivad olla kas DNS Wireformat formaadis, mis on määratletud RFC1035 (saabuma HTTP meetoditega POST ja GET), või JSON vormingus (kasutatakse HTTP meetodit GET). Isiklikult tundub mulle idee teha DNS-päringuid HTTP-päringute kaudu üllatav, kuid selles on oma tõde: selline päring läbib paljusid liiklusfilter süsteeme, vastuseid on piisavalt lihtne parsida ja päringute koostamine on veelgi lihtsam. Turvalisuse eest vastutavad tuttavad teegid ja protokollid.

Päringute näidised otse dokumentatsioonist:

GET-päring DNS Wireformat'i vormingus

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Kasutades HTTP2, server toetab mitme kasutuse.
* Ühenduse olek muutus (HTTP/2 kinnitatud)
* Kopeeritakse HTTP/2 andmed voogude puhverdusse seose puhverdusse pärast uuendamist: len=0
* Kasutades voogu ID: 1 (lihtne käepide 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*

* Ühenduse olek muutus (MAX_CONCURRENT_STREAMS uuendatud)!
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 baidi andmed]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Ühendus #0 hostiga cloudflare-dns.com jäi puutumata
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-päring DNS Wireformat'i vormingus

$ echo -n 'q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | base64 -D | curl -H 'Content-Type: application/dns-udpwireformat' --data-binary @- https://cloudflare-dns.com/dns-query -o - | hexdump

{ [49 baidi andmed]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Ühendus #0 hostiga cloudflare-dns.com jäi puutumata
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

Sama, aga JSON-i kasutades

$ 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"
    }
  ]
}

On ilmne, et harv (kui mitte ükski) koduruuter ei oska DNS-iga nii töötada, kuid see ei tähenda, et tugi ei võiks homme saabuda — ja mis huvitav, siin saame täiesti rakendada DNS-i töötamist oma rakenduses (nagu juba plaanib Mozilla, just Cloudflare serverites).

DNS TLS-i kaudu

Vaikimisi edastatakse DNS-päringud krüpteerimata. DNS üle TLS on viis edastada need turvalise ühenduse kaudu. Cloudflare toetab DNS-i üle TLS-i standardsel pordil 853, nagu ette nähtud. RFC7858. Selleks kasutatakse TLS-sertifikaati, mis on välja antud hostile cloudflare-dns.com ja toetatakse TLS 1.2 ja TLS 1.3.

Seose loomine ja protokolli kasutamine toimub umbes nii:

• Enne DNS-iga ühenduse loomist salvestab klient base64 kodeeritud SHA256 räsimise TLS-sertifikaadist cloudflare-dns.com (tuntud kui SPKI).
• DNS klient loob TCP-ühenduse cloudflare-dns.com:853.
• DNS klient alustab TLS-ühenduse loomise protseduuri.
• TLS-ühenduse loomise protsessi käigus esitab host cloudflare-dns.com oma TLS-sertifikaadi.
• Kui TLS-ühendus on loodud, saab DNS klient edastada DNS-päringud turvalise kanali kaudu, mis takistab kuulamist ja päringute ning vastuste valeandmeid.
• Kõik TLS-ühenduse kaudu edastatud DNS-päringud peavad vastama spetsifikatsioonile DNS-i edastamine TCP kaudu.

Näide päringust DNS üle TLS-i:

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Küsimine omaniku (example.com.), klassi (1), tüübi (1), serveri (1.1.1.1), pordi (853), protokolli (TCP)
;; DEBUG: TLS, imporditud 170 süsteemi sertifikaati
;; DEBUG: TLS, saadud sertifikaadi hierarhia:
;; 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, sertifikaadi PIN-i kontroll vahele jäänud
;; DEBUG: TLS, sertifikaat on usaldusväärne.
;; TLS sessioon (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; staatus: NOERROR; id: 58548
;; Lipud: qr rd ra; KÜSIMUS: 1; VASTUS: 1; AUTORITEET: 0; LISATUD: 1

;; EDNS PSEUDOSECTION:
;; Versioon: 0; lipud: ; UDP suurus: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; KÜSIMUSE SECTION:
;; example.com.             IN  A

;; VASTUSE SECTION:
example.com.            2347    IN  A   93.184.216.34

;; Vastatud 468 B
;; Aeg 2018-03-31 15:20:57 PDT
;; Aadressilt 1.1.1.1@853(TCP) ajas 12.6 ms

See variant näib sobivat paremini kohalikele DNS-serveritele, mis teenindavad kohaliku võrgu vajadusi või üksikuid kasutajaid. Kahjuks ei ole standardi toetus väga hea, aga — loodame parimat!

Kaks sõna selgituseks, millest jutt käib

Lühend DNS tähistab Domeen Nime Teenust (nii et öelda „DNS teenus“ on natuke liialdatud, sest lühendis on juba sõna „teenus“), ja seda kasutatakse lihtsa ülesande lahendamiseks — mõista, milline IP-aadress kuulub konkreetsele hostinimele. Iga kord, kui inimene klõpsab lingil või kirjutab brauseri aadressiribale aadressi (ütleme midagi sellist nagu "https://habrahabr.ru/post/346430/In the process, the computer attempts to understand which server to route the request to in order to retrieve the page content. In the case of habrahabr.ru, the response from DNS will contain a reference to the IP address of the web server: 178.248.237.68, and then the browser will try to connect with 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, after finding the final answer, the retrieved data is sent back to the still waiting client, plus it is saved in the cache of the DNS server itself, allowing it to respond to such questions much faster next time.

A common problem is that, first of all, DNS query data is transmitted in plain text (which allows anyone with access to the traffic stream to extract DNS queries and the responses received, and analyze them for their own purposes; this enables targeted advertising with precision for the DNS client, which is quite significant!). Secondly, some internet providers (let's not point fingers, but they are not the smallest) tend to display ads instead of the requested page (which is implemented quite simply: instead of the specified IP address for the request by the host name habranabr.ru, the user randomly receives the IP address of the provider's web server, where a page containing advertisements is served). Thirdly, there are internet access providers that implement mechanisms to enforce requirements to block specific sites by substituting correct DNS responses for the IP addresses of blocked web resources with the IP address of their server containing placeholder pages (resulting in significantly more difficult access to such sites), or to their proxy server that filters the content.

Here, it is probably necessary to insert an image from the site http://1.1.1.1/, which serves to describe the connection to the service. The authors are quite confident in the quality of their DNS work (however, one cannot expect anything else from Cloudflare):

On täiesti arusaadav, miks Cloudflare, teenuse pakkuja, seda teeb: nad teenivad oma leiba, toetades ja arendades ühte maailma populaarseimat CDN-võrgustikku (mille funktsioonide hulka kuulub mitte ainult sisu jagamine, vaid ka DNS tsoonide hostimine). Ja kuna nad soovivad, et need, kes ei ole väga kursis,, õpetaksid neid, keda nad ei tunne,, sellele, kuhu minna globaalvõrgus, kannatavad nad sageli blokeeringute tõttu, mis on suunatud nende serverite aadressidele, ärme räägi sellest, — seega tähendab DNS, mis ei allu "karjumistele, viledelele ja kirjadele", ettevõttele vähem kahju nende äritegevusele. Lisaks on tehnilised eelised (väike, aga meeldiv: näiteks Cloudflare tasuta DNS-i klientide jaoks ressursside DNS-kirjete värskendamine, mis on majutatud ettevõtte DNS-serverites, toimub koheselt) muudab kirjeldatud teenuse kasutamise veelgi huvitavamaks.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Kas kavatsete uut teenust kasutada?

• Jah, lihtsalt määrates selle OS-is ja/või ruuteris
• Jah, ja hakkan kasutama uusi protokolle (DNS over HTTPs ja DNS over TLS)
• Ei, mulle piisab praegustest serveritest (need on avalikud teenusepakkujad: Google, Yandex jne.)
• Ei, ma ei tea isegi, mida ma praegu kasutan
• Kasutab oma rekurssiivseid DNS-e, millele pääseb SSL tunneli kaudu

Hääletas 693 kasutajat. 191 kasutajat jäid erapooletuks.

Allikas: habr.com