Tere tulemast Cloudflare'i teenusesse aadressidel 1.1.1.1 ja 1.0.0.1, või "avalik DNS on kohal!"

Cloudflare esituse avatud DNS-aadressid:

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

Käib väide, et kasutatakse „Privacy first” poliitikat, nii et kasutajad saavad oma päringute sisu osas rahulikud olla.

Teenust iseloomustab see, et tavalise DNS-i kõrval pakub see ka tehnoloogiate kasutamise võimalust DNS-over-TLS ja plaane, et vaikimisi toetada, mis takistab teenusepakkujatel teie päringute teel teie päringute pealt kuulamist — ja statistika kogumist, jälgimist ning reklaami haldamist. Cloudflare väidab, et kuupäev, mil teade avaldati (1. aprill 2018, või 04/01 Ameerika märkuses), ei olnud juhuslik: mis muul päeval aastas esitleda „nelja ühte”?

Kuna Habr'i publik on tehniliselt osav, panen traditsioonilise jaotuse „miks on DNS vajalik?” postituse lõppu, samas kui siia toon praktiliselt kasulikud asjad:

Kuidas uut teenust kasutada?

Kõige lihtsam on oma DNS-klientides (või kohaliku DNS-serveri seadetes upstream-ina) märkida ülaltoodud DNS-aadressidserveritele. Kas on mõtet asendada tuntud väärtused Google'i DNS (8.8.8.8 jne), ehkki veidi vähem levinud Yandexi avalike DNS-serveritega (77.88.8.8 ja teised) Cloudflare'i serveritele — lahendab teie probleemi, kuid algaja jaoks on see räägitud. diagramm vastuste kiirus, mille kohaselt Cloudflare töötab kiiremini kui kõik konkurendid (täpsustan: mõõtmised on tehtud kolmanda osapoole teenuse poolt, ja kiirus konkreetse kliendini võib loomulikult erineda).

Olulisem on töö uute režiimidega, kus päring saadetakse server krüpteeritud ühenduse kaudu (päringule vastatakse samuti läbi selle), mainitud DNS-over-TLS ja DNS-over-HTTPS. Kahjuks ei toeta need „karbist välja” (autorid usuvad, et see on „praegu”), kuid nende töö korraldamine oma tarkvaras (või isegi oma riistvaral) ei ole keeruline:

DNS over HTTPs (DoH)

Nagu nimigi ütleb, toimub suhtlemine HTTPS-kanali kaudu, mis eeldab

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

Päringud võivad olla kas DNS Wireformati vormingus, nagu on määratletud RFC1035 (saata HTTP-meetoditega POST ja GET), või JSON-vormingus (kasutatakse HTTP-meetodit GET). Minu jaoks tundus idee teha DNS-päringuid läbi HTTP-päringute üllatavana, kuid selles on rationaalne tuum: selline päring läbib palju liikluse filtreerimise süsteeme, vastuste parseerimine on piisavalt lihtne, ja päringute koostamine — veelgi lihtsam. Turvalisuse tagavad tuttavad raamatukogud ja protokollid.

Päringute näited, otse dokumentatsioonist:

GET-päring DNS Wireformaatide vormingus

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Kasutatakse HTTP2, server toetab korduvat kasutust
* Ühenduse olek muutus (HTTP/2 kinnitatud)
* HTTP/2 andmed kopeeritakse voogude puhvrist ühenduse puhvri: len=0
* Kasutatakse voolu ID: 1 (lihtne käitlemine 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 ajakohastatud)!
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
* Ü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 Wireformaat

