Compania Cloudflare a prezentat DNS publice la adresele:
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
Se afirmă că se folosește politica „Privacy first”, astfel că utilizatorii pot fi liniștiți în legătură cu conținutul cererilor lor.
Serviciul este interesant deoarece, pe lângă DNS-ul obișnuit, oferă posibilitatea de a folosi tehnologii DNS-over-TLS și DNS-over-HTTPS, ceea ce va împiedica semnificativ ISP-urile să asculte cererile tale pe parcursul acestora — și să strângă statistici, să urmărească, să gestioneze publicitatea. Cloudflare susține că data anunțului (1 aprilie 2018, sau 04/01 în notația americană) a fost aleasă nu întâmplător: în ce altă zi a anului să se prezinte „patru unități”?
Având în vedere că publicul de pe Habr este tehnic pregătit, am pus tradiționala secțiune „de ce este necesar DNS?” la sfârșitul postării, iar aici voi prezenta lucruri mai practic utile:
Cum se folosește noul serviciu?
Cea mai simplă metodă este să indicăm în clientul nostru DNS (sau ca upstream în setările serverului DNS local folosit) adresele DNS menționate mai sus,servere. Are sens să înlocuiți valorile obișnuite DNS-urile Google (8.8.8.8 etc.), sau cele puțin mai folosite serverele publice DNS de la Yandex (77.88.8.8 și similare) cu serverele de la Cloudflare — veți decide voi, dar pentru începători vorbește graficul timpului de răspuns, conform căruia Cloudflare funcționează mai repede decât toți competitorii (precizez: măsurătorile au fost efectuate de un serviciu terț, iar viteza pentru un client specific poate varia).
Mult mai interesantă este munca cu noile moduri, în care cererea pleacă pe serverul printr-o conexiune criptată (de fapt, răspunsul se întoarce pe aceeași cale), menționate DNS-over-TLS și DNS-over-HTTPS. Din păcate, „din cutie” acestea nu sunt suportate (autorii cred că este „până acum”), dar organizarea funcționării lor în software-ul tău (sau chiar pe hardware-ul tău) nu este dificilă:
DNS over HTTPs (DoH)
Așa cum sugerează numele, comunicarea se desfășoară pe un canal HTTPS, ceea ce implică
- existenta unui punct de aterizare (endpoint) — acesta se află la adresa https://cloudflare-dns.com/dns-query, și
- un client care știe să trimită cereri și să primească răspunsuri.
Cererea poate fi fie în formatul DNS Wireformat, definit în RFC1035 (să se trimită metodele HTTP POST și GET), sau în format JSON (se folosește metoda HTTP GET). Personal, ideea de a face cereri DNS prin cereri HTTP mi s-a părut surprinzătoare, dar ideea are un sâmbure de rațiune: o astfel de cerere va trece prin multe sisteme de filtrare a traficului, este destul de simplu de parsat răspunsurile, iar formarea cererilor este și mai simplă. Siguranța este asigurată de bibliotecile și protocoalele familiare.
Exemple de cereri, direct din documentație:
Cerere GET în format DNS Wireformat
$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Folosind HTTP2, serverul suportă utilizarea multiplă
* Starea conexiunii s-a schimbat (HTTP/2 confirmat)
* Copierea datelor HTTP/2 în buffer-ul de conexiune după upgrade: len=0
* Folosind ID-ul stream-ului: 1 (handle ușor 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*
* Starea conexiunii s-a schimbat (MAX_CONCURRENT_STREAMS actualizat)!
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
* Conexiunea #0 la gazda cloudflare-dns.com a rămas 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
Cerere POST în format 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
* Conexiunea #0 la gazda cloudflare-dns.com a rămas 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
Același lucru, dar folosind 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"
}
]
}
Este evident că un router de acasă rar (dacă există vreunul) știe să funcționeze astfel cu DNS, dar asta nu înseamnă că suportul nu va apărea mâine — și, interesant, aici putem implementa gestionarea DNS în aplicația noastră (așa cum deja își propune să facă Mozilla, exact pe serverele Cloudflare).
DNS over TLS
În mod implicit, cererile DNS sunt trimise fără criptare. DNS over TLS este o modalitate de a le trimite printr-o conexiune securizată. Cloudflare suportă DNS over TLS pe portul standard 853, conform specificațiilor. RFC7858. Acesta utilizează un certificat emis pentru gazda cloudflare-dns.com, suportând TLS 1.2 și TLS 1.3.
Stabilirea conexiunii și funcționarea protocolului se desfășoară aproximativ astfel:
- Până la stabilirea conexiunii, clientul DNS stochează hash-ul SHA256 al certificatului TLS pentru cloudflare-dns.com (numit SPKI), codificat în base64.
- Clientul DNS stabilește o conexiune TCP cu cloudflare-dns.com:853
- Clientul DNS inițiază procedura de stabilire a conexiunii TLS.
- În timpul stabilirii conexiunii TLS, gazda cloudflare-dns.com prezintă certificatul său TLS.
- Odată ce conexiunea TLS este stabilită, clientul DNS poate trimite cereri DNS prin canalul protejat, ceea ce împiedică interceptarea și falsificarea cererilor și răspunsurilor.
- Toate cererile DNS trimise prin conexiunea TLS trebuie să respecte specificațiile privind trimiterea DNS prin TCP..
Exemplu de cerere prin DNS over TLS:
$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Interogare pentru proprietar(example.com.), clasă(1), tip(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, importate 170 certificatul de sistem
;; DEBUG: TLS, certificat primit ierarhic:
;; 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, sărați verificarea PIN-ului certificatului
;; DEBUG: TLS, certificatul este de încredere.
;; sesiune TLS (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: INTEROGARE; stare: NOERROR; id: 58548
;; Fluturas: qr rd ra; INTEROGARE: 1; RĂSPUNS: 1; AUTORITATE: 0; SUPLIMENTAR: 1
;; SECȚIUNE PSEUDOEDNS:
;; Versiune: 0; fluturas: ; dimensiune UDP: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B
;; SECȚIUNE DE ÎNTREBARE:
;; example.com. IN A
;; SECȚIUNE DE RĂSPUNS:
example.com. 2347 IN A 93.184.216.34
;; A primit 468 B
;; Timp 2018-03-31 15:20:57 PDT
;; De la 1.1.1.1@853(TCP) în 12.6 ms
Această variantă pare să fie mai potrivită pentru serverele DNS locale, care deservesc nevoile unei rețele locale sau ale unui singur utilizator. Cu toate acestea, suportul pentru standard nu este foarte bun, dar — să sperăm!
Două cuvinte de explicație, despre ce este vorba
Acronimul DNS se traduce prin Domeniu Name Service (deci a spune „serviciul DNS” este oarecum redundant, pentru că în acronim este deja cuvântul „serviciu”), și este folosit pentru a rezolva o simplă problemă — a înțelege ce adresă IP are un anumit nume de gazdă. De fiecare dată când o persoană face clic pe un link sau introduce în bara de adrese a browserului o adresă (să zicem, ceva de genul „https://habrahabr.ru/post/346430/Computerul unei persoane încearcă să determine către ce server să direcționeze cererea pentru a obține conținutul paginii. În cazul habrahabr.ru, răspunsul de la DNS va conține indicația către adresa IP a serverului web: 178.248.237.68, iar apoi browserul va încerca să se conecteze la serverul cu adresa IP specificată.
La rândul său, serverul DNS, primind cererea „care este adresa IP a gazdei cu numele habrahabr.ru?”, determină dacă știe ceva despre gazda specificată. Dacă nu, el face o cerere către alte servere DNS din lume și, pas cu pas, încearcă să afle răspunsul la întrebarea pusă. În cele din urmă, când se găsește răspunsul final, datele găsite sunt trimise clientului care le așteaptă, plus sunt salvate în cache-ul serverului DNS, ceea ce va permite să răspundă mult mai repede la o întrebare similară data viitoare.
O problemă obișnuită este că, pe de o parte, datele cererilor DNS sunt transmise în mod deschis (ceea ce permite tuturor celor care au acces la fluxul de trafic să excludă cererile DNS și răspunsurile primite, apoi să le analizeze pentru scopurile proprii; aceasta oferă posibilitatea de a targeta publicitatea cu precizie pentru clientul DNS, ceea ce nu este deloc puțin!). Pe de altă parte, unii furnizori de internet (fără a arăta cu degetul, dar nu cei mai mici) au tendința de a afișa reclame în locul paginilor solicitate (ceea ce se face foarte simplu: în loc să returneze adresa IP specificată pentru cererea pe numele gazdei habranabr.ru, persoanei i se returnează aleatoriu adresa serverului web al furnizorului, unde se oferă o pagină ce conține reclame). În al treilea rând, există furnizori de acces la internet care implementează un mecanism de blocare a anumitor site-uri, prin înlocuirea răspunsurilor DNS corecte cu adrese IP ale site-urilor web blocate cu cele ale serverului lor, care conține pagini de tip glumă (în rezultat, accesul la astfel de site-uri devine semnificativ mai complicat), sau către adresa serverului lor proxy care efectuează filtrarea.
Aici, probabil, ar trebui să fie plasată o imagine de pe site http://1.1.1.1/, care este utilizată pentru a descrie conexiunea la serviciu. Autorii, după cum se vede, sunt complet încrezători în calitatea funcționării DNS-ului lor (totuși, de la Cloudflare este greu să aștepți altceva):
Este complet de înțeles pentru compania Cloudflare, creatorul serviciului: ei își câștigă existența susținând și dezvoltând una dintre cele mai populare rețele CDN din lume (printre funcțiile acesteia se numără nu doar livrarea de conținut, ci și găzduirea zonelor DNS), și, din dorința de a-i ajuta pe cei care nu se pricep foarte bine, să îi învețe pe cei pe care nu îi cunosc, cum să navigheze în rețeaua globală, suferă destul de des din cauza blocării adreselor serverelor lor de către nu vom menționa cine — astfel că un DNS, care nu este supus influenței "strigătelor, fluierăturilor și scrisorelor", reprezintă pentru companie un prejudiciu mai mic pentru afacerea lor. Iar avantajele tehnice (o chestiune mică, dar plăcută: în special pentru clienții DNS-ului gratuit Cloudflare, actualizarea înregistrărilor DNS ale resurselor găzduite pe serverele DNS ale companiei va fi instantanee) fac utilizarea serviciului descris în postare și mai interesantă. Veți folosi noul serviciu?
Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.
Da, doar specificându-l în OS și/sau pe router
- Da, și voi folosi noile protocoale (DNS over HTTPs și DNS over TLS)
- Nu, îmi sunt suficiente serverele actuale (acesta este un furnizor public: Google, Yandex etc.)
- Nu, nici nu știu ce folosesc acum
- Folosesc propriile mele DNS recursive cu tunel SSL către ele
- Au votat 693 de utilizatori. 191 de utilizatori s-au abținut.
🥇Întâmpinăm serviciul de la Cloudflare pe adresele 1.1.1.1 și 1.0.0.1, sau "am avut parte de o nouă achiziție în rândul DNS-urilor publice!" | ProHoster
Sursa: habr.com
