Me kohtume Cloudflare'i teenusega aadressidel 1.1.1.1 ja 1.0.0.1 ehk "avalik DNS-i riiul on saabunud!"

Me kohtume Cloudflare'i teenusega aadressidel 1.1.1.1 ja 1.0.0.1 ehk "avalik DNS-i riiul on saabunud!"

Cloudflare'i ettevõte esitatakse avalik DNS aadressidel:

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

Väidetavalt on poliitika "privaatsus kõigepealt", et kasutajad saaksid oma taotluste sisu suhtes meelerahu olla.

Teenus on huvitav selle poolest, et lisaks tavapärasele DNS-ile pakub see tehnoloogiate kasutamise võimalust DNS-over-TLS и DNS-üle HTTPS-i, mis takistab oluliselt teenusepakkujatel teie päringuid pealt kuulamast – ja kogub statistikat, jälgib ja haldab reklaame. Cloudflare väidab, et teadaande kuupäev (1. aprill 2018 või 04/01 Ameerika noodikirjas) ei valitud juhuslikult: mis teisel päeval aastas esitatakse "neli ühikut"?

Kuna Habri publik on tehniliselt asjatundlik, on traditsiooniline rubriik "miks teil DNS-i vaja on?" Panen selle postituse lõppu, aga siinkohal toon välja veel praktiliselt kasulikud asjad:

Kuidas uut teenust kasutada?

Kõige lihtsam on määrata ülaltoodud DNS-serveri aadressid oma DNS-kliendis (või kasutatava kohaliku DNS-serveri sätetes ülesvoolu). Kas tavaväärtusi on mõtet asendada Google DNS (8.8.8.8 jne) või veidi harvem Yandexi avalikud DNS-serverid (77.88.8.8 ja teised sarnased) Cloudflare'i serveritele - nemad otsustavad teie eest, kuid räägivad algaja eest ajakava reageerimiskiirus, mille järgi on Cloudflare kõigist konkurentidest kiirem (selgitan: mõõtmised tegi kolmanda osapoole teenus ja kiirus konkreetse kliendi puhul võib muidugi erineda).

Me kohtume Cloudflare'i teenusega aadressidel 1.1.1.1 ja 1.0.0.1 ehk "avalik DNS-i riiul on saabunud!"

Palju huvitavam on töötada uute režiimidega, kus päring lendab serverisse krüptitud ühenduse kaudu (tegelikult tagastatakse vastus selle kaudu), mainitud DNS-over-TLS ja DNS-over-HTTPS. Kahjuks ei toetata neid "kastist väljas" (autorite arvates on see "veel"), kuid nende tööd pole keeruline oma tarkvaras (või isegi riistvaras) korraldada:

DNS HTTP-de kaudu (DoH)

Nagu nimigi ütleb, toimub suhtlus HTTPS-kanali kaudu, mis tähendab

  1. maandumispunkti (lõpp-punkti) olemasolu - see asub aadressil https://cloudflare-dns.com/dns-queryJa
  2. klient, kes saab päringuid saata ja vastuseid vastu võtta.

Päringud võivad olla DNS Wireformat vormingus, mis on määratletud RFC1035 (saadetakse POST- ja GET-HTTT-meetoditega) või JSON-vormingus (GET-HTTP-meetodi abil). Mulle isiklikult tundus idee teha DNS-päringuid HTTP-päringute kaudu ootamatu, kuid selles on ratsionaalne tera: selline päring läbib paljusid liikluse filtreerimissüsteeme, vastuste sõelumine on üsna lihtne ja päringute genereerimine veelgi lihtsam. Turvalisuse eest vastutavad tavalised raamatukogud ja protokollid.

Taotlege näiteid otse dokumentatsioonist:

HANGI taotlus DNS Wireformat vormingus

$ 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-i päring DNS Wireformat vormingus

$ 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

Sama, kuid kasutab JSON-i

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

