Mēs satiekam pakalpojumu no Cloudflare adresēs 1.1.1.1 un 1.0.0.1 jeb “publiskais DNS plaukts ir pienācis!”

Mēs satiekam pakalpojumu no Cloudflare adresēs 1.1.1.1 un 1.0.0.1 jeb “publiskais DNS plaukts ir pienācis!”

Uzņēmums Cloudflare uzrādīts publiskais DNS adresēs:

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

Tiek uzskatīts, ka šī politika ir "privātums pirmajā vietā", lai lietotāji varētu būt mierīgi par savu pieprasījumu saturu.

Pakalpojums ir interesants ar to, ka papildus ierastajam DNS nodrošina iespēju izmantot tehnoloģijas DNS-over-TLS и DNS pār HTTPS, kas ievērojami neļaus pakalpojumu sniedzējiem noklausīties jūsu pieprasījumus pieprasījumu ceļā — un apkopot statistiku, uzraudzīt, pārvaldīt reklāmas. Cloudflare apgalvo, ka paziņojuma datums (1. gada 2018. aprīlis vai 04. aprīlis amerikāņu apzīmējumā) nav izvēlēts nejauši: kurā vēl gada dienā tiks prezentētas “četras vienības”?

Tā kā Habra auditorija ir tehniski gudra, tradicionālā sadaļa "kāpēc jums ir nepieciešams DNS?" Ielikšu ieraksta beigās, bet te pastāstīšu praktiski noderīgākas lietas:

Kā izmantot jauno pakalpojumu?

Visvienkāršākā lieta ir norādīt iepriekš minētās DNS servera adreses savā DNS klientā (vai kā augšpus jūsu izmantotā vietējā DNS servera iestatījumos). Vai ir jēga aizstāt ierastās vērtības Google DNS (8.8.8.8 utt.), vai nedaudz retāk Yandex publiskie DNS serveri (77.88.8.8 un citi līdzīgi) uz serveriem no Cloudflare - viņi izlems jūsu vietā, bet runā iesācēja vārdā grafiku reakcijas ātrums, saskaņā ar kuru Cloudflare ir ātrāks par visiem konkurentiem (paskaidrošu: mērījumus veica trešās puses serviss, un ātrums konkrētam klientam, protams, var atšķirties).

Mēs satiekam pakalpojumu no Cloudflare adresēs 1.1.1.1 un 1.0.0.1 jeb “publiskais DNS plaukts ir pienācis!”

Daudz interesantāk ir strādāt ar jauniem režīmiem, kuros pieprasījums lido uz serveri pa šifrētu savienojumu (patiesībā caur to tiek atgriezta atbilde), minētajiem DNS-over-TLS un DNS-over-HTTPS. Diemžēl tie netiek atbalstīti “no kastes” (autori uzskata, ka tas ir “vēl”), taču nav grūti organizēt savu darbu savā programmatūrā (vai pat aparatūrā):

DNS, izmantojot HTTP (DoH)

Kā norāda nosaukums, saziņa notiek, izmantojot HTTPS kanālu, kas nozīmē

  1. nosēšanās punkta (gala punkta) klātbūtne - tas atrodas adresē https://cloudflare-dns.com/dns-queryUn
  2. klients, kas var nosūtīt pieprasījumus un saņemt atbildes.

Pieprasījumi var būt DNS Wireformat formātā, kas definēts RFC1035 (nosūtīts, izmantojot POST un GET HTTP metodes) vai JSON formātā (izmantojot GET HTTP metodi). Man personīgi ideja veikt DNS pieprasījumus, izmantojot HTTP pieprasījumus, šķita negaidīta, taču tajā ir racionāls grauds: šāds pieprasījums izturēs daudzas trafika filtrēšanas sistēmas, atbilžu parsēšana ir diezgan vienkārša, un pieprasījumu ģenerēšana ir vēl vienkāršāka. Par drošību atbild parastās bibliotēkas un protokoli.

