Vi møter tjenesten fra Cloudflare på adressene 1.1.1.1 og 1.0.0.1, eller "den offentlige DNS-hyllen har ankommet!"

Vi møter tjenesten fra Cloudflare på adressene 1.1.1.1 og 1.0.0.1, eller "den offentlige DNS-hyllen har ankommet!"

Cloudflare Company presentert offentlig DNS på adresser:

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

Det hevdes at en "Personvern først"-policy brukes, slik at brukere kan være trygge på innholdet i forespørslene deres.

Tjenesten er interessant fordi den, i tillegg til vanlig DNS, gir muligheten til å bruke teknologier DNS-over-TLS и DNS-over-HTTPS, som i stor grad vil hindre leverandører i å avlytte forespørslene dine langs forespørselsbanen - og samle inn statistikk, overvåke og administrere annonsering. Cloudflare hevder at kunngjøringsdatoen (1. april 2018 eller 04/01 i amerikansk notasjon) ikke ble valgt ved en tilfeldighet: hvilken annen dag i året ville "fire enheter" bli presentert?

Siden Habrs publikum er teknisk kunnskapsrike, er den tradisjonelle delen "hvorfor trenger vi DNS?" Jeg legger det på slutten av innlegget, og her vil jeg skissere mer praktisk nyttige ting:

Hvordan bruke den nye tjenesten?

Det enkleste er å spesifisere DNS-serveradressene ovenfor i DNS-klienten din (eller som en oppstrøms i innstillingene til den lokale DNS-serveren du bruker). Er det fornuftig å erstatte de vanlige verdiene? Google DNS (8.8.8.8 osv.), eller litt mindre vanlig Yandex offentlige DNS-servere (77.88.8.8 og andre som dem) til servere fra Cloudflare - de bestemmer for deg, men det taler for en nybegynner planlegge svarhastighet, ifølge hvilken Cloudflare fungerer raskere enn alle konkurrenter (la meg presisere: målingene ble gjort av en tredjepartstjeneste, og hastigheten til en spesifikk klient kan selvfølgelig variere).

Vi møter tjenesten fra Cloudflare på adressene 1.1.1.1 og 1.0.0.1, eller "den offentlige DNS-hyllen har ankommet!"

Det er mye mer interessant å jobbe med nye moduser der forespørselen flyr til serveren via en kryptert tilkobling (faktisk returneres svaret via den), nevnte DNS-over-TLS og DNS-over-HTTPS. Dessverre støttes de ikke ut av boksen (forfatterne mener at dette er "ennå"), men det er ikke vanskelig å organisere arbeidet i programvaren din (eller til og med på maskinvaren):

DNS over HTTPs (DoH)

Som navnet antyder, skjer kommunikasjon over en HTTPS-kanal, noe som innebærer

  1. tilstedeværelse av et landingspunkt (endepunkt) - det ligger ved https://cloudflare-dns.com/dns-queryOg
  2. en klient som kan sende forespørsler og motta svar.

Forespørsler kan enten være i DNS Wireformat definert i RFC1035 (sendes ved hjelp av POST- og GET HTTP-metodene), eller i JSON-format (ved hjelp av GET HTTP-metoden). For meg personlig virket ideen om å lage DNS-forespørsler via HTTP-forespørsler uventet, men det er et rasjonelt korn i det: en slik forespørsel vil passere mange trafikkfiltreringssystemer, parsing av svar er ganske enkelt, og generering av forespørsler er enda enklere. Kjente biblioteker og protokoller er ansvarlige for sikkerheten.

Eksempelspørsmål, rett fra dokumentasjonen:

GET forespørsel i DNS Wireformat-format

$ 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-forespørsel i 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
* 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

Det samme, men bruker 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"
    }
  ]
}

Det er klart at få (om noen) hjemmerutere kan jobbe med DNS som dette, men dette betyr ikke at støtten ikke vises i morgen - og interessant nok, her kan vi enkelt implementere arbeid med DNS i applikasjonen vår (som allerede skal lage Mozilla, bare på Cloudflare-servere).

DNS over TLS

Som standard sendes DNS-spørringer uten kryptering. DNS over TLS er en måte å sende dem over en sikker tilkobling. Cloudflare støtter DNS over TLS på standard port 853 som foreskrevet RFC7858. Dette bruker et sertifikat utstedt for verten cloudflare-dns.com, TLS 1.2 og TLS 1.3 støttes.

Å etablere en forbindelse og jobbe med protokollen går omtrent slik:

  • Før du oppretter en tilkobling til DNS, lagrer klienten en base64-kodet SHA256-hash av cloudflare-dns.coms TLS-sertifikat (kalt SPKI)
  • DNS-klienten etablerer en TCP-forbindelse til cloudflare-dns.com:853
  • DNS-klienten starter TLS-håndtrykkprosedyren
  • Under TLS-håndtrykket presenterer cloudflare-dns.com-verten sitt TLS-sertifikat.
  • Når TLS-tilkoblingen er etablert, kan DNS-klienten sende DNS-spørringer over en sikker kanal, som forhindrer avlytting og forfalskning av forespørsler og svar.
  • Alle DNS-forespørsler som sendes over en TLS-tilkobling må være i samsvar med spesifikasjonen iht sende DNS over TCP.