Ilmselgelt saab haruldane (kui vähemalt üks) koduruuter sel viisil DNS-iga töötada, kuid see ei tähenda, et tugi homme ei ilmuks - ja huvitaval kombel saame siin oma rakenduses DNS-iga töötamist üsna hästi rakendada (nagu juba hakkan Mozillat tegema, ainult Cloudflare'i serverites).

DNS TLS-i kaudu

Vaikimisi edastatakse DNS-päringud ilma krüptimiseta. DNS TLS-i kaudu on viis nende saatmiseks turvalise ühenduse kaudu. Cloudflare toetab DNS-i TLS-i kaudu standardpordis 853, nagu ette nähtud RFC7858. See kasutab pilvflare-dns.com hosti jaoks välja antud sertifikaati, toetatud on TLS 1.2 ja TLS 1.3.

Ühenduse loomine ja protokolli järgi töötamine käib umbes nii:

  • Enne DNS-ühenduse loomist salvestab klient base64-kodeeringuga SHA256 räsi cloudflare-dns.com TLS-sertifikaadist (nimetatakse SPKI-ks).
  • DNS-klient loob TCP-ühenduse saidiga cloudflare-dns.com:853
  • DNS-klient käivitab TLS-i käepigistuse
  • TLS-i käepigistuse käigus esitab cloudflare-dns.com host oma TLS-sertifikaadi.
  • Kui TLS-ühendus on loodud, saab DNS-klient saata DNS-päringuid turvalise kanali kaudu, mis takistab päringute ja vastuste pealtkuulamist ja võltsimist.
  • Kõik TLS-ühenduse kaudu saadetud DNS-päringud peavad järgima DNS-i saatmine TCP kaudu.

TLS-i kaudu DNS-i kaudu päringu näide:

$ 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

Tundub, et see valik töötab kõige paremini kohalike DNS-serverite puhul, mis teenindavad kohaliku võrgu või ühe kasutaja vajadusi. Tõsi, standardi toel pole väga hea, aga - loodame!

Kaks sõna selgituseks selle kohta, millest vestlus räägib

Lühend DNS tähistab domeeninime teenust (seetõttu on sõna "DNS-teenus" rääkimine mõnevõrra üleliigne, lühend sisaldab juba sõna "teenus") ja seda kasutatakse lihtsa ülesande lahendamiseks - aru ​​saada, milline IP-aadress konkreetsel hostinimel on. Iga kord, kui inimene klõpsab lingil või sisestab brauseri aadressiribale aadressi (näiteks midagi sellist nagu "https://habrahabr.ru/post/346430/"), püüab inimarvuti välja selgitada, millisele serverile lehe sisu hankimiseks päring saata. Habrahabr.ru puhul sisaldab DNS-i vastus veebiserveri IP-aadressi märge: 178.248.237.68 ja seejärel proovib brauser juba määratud IP-aadressiga serveriga ühendust võtta.

DNS-server, olles saanud päringu "mis on hosti nimega habrahabr.ru IP-aadress?", määrab omakorda, kas ta teab midagi määratud hosti kohta. Kui ei, siis teeb see päringu teistele maailma DNS-serveritele ja proovib samm-sammult välja mõelda vastuse esitatud küsimusele. Selle tulemusena saadetakse leitud andmed lõpliku vastuse leidmisel neid veel ootavale kliendile, lisaks salvestatakse need DNS-serveri enda vahemällu, mis võimaldab järgmisel korral sarnasele küsimusele palju kiiremini vastata.

Levinud probleem seisneb selles, et esiteks edastatakse DNS-päringuandmed selgelt (mis annab kõigile, kellel on juurdepääs liiklusvoole, võimaluse eraldada DNS-päringud ja saadud vastused ning seejärel neid oma eesmärkidel sõeluda; see annab võimalus sihtida reklaame DNS-kliendi jaoks täpselt, mis on üsna palju!). Teiseks kipuvad mõned Interneti-teenuse pakkujad (me ei näita näpuga, aga mitte kõige väiksemad) reklaame näitama ühe või teise nõutud lehe asemel (mis on rakendatud üsna lihtsalt: habranabr.ru päringu jaoks määratud IP-aadressi asemel hostinimi, juhuslik isik Nii tagastatakse pakkuja veebiserveri aadress, kuhu kuulutust sisaldav lehekülg serveeritakse). Kolmandaks on Interneti-juurdepääsu pakkujaid, kes rakendavad mehhanismi üksikute saitide blokeerimise nõuete täitmiseks, asendades blokeeritud veebiressursside IP-aadresside õiged DNS-vastused oma serveri IP-aadressiga, mis sisaldab tüngalehti (selle tulemusena on juurdepääs sellised saidid märgatavalt keerulisemad) või teie filtreerimist teostava puhverserveri aadressile.

See peaks ilmselt olema pilt saidilt. http://1.1.1.1/, mida kasutatakse teenusega ühenduse kirjeldamiseks. Tundub, et autorid on oma DNS-i kvaliteedis üsna kindlad (samas on raske Cloudflare'ilt midagi muud oodata):

Me kohtume Cloudflare'i teenusega aadressidel 1.1.1.1 ja 1.0.0.1 ehk "avalik DNS-i riiul on saabunud!"

Teenuse loojast Cloudflare'ist saab täiesti aru: nad teenivad oma leiva maailma üht populaarseimat CDN-võrku hooldades ja arendades (mille funktsioonid ei hõlma mitte ainult sisu levitamist, vaid ka DNS-tsoonide hostimist) ning tänu nende soov, kes pole hästi kursis, õpetage neid keda nad ei tea, sellele kuhu minna globaalses võrgus kannatab üsna sageli oma serverite aadresside blokeerimise pärast ärme ütle kes - seega tähendab DNS-i olemasolu, mida ettevõtte jaoks ei mõjuta "hüüded, viled ja kritseldused", nende äritegevusele vähem kahju. Ja tehnilised eelised (pisiasi, kuid tore: eriti tasuta DNS Cloudflare'i klientide jaoks on ettevõtte DNS-serverites hostitud ressursside DNS-kirjete värskendamine kohene) muudavad postituses kirjeldatud teenuse kasutamise veelgi huvitavamaks.

Küsitluses saavad osaleda ainult registreerunud kasutajad. Logi sissepalun.

Kas kasutate uut teenust?

  • Jah, lihtsalt määrates selle OS-is ja/või ruuteris

  • Jah, ja ma kasutan uusi protokolle (DNS üle HTTP ja DNS TLS-i kaudu)

  • Ei, mul on piisavalt praeguseid servereid (see on avalik pakkuja: Google, Yandex jne)

  • Ei, ma isegi ei tea, mida ma praegu kasutan

  • Ma kasutan oma rekursiivset DNS-i koos SSL-tunneliga

693 kasutajat hääletas. 191 kasutaja jäi erapooletuks.

Allikas: www.habr.com

Lisa kommentaar