Pieprasiet piemērus tieši no dokumentācijas:

IEGŪT pieprasījumu DNS Wireformat formātā

$ 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 pieprasījums DNS Wireformat formātā

$ 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

Tas pats, bet izmanto 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"
    }
  ]
}

Acīmredzot rets (ja vismaz viens) mājas maršrutētājs var strādāt ar DNS šādā veidā, taču tas nenozīmē, ka atbalsts neparādīsies rīt - un, kas ir interesanti, šeit mēs varam diezgan ieviest darbu ar DNS mūsu lietojumprogrammā (kā jau gatavojas taisīt Mozilla, tikai Cloudflare serveros).

DNS, izmantojot TLS

Pēc noklusējuma DNS vaicājumi tiek pārsūtīti bez šifrēšanas. DNS, izmantojot TLS, ir veids, kā tos nosūtīt, izmantojot drošu savienojumu. Cloudflare atbalsta DNS, izmantojot TLS standarta portā 853, kā noteikts RFC7858. Tiek izmantots resursdatoram cloudflare-dns.com izsniegts sertifikāts, tiek atbalstīts TLS 1.2 un TLS 1.3.

Savienojuma izveide un darbs saskaņā ar protokolu notiek apmēram šādi:

  • Pirms DNS savienojuma izveides klients saglabā base64 kodētu SHA256 hash no cloudflare-dns.com TLS sertifikāta (saukts par SPKI).
  • DNS klients izveido TCP savienojumu ar cloudflare-dns.com:853
  • DNS klients sāk TLS rokasspiedienu
  • TLS rokasspiediena procesa laikā resursdators cloudflare-dns.com uzrāda savu TLS sertifikātu.
  • Kad TLS savienojums ir izveidots, DNS klients var nosūtīt DNS pieprasījumus pa drošu kanālu, kas novērš pieprasījumu un atbilžu noklausīšanos un viltošanu.
  • Visiem DNS vaicājumiem, kas nosūtīti, izmantojot TLS savienojumu, ir jāatbilst DNS nosūtīšana, izmantojot TCP.

Pieprasījuma piemērs, izmantojot DNS, izmantojot TLS:

$ 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

Šķiet, ka šī opcija vislabāk darbojas vietējiem DNS serveriem, kas apkalpo vietējā tīkla vai viena lietotāja vajadzības. Tiesa, ar standarta atbalstu nav īpaši labi, bet - cerēsim!

Divi vārdi paskaidrojumam par to, par ko ir saruna

Saīsinājums DNS apzīmē Domain Name Service (tāpēc teikšana “DNS pakalpojums” ir nedaudz lieka, saīsinājumā jau ir vārds “service”), un to izmanto, lai atrisinātu vienkāršu uzdevumu – lai saprastu, kāda IP adrese ir konkrētam resursdatora nosaukumam. Katru reizi, kad lietotājs noklikšķina uz saites vai ievada adresi pārlūkprogrammas adreses joslā (piemēram, "https://habrahabr.ru/post/346430/"), cilvēka dators mēģina noskaidrot, kuram serverim nosūtīt pieprasījumu, lai iegūtu lapas saturu. Habrahabr.ru gadījumā atbilde no DNS saturēs tīmekļa servera IP adreses norādi: 178.248.237.68, un pēc tam pārlūkprogramma jau mēģinās sazināties ar serveri ar norādīto IP adresi.

Savukārt DNS serveris, saņēmis pieprasījumu “kāda ir resursdatora ar nosaukumu habrahabr.ru IP adrese?”, nosaka, vai tas kaut ko zina par norādīto resursdatoru. Ja nē, tas nosūta pieprasījumu citiem DNS serveriem pasaulē un soli pa solim mēģina izdomāt atbildi uz uzdoto jautājumu. Rezultātā, atrodot galīgo atbildi, atrastie dati tiek nosūtīti klientam, kurš tos joprojām gaida, kā arī tiek saglabāts paša DNS servera kešatmiņā, kas ļaus jums daudz ātrāk atbildēt uz līdzīgu jautājumu nākamajā reizē.