Eksempel på en forespørsel via DNS over 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

Dette alternativet ser ut til å være bedre egnet for lokale DNS-servere som betjener behovene til et lokalt nettverk eller en enkelt bruker. Riktignok er ikke støtten for standarden veldig god, men la oss håpe!

To ord til forklaring på hva vi snakker om

Forkortelsen DNS står for Domain Name Service (så å si "DNS-tjeneste" er noe overflødig; akronymet inneholder allerede ordet "tjeneste"), og brukes til å løse en enkel oppgave - å forstå hvilken IP-adresse et spesifikt vertsnavn har. Hver gang en person klikker på en lenke, eller skriver inn en adresse i nettleserens adresselinje (si noe sånt som "https://habrahabr.ru/post/346430/"), prøver en persons datamaskin å finne ut hvilken server som skal sende en forespørsel om å motta innholdet på en side. Når det gjelder habrahabr.ru, vil svaret fra DNS inneholde en indikasjon på IP-adressen til webserveren: 178.248.237.68, og deretter vil nettleseren prøve å kontakte serveren med den angitte IP-adressen.

På sin side bestemmer DNS-serveren, etter å ha mottatt forespørselen "hva er IP-adressen til verten som heter habrahabr.ru?", om den vet noe om den angitte verten. Hvis ikke, sender den en spørring til andre DNS-servere i verden, og prøver trinn for trinn å finne ut svaret på spørsmålet. Som et resultat, når du finner det endelige svaret, blir de funnet dataene sendt til den fortsatt ventende klienten, pluss at de lagres i bufferen til selve DNS-serveren, noe som lar deg svare på et lignende spørsmål mye raskere neste gang.

Et vanlig problem er at for det første sendes DNS-spørringsdataene i klartekst (som lar alle med tilgang til trafikkstrømmen isolere DNS-spørringene og de resulterende svarene, og deretter analysere dem for sine egne formål; dette tillater muligheten å målrette annonsering med presisjon for DNS-klienten, og dette er ganske mye!). For det andre, noen Internett-leverandører (vi vil ikke peke fingre, men ikke de minste) har en tendens til å vise reklame i stedet for en eller annen forespurt side (som er implementert veldig enkelt: i stedet for den spesifiserte IP-adressen for en forespørsel om vertsnavnet habranabr.ru til en tilfeldig person På denne måten returneres adressen til leverandørens nettserver, der siden som inneholder annonsen vises). For det tredje er det Internett-tilgangsleverandører som implementerer en mekanisme for å oppfylle kravene for blokkering av individuelle nettsteder ved å erstatte de riktige DNS-svarene om IP-adressene til blokkerte nettressurser med IP-adressen til serveren deres som inneholder stubbsider (som et resultat av tilgang til slike nettsteder blir merkbart mer kompliserte), eller til adressen til proxy-serveren din som utfører filtrering.

Du bør nok legge inn et bilde fra nettsiden her http://1.1.1.1/, som tjener til å beskrive forbindelsen til tjenesten. Forfatterne er tilsynelatende helt sikre på kvaliteten på deres DNS (det er imidlertid vanskelig å forvente noe annerledes fra Cloudflare):

Vi møter tjenesten fra Cloudflare på adressene 1.1.1.1 og 1.0.0.1, eller "den offentlige DNS-hyllen har ankommet!"

Man kan helt forstå Cloudflare, skaperen av tjenesten: de tjener sitt brød ved å støtte og utvikle et av de mest populære CDN-nettverkene i verden (hvis funksjonene inkluderer ikke bare innholdsdistribusjon, men også hosting av DNS-soner), og, på grunn av disses ønske, som ikke vet mye, lære dem som de ikke kjenner, til det hvor du skal dra på det globale nettverket, lider ganske ofte av blokkering av serveradressene av vi vil ikke si hvem - så å ha en DNS som ikke er påvirket av "rop, fløyter og skriblerier" betyr mindre skade på virksomheten deres for et selskap. Og de tekniske fordelene (en liten ting, men hyggelig: spesielt for klienter av gratis DNS Cloudflare, vil oppdatering av DNS-postene for ressurser som er vert på selskapets DNS-servere være øyeblikkelig) gjør bruken av tjenesten beskrevet i innlegget enda mer interessant .

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Kommer du til å bruke den nye tjenesten?

  • Ja, bare ved å spesifisere det i OS og/eller på ruteren

  • Ja, og jeg vil bruke nye protokoller (DNS over HTTPs og DNS over TLS)

  • Nei, jeg har nok nåværende servere (dette er en offentlig leverandør: Google, Yandex, etc.)

  • Nei, jeg vet ikke engang hva jeg bruker akkurat nå

  • Jeg bruker min egen rekursive DNS med en SSL-tunnel foran dem

693 brukere stemte. 191 bruker avsto.

Kilde: www.habr.com

Legg til en kommentar