$ 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
* Ü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 selge, et haruldane (kui mitte ükski) kodus ruuter ei suuda DNS-iga nii töötada, kuid see ei tähenda, et toetust ei võiks homme tulla — huvitaval kombel saame siin täielikult rakendada DNS-i töötlemist oma rakenduses (nagu kavatseb teha Mozilla, just Cloudflare'i serverites).

DNS üle TLS

Vaikimisi saadetakse DNS päringud ilma krüpteerimiseta. DNS üle TLS on viis neid edastada kaitstud ühenduse kaudu. Cloudflare toetab DNS üle TLS-i standardporti 853, nagu ette näeb RFC7858. Sellega kasutatakse sertifikaati, mis on väljastatud hostile cloudflare-dns.com, toetatakse TLS 1.2 ja TLS 1.3.

Ühenduse loomine ja protokolli töötamine toimub umbes nii:

• Enne DNS-iga ühenduse loomist salvestab klient base64-dekooditud SHA256-häši TLS-sertifikaadist cloudflare-dns.com (nimetatakse SPKI)
• DNS klient loob TCP-ühenduse cloudflare-dns.com:853
• DNS klient algatab TLS handshake'i protseduuri
• TLS käepidemete protsessi käigus esitab host cloudflare-dns.com oma TLS sertifikaadi.
• Niipea kui TLS-ühendus on loodud, saab DNS klient saata DNS päringud kaitstud kanali kaudu, mis takistab kuulamist ja päringute ning vastuste valeesitust.
• Kõik TLS-ühenduse kaudu saadetud DNS-päringud peavad vastama spetsifikatsioonile DNS saatmiseks TCP kaudu.

Näide päringust DNS over TLS kaudu:

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Päring omaniku (example.com.), klassi (1), tüübi (1), serveri (1.1.1.1), port (853), protokolli (TCP) jaoks
;; DEBUG: TLS, importis 170 süsteemi sertifikaati
;; DEBUG: TLS, sai 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-kontroll jätatakse vahele
;; DEBUG: TLS, Sertifikaat on usaldusväärne.
;; TLS seanss (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548
;; Lippude: qr rd ra; PÄRING: 1; VASTUS: 1; AUHORITY: 0; LISAND: 1

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

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

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

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

See variant sobib paremini kohalikeks DNS-serveriteks, mille eesmärk on teenindada kohaliku võrgu vajadusi või ühe kasutaja vajadusi. Tõsi, standardi toetamisega pole kõik hästi, aga — loodame parimat!

Kaks sõna selgituseks, millest on jutt

Lühend DNS tähendab Domeen Name Service (nii et öelda "DNS-teenus" — on natuke ülearune, kuna lühendis on juba sõna "teenus"), ja seda kasutatakse lihtsa ülesande lahendamiseks — mõista, milline IP-aadress on konkreetse hostinimega seotud. Iga kord, kui inimene klõpsab lingil või kirjutab brauseri aadressiriba, näiteks midagi nagu "https://habrahabr.ru/post/346430/«), üritab tema arvuti mõista, kuhu serverisse tuleks lehekülje sisu taotlusega pöörduda. Näiteks habrahabr.ru puhul sisaldab DNS-i vastus viidet veebiserveri IP-aadressile: 178.248.237.68, ja seejärel proovib brauser juba ühendust võtta antud IP-aadressiga serveriga.

DNS-server, saades vastu küsimust "mis IP-aadress on hostil nimega habrahabr.ru?", määrab, kas tal on teavet mainitud hosti kohta. Kui ei, siis edastab ta päringu teistele DNS-serveritele maailmas ja samm-sammult üritab välja selgitada vastuse esitatud küsimusele. Lõpuks, kui lõplik vastus on leitud, saadetakse kogutud andmed tagasi ootavale kliendile ning salvestatakse ka DNS-serveri vahemälus, mis võimaldab järgmine kord vastata sarnasele küsimusele tunduvalt kiiremini.

Tavaline probleem seisneb peamiselt selles, et DNS-päringute andmed edastatakse avatud kujul (mis võimaldab kõigil, kes pääsevad juurde liiklusvoole, eristada DNS-päringuid ja saadud vastuseid ning seejärel neid oma eesmärkidel analüüsida; see annab reklaamimise võimaluse DNS-i kliendi täpsusega, mis on märkimisväärne!). Teiseks, mõned Interneti-teenuse pakkujad (me ei nimeta nimesid, kuid need pole just väikseimad) näitavad reklaame selle asemel, et näidata mingit küsitud lehte (see realiseeritakse üsna lihtsalt: earu, mis on hostname'i päringu IP-aadressi asemel, antakse inimesele juhusikult teenuse pakkuja veebiserveri aadress, kus kuvatakse reklaamidega leht). Kolmandaks, on olemas internetiühenduse pakkujad, kes kasutavad mehhanismi teatud saitide blokeerimise nõuete täitmiseks, asendades õiged DNS-vastused blokeeritavate veebiresursside IP-aadresside kohta enda serveri aadressiga, mis sisaldab vahepealseid lehti (seetõttu muutub juurdepääs neile saitidele märkimisväärselt keerulisemaks), või oma filtriteemaga proxy-serveri aadressiga.

Siin on tõenäoliselt koht, kuhu tuleks panna pilt veebisaidilt http://1.1.1.1/, mida kasutatakse teenuse ühenduse kirjeldamiseks. Autorid on selgelt kindlad oma DNS-i töö kvaliteedis (kuigi Cloudflare'lt on raske oodata midagi muud):

On täiesti võimalik mõista ettevõtet Cloudflare, teenuse loojat: nad teenivad oma leiva, toetades ja arendades üht maailma populaarseimat CDN-võrku (mille funktsioonide seas on mitte ainult sisu jaotamine, vaid ka DNS-tsoonide hostimine), ja, kuna nad tahavad õpetada neid, kes ei ole just väga kursis, õpetavad neid, keda nad ei tunne, sellele, kuidas ringi liikuda globaalsetes võrkudes, kannatavad nad piisavalt sageli oma serverite aadresside blokeerimise all ärgem rääkigem neist — nii et DNS-i olemasolu, mis ei ole mõjutatud „karjumiste, vilede ja paberitükkide” surveest, tähendab ettevõttele väiksemat kahju nende äritegevusele. Ja tehnilised eelised (väikese asi, kuid meeldiv: näiteks Cloudflare'i tasuta DNS-i klientide jaoks toimub DNS-kirjete värskendamine, mis on ettevõtte DNS-serverites majutatud ressursside osas, koheselt), muudavad postituses kirjeldatud teenuse kasutamise veelgi huvitavamaks.

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

Kas plaanite uut teenust kasutada?

• Jah, lihtsalt määrates selle operatsioonisüsteemis ja/või ruuteri seadetes
• Jah, ja hakkan kasutama uusi protokolle (DNS üle HTTPs ja DNS üle TLS)
• Ei, mul on piisavalt praeguseid servereid (need on avalikud teenusepakkujad: Google, Yandex jne.)
• Ei, ma ei tea isegi, millega ma praegu kasutan
• Kasutame oma rekursiivseid DNS-e, millel on SSL tunnel nende juurde

Hääletas 693 kasutajat. 191 kasutajat hoiduti hääletamast.

Allikas: habr.com