Izplatīta problēma ir tā, ka, pirmkārt, DNS vaicājumu dati tiek pārsūtīti skaidri (kas dod iespēju ikvienam, kam ir piekļuve trafika plūsmai, izolēt DNS vaicājumus un saņemtās atbildes un pēc tam parsēt tos saviem mērķiem; tas dod spēja mērķēt reklāmas ar precizitāti DNS klientam, kas ir diezgan daudz!). Otrkārt, daži interneta pakalpojumu sniedzēji (nerādīsim ar pirkstiem, bet ne mazākie) mēdz rādīt reklāmas vienas vai otras pieprasītās lapas vietā (kas tiek ieviesta pavisam vienkārši: norādītās IP adreses vietā habranabr.ru vaicājumam. resursdatora nosaukums, nejauša persona Tādējādi tiek atgriezta pakalpojumu sniedzēja tīmekļa servera adrese, kurā tiek apkalpota lapa, kurā atrodas reklāma). Treškārt, ir interneta piekļuves nodrošinātāji, kas ievieš mehānismu atsevišķu vietņu bloķēšanas prasību izpildei, aizstājot pareizās DNS atbildes par bloķēto tīmekļa resursu IP adresēm ar sava servera IP adresi, kurā ir nepilnīgas lapas (tā rezultātā tiek nodrošināta piekļuve šādas vietnes ir ievērojami sarežģītākas) vai uz jūsu starpniekservera adresi, kas veic filtrēšanu.

Tam, iespējams, vajadzētu būt attēlam no vietnes. http://1.1.1.1/, ko izmanto, lai aprakstītu savienojumu ar pakalpojumu. Šķiet, ka autori ir diezgan pārliecināti par sava DNS kvalitāti (tomēr no Cloudflare ir grūti sagaidīt kaut ko citu):

Mēs satiekam pakalpojumu no Cloudflare adresēs 1.1.1.1 un 1.0.0.1 jeb “publiskais DNS plaukts ir pienācis!”

Pilnībā var saprast pakalpojuma veidotāju Cloudflare: viņi pelna maizi, uzturot un attīstot vienu no pasaulē populārākajiem CDN tīkliem (kura funkcijas ietver ne tikai satura izplatīšanu, bet arī DNS zonu mitināšanu), un, pateicoties to vēlme, kurš nav labi pārzināts, māciet tos kurus viņi nepazīst, uz to kur doties globālajā tīklā diezgan bieži cieš no savu serveru adrešu bloķēšanas no neteiksim kurš - tātad, ja uzņēmumam ir DNS, kuru neietekmē "kliedzieni, svilpes un skricelējumi", tas nozīmē mazāku kaitējumu viņu biznesam. Un tehniskās priekšrocības (sīkums, bet jauki: jo īpaši bezmaksas DNS Cloudflare klientiem uzņēmuma DNS serveros mitināto resursu DNS ierakstu atjaunināšana būs tūlītēja) padara ierakstā aprakstītā pakalpojuma izmantošanu vēl interesantāku.

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Vai izmantosiet jauno pakalpojumu?

  • Jā, vienkārši norādot to OS un/vai maršrutētājā

  • Jā, un es izmantošu jaunus protokolus (DNS, izmantojot HTTPs, un DNS, izmantojot TLS)

  • Nē, man ir pietiekami daudz pašreizējo serveru (tas ir publisks pakalpojumu sniedzējs: Google, Yandex utt.)

  • Nē, es pat nezinu, ko šobrīd lietoju

  • Es izmantoju savu rekursīvo DNS ar SSL tuneli tiem

Nobalsoja 693 lietotāji. 191 lietotājs atturējās.

Avots: www.habr.com

Pievieno komentāru