
Kompania Cloudflare ka prezantuar DNS publik në adresat:
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
Afirmohet se përdoret politika «Privatësia e parë», kështu që përdoruesit mund të jenë të qetë për përmbajtjen e pyetjeve të tyre.
Shërbimi është i interesant sepse përveç DNS normal ofron mundësinë e përdorimit të teknologjive DNS-over-TLS dhe DNS-over-HTTPS, e cila do ta pengojë rëndë ofruesit e shërbimeve të monitorojnë pyetjet tuaja në rrugën e tyre — dhe të mbledhin statistikë, të kontrollojnë, t'i drejtojnë reklamat. Cloudflare pretendon se data e shpalljes (1 prill 2018, ose 04/01 në notacionin amerikan) u zgjodh rastësisht: në cilin ditë tjetër të vitit mund të paraqitet «katër njësi»?
Duke qenë se publiku i Habra është teknikisht i arsimuar, seksioni tradicional «përse na nevojitet DNS?» do ta vendosja në fund të postimit, dhe këtu do të përmend gjëra më praktikisht të dobishme:
Si ta përdorim shërbimin e ri?
Më e thjeshta — në klientin tuaj DNS (ose si upstream në cilësimet e serverit tuaj lokal DNS) tregoni adresat e mësipërme të DNS-serverëve. Ka kuptim të zëvendësohen vlerat e njohura DNS të Google (8.8.8.8 etj.), ose pak më pak të njohura serverët publikë të DNS të Yandex (77.88.8.8 dhe të ngjashme) me serverët nga Cloudflare — do ta vendosni ju, por për novice flet grafiku i shpejtësive të përgjigjeve, sipas të cilit Cloudflare punon më shpejt se të gjithë konkurrentët (duke sqaruar: matjet janë bërë nga një shërbim i tretë, dhe shpejtësia deri te klienti konkret, natyrisht, mund të ndryshojë).

Më interesante është puna me modulet e reja, në të cilat kërkesa shkon në server përmes një lidhjeje të enkriptuar (përveç, përgjigjja kthehet po ashtu përmes saj), të përmendura DNS-over-TLS dhe DNS-over-HTTPS. Fatkeqësisht, «nga kuti» ato nuk mbështeten (autorët besojnë se është «ndoshta»), por është e lehtë të organizoni punën e tyre në softuerin tuaj (ose madje edhe në harduerin tuaj):
DNS over HTTPS (DoH)
Siç tregon titulli, komunikimi ndodh sipër kanalit HTTPS, që supozon
- praninë e një pikë rënieje (endpoint) — ajo ndodhet në adresën https://cloudflare-dns.com/dns-query, dhe
- një klient që di të dërgojë kërkesa, dhe të marrë përgjigje.
Kërkesat mund të jenë ose në formatin e DNS Wireformat, të përcaktuar në RFC1035 (të dërgojë me metodat HTTP POST dhe GET), ose në formatin JSON (përdoret metoda HTTP GET). Personalisht, ideja për të bërë kërkesa DNS përmes kërkesave HTTP më duket e papritur, megjithatë ka një thelb të arsyeshëm në të: një kërkesë e tillë do të kalojë shumë sisteme filtrimi të trafikut, është e thjeshtë për të përpunuar përgjigjet, ndërsa formimi i kërkesave është edhe më i thjeshtë. Për sigurinë përgjigjet bibliotekat dhe protokollet e njohura.
Shembuj kërkesash, direkt nga dokumentacioni:
Kërkesa GET në formatin DNS Wireformat
$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Përdorimi i HTTP2, serveri mbështet përdorim të shumëfishtë
* Gjendja e lidhjes ndryshoi (HTTP/2 e konfirmuar)
* Po kopjojmë të dhënat HTTP/2 në buffer-in e lidhjes pas azhurnimit: len=0
* Përdorimi i ID-së së rrjedhës: 1 (handle i lehtë 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*
* Gjendja e lidhjes ndryshoi (MAX_CONCURRENT_STREAMS përditësuar)!
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; skadon: 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
* Lidhja #0 me host cloudflare-dns.com mbeti e paprekur
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
Kërkesa POST në formatin 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
* Lidhja #0 me host cloudflare-dns.com mbeti e paprekur
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
E njëjta, por me përdorimin e 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"
}
]
}
Është evidente se një router i zakonshëm (nëse ndonjëherë ka një) nuk di të punojë kështu me DNS, por nuk do të thotë se mbështetja nuk do të shfaqet nesër — dhe, cuditërisht, këtu mund të realizojmë punën me DNS në aplikacionin tonë (siç është duke planifikuar të bëjë Mozilla, pikërisht në serverat e Cloudflare).
DNS mbi TLS
Me standard, kërkesat DNS dërgohen pa enkriptim. DNS mbi TLS është një mënyrë për t'i dërguar ato mbi një lidhje të sigurt. Cloudflare mbështet DNS mbi TLS në portin standard 853, siç parashikohet. RFC7858. Gjatë kësaj përdoret një certifikatë e lëshuar për hostin cloudflare-dns.com, mbështeten TLS 1.2 dhe TLS 1.3.
Krijimi i lidhjes dhe funksionimi i protokollit ndodhin përafërsisht kështu:
- Para se të krijohet lidhja me DNS, klienti ruan hash-in e certifikatës TLS të cloudflare-dns.com të koduar në base64 (i quajtur SPKI).
- Klienti DNS krijon një lidhje TCP me cloudflare-dns.com:853
- Klienti DNS iniciaton procedurën e dorëzimit TLS.
- Në procesin e dorëzimit TLS, hosti cloudflare-dns.com paraqet certifikatën e tij TLS.
- Sa herë që lidhet TLS, klienti DNS mund të dërgojë kërkesa DNS mbi kanalin e sigurt, duke parandaluar përgjojjen dhe falsifikimin e kërkesave dhe përgjigjeve.
- Të gjitha kërkesat DNS që dërgohen përmes lidhjes TLS duhet të përmbushin specifikatat për dërgimin e DNS mbi TCP..
Shembulli i një kërkese përmes DNS mbi TLS:
$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Kërkesa për pronarin(example.com.), klasa(1), lloji(1), server(1.1.1.1), porti(853), protokolli(TCP)
;; DEBUG: TLS, importoi 170 certifikata sistemike
;; DEBUG: TLS, mori hierarkinë e certifikatave:
;; 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, duke skipped kontrollin e PIN të certifikatës
;; DEBUG: TLS, Certifikata është e besueshme.
;; Sesioni TLS (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: KËRKESË; status: NOERROR; id: 58548
;; Flamuj: qr rd ra; KËRKESË: 1; PËRGJIGJE: 1; AUTORITET: 0; SHTESAT: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flamuj: ; madhësia UDP: 1536 B; kod i zgjeruar: NOERROR
;; PADDING: 408 B
;; NJËSI KËRKESË:
;; example.com. IN A
;; PËRGJIGJE NJËSI:
example.com. 2347 IN A 93.184.216.34
;; Marrë 468 B
;; Koha 2018-03-31 15:20:57 PDT
;; Nga 1.1.1.1@853(TCP) në 12.6 ms
Ky opsion duket se i përshtatet më mirë serverëve lokalë DNS që shërbejnë nevojat e një rrjeti lokal ose të një përdoruesi të vetëm. Megjithatë, mbështetja për standardin nuk është e shkëlqyer, por – le të shpresojmë!
Dy fjalë sqarimesh, mbi çfarë bëhet fjalë
Shkurtesa DNS shpjegohet si Domain Shërbimi i Emrave (pra, të thuash "shërbimi DNS" është disi e tepërt, në shkurtimin është tashmë fjala "shërbim"), dhe përdoret për të zgjidhur një problem të thjeshtë – të kuptojë se cili është adresa IP për një emër konkret hosti. Çdo herë kur një njeri klikoni në një link, ose fut adresën në shiritin e adresës së shfletuesit (të themi, diçka si "https://habrahabr.ru/post/346430/«), kompjuter i njeriut përpiqet të kuptojë se në cilin server duhet të dërgojë kërkesën për të marrë përmbajtjen e faqes. Në rastin e habrahabr.ru, përgjigjja nga DNS do të përmbajë një tregues për adresën IP të serverit të uebit: 178.248.237.68, dhe pastaj shfletuesi do të përpiqet të lidhë me serverin me adresën IP të specifikuar.
Nga ana tjetër, serveri DNS, pasi merr kërkesën «cila është adresa IP e hostit me emrin habrahabr.ru?», përcakton nëse ai di ndonjë gjë për hostin e dhënë. Nëse jo, ai bën një kërkesë te serverë të tjerë DNS në botë dhe, hap pas hapi, përpiqet të zbulojë përgjigjen për pyetjen e shtruar. Në fund, pasi të gjejë përgjigjen përfundimtare, të dhënat e gjetura dërgohen ende duke pritur klientit, plus ruhen në cache-në e vet serverit DNS, duke e lejuar që herën tjetër të përgjigjet për një pyetje të ngjashme shumë më shpejt.
Një problem i zakonshëm është se, së pari, të dhënat e kërkesave DNS transmetohen në një formë të hapur (çka i jep çdo personi që ka qasje në rrjedhën e trafikut mundësinë për të nxjerrë kërkesat dhe përgjigjet DNS dhe më pas për t'i analizuar ato për qëllime të tij; kjo i mundëson targetimin e reklamave me saktësi për klientin DNS, dhe kjo nuk është pak!). Së dyti, disa ofrues interneti (nuk do të tregojmë gishti, por nuk janë të vegjël) kanë tendencën të tregojnë reklama në vend të një faqeje të caktuar (kjo realizohet shumë thjeshtë: në vend të adresës IP të dhënë për kërkesën sipas emrit të hostit habranabr.ru, adresa e serverit të uebit të ofruesit kthehet rastësisht, ku shfaqet një faqe që përmban reklamë). Së treti, ekzistojnë ofrues të shërbimit të internetit që realizojnë mekanizmin e përmbushjes së kërkesave për bllokimin e disa faqeve, përmes zëvendësimit të përgjigjeve të duhura DNS për adresat IP të burimeve të bllokuara në IP të serverit të tyre, që përmban faqe zëvendësuese (si rezultat, qasja në këto faqe komplikohet ndjeshëm), ose në adresën e serverit të tyre proxy, që kryen filtrimin.
Këtu, ndoshta, duhet të vendosni një imazh nga faqja http://1.1.1.1/, që shërben për të përshkruar lidhjen me shërbimin. Autorët, siç duket, janë të sigurt për cilësinë e punës së DNS-it të tyre (ndërsa është e vështirë të presësh diçka tjetër nga Cloudflare):

Është krejtësisht e kuptueshme për kompaninë Cloudflare, krijuesin e shërbimit: ata fitojnë jetesën e tyre duke mbështetur dhe zhvilluar një nga rrjetet më të njohura CDN në botë (mes funksioneve të saj — jo vetëm shpërndarjen e përmbajtjes, por edhe hostimin e zonave DNS), dhe, për shkak të dëshirës së atyre që nuk janë shumë të informuar, për të mësuar ata që ata nuk i njohin, rreth se ku duhet të shkojnë në rrjetin global, shpesh vuajnë nga bllokimi i adresave të serverëve të tyre nga nuk do të flasim për kush — kështu që disponimi i DNS-së, që nuk është i ndikuar nga "klithmat, zerat dhe shënimet", për kompaninë do të thotë më pak dëm për biznesin e tyre. Dhe përfitimet teknike (një detaj të vogël, por të këndshëm: sidomos për klientët e DNS-së falas Cloudflare, përditësimi i regjistrave DNS të burimeve të vendosura në serverët DNS të kompanisë do të jetë momental) e bëjnë përdorimin e shërbimit të përshkruar në postim edhe më tërheqës. A do ta përdorni shërbimin e ri?
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutem.
Po, thjesht duke e caktuar atë në OS dhe/apo në router
- Po, dhe do të përdor protokollet e reja (DNS mbi HTTPs dhe DNS mbi TLS)
- Jo, më mjafton serveri aktual (këto janë ofrues publikë: Google, Yandex etj.)
- Jo, nuk e di as çfarë po përdor tani
- Përdor DNS-të e mia rekursive me një tunel SSL deri te ato
- 693 përdorues votuan. 191 përdorues abstenuan.
🥇 Po mirëpresim shërbimin nga Cloudflare në adresat 1.1.1.1 dhe 1.0.0.1, ose "ra dhe mbërriti rafti publik i DNS-ve!" | ProHoster
Burimi: habr.com
