Cloudflare præsenterede public DNS på adresserne:
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
Det hævdes, at der anvendes en "Privacy first" politik, så brugerne kan være trygge ved indholdet af deres forespørgsler.
Tjenesten er interessant, fordi den udover almindelig DNS tilbyder mulighed for at bruge teknologier DNS-over-TLS og DNS-over-HTTPS, hvilket vil gøre det vanskeligt for udbydere at overvåge dine forespørgsler undervejs — og indsamle statistik, overvåge, administrere reklamer. Cloudflare hævder, at datoen for annoncering (1. april 2018, eller 04/01 i amerikansk notation) ikke er tilfældigt valgt: hvornår ellers på året præsentere "fire enheder"?
Da publikum på Habr er teknisk kyndigt, placerer jeg den traditionelle sektion "hvorfor bruge DNS?" til slut i indlægget, og her præsenterer jeg mere praktisk nyttige ting:
Hvordan bruger man den nye tjeneste?
Det simpleste er at angive de ovenstående adresser i din DNS-klient (eller som upstream i indstillingerne for din lokale DNS-server).DNS-servere. Giver det mening at erstatte de vante værdier Google DNS (8.8.8.8 osv.), eller de lidt mindre udbredte Yandex offentlige DNS-servere (77.88.8.8 og lignende) med servere fra Cloudflare — det vil I selv afgøre, men for nybegyndere taler grafikken for svartider, ifølge hvilken Cloudflare arbejder hurtigere end alle konkurrenterne (jeg præciserer: målingerne er foretaget af en tredjepart, og hastigheden til den specifikke klient kan naturligvis variere).
Meget mere interessant er arbejdet med de nye tilstande, hvor forespørgslen sendes via server en krypteret forbindelse (egentlig returneres svaret over den samme), nævnt DNS-over-TLS og DNS-over-HTTPS. Desværre understøttes de "out of the box" ikke (forfatterne mener, det er "indtil videre"), men det er ikke svært at arrangere deres funktionalitet i din software (eller endda på dit eget udstyr):
DNS over HTTPS (DoH)
Som navnet antyder, foregår kommunikationen over HTTPS-kanalen, hvilket forudsætter
- tilstedeværelsen af et endpoint — det er placeret på adressen https://cloudflare-dns.com/dns-query, og
- en klient, der kan sende forespørgsler og modtage svar.
Forespørgsler kan enten være i DNS Wireformat, som defineret i RFC1035 (afsendes med HTTP-metoderne POST og GET), eller i JSON-format (bruger HTTP-metoden GET). Personligt syntes jeg, at ideen om at udføre DNS-anmodninger via HTTP-anmodninger var overraskende, men der er en rationel kerne i det: en sådan anmodning vil passere mange trafikfiltreringssystemer, at analysere svarene er forholdsvis enkelt, og at danne anmodninger er endnu lettere. De velkendte biblioteker og protokoller tager sig af sikkerheden.
Eksempler på anmodninger, direkte fra dokumentationen:
GET-anmodning i DNS Wireformat
$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Bruger HTTP2, serveren understøtter flerbrug
* Forbindelsens tilstand ændret (HTTP/2 bekræftet)
* Kopierer HTTP/2-data i strømbufferen til forbindelsesbufferen efter opgradering: len=0
* Bruger Stream ID: 1 (nem håndtag 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*
* Forbindelsens tilstand ændret (MAX_CONCURRENT_STREAMS opdateret)!
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
* Forbindelse #0 til host cloudflare-dns.com forblev intakt
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-anmodning 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
* Forbindelse #0 til host cloudflare-dns.com forblev intakt
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 med brug af 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 tydeligt, at der sjældent findes (hvis overhovedet nogen) hjemme-routere, der kan arbejde på denne måde med DNS, men det betyder ikke, at supporten ikke kan komme i morgen — og hvad der er interessant, er, at vi i vores applikation godt kan implementere DNS-funktionalitet (som allerede Mozilla planlægger at gøre, netop på Cloudflare-serverne).
DNS over TLS
Som standard sendes DNS-anmodninger uden kryptering. DNS over TLS er en metode til at sende dem over en sikker forbindelse. Cloudflare understøtter DNS over TLS på standardport 853, som angivet. RFC7858. Et certifikat udstedt til værten cloudflare-dns.com anvendes, og TLS 1.2 og TLS 1.3 understøttes.
Oprettelse af forbindelse og drift efter protokollen foregår cirka sådan her:
- Før forbindelsen til DNS opbevarer klienten den base64-kodede SHA256-hash af TLS-certifikatet for cloudflare-dns.com (kendt som SPKI).
- DNS-klienten opretter en TCP-forbindelse til cloudflare-dns.com:853
- DNS-klienten initierer TLS handshake-processen.
- Under TLS handshake præsenterer værten cloudflare-dns.com sit TLS-certifikat.
- Når TLS-forbindelsen er oprettet, kan DNS-klienten sende DNS-anmodninger over den sikre kanal, hvilket forhindrer aflytning og forfalskning af anmodninger og svar.
- Alle DNS-anmodninger, der sendes gennem TLS-forbindelsen, skal overholde specifikationen for sending af DNS over TCP.
Eksempel på anmodning via DNS over TLS:
$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Forespørger ejer(example.com.), klasse(1), type(1), server(1.1.1.1), port(853), protokol(TCP)
;; DEBUG: TLS, importerede 170 systemcertifikater
;; DEBUG: TLS, modtagne certifikat hierarki:
;; 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, springer over certifikats PIN-kontrol
;; DEBUG: TLS, certifikatet er betroet.
;; 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 størrelse: 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
;; Modtaget 468 B
;; Tid 2018-03-31 15:20:57 PDT
;; Fra 1.1.1.1@853(TCP) på 12.6 ms
Dette valg synes bedre egnet til lokale DNS-servere, der betjener behovene for et lokalt netværk eller en enkelt bruger. Sandt nok, understøttelsen af standarden er ikke så god, men lad os håbe!
To ord af forklaring, hvad samtalen handler om
Forkortelsen DNS står for Domæne Name Service (så det ville være overflødigt at sige 'DNS-service', da der allerede er ordet 'service' i forkortelsen), og den bruges til at løse en simpel opgave – at finde ud af, hvilken IP-adresse der hører til et givet vært navn. Hver gang en person klikker på et link, eller indtaster en adresse i browserens adresselinje (lad os sige noget som 'https://habrahabr.ru/post/346430/Når en bruger computer forsøger at forstå, hvilken server der skal sendes en anmodning til for at modtage indholdet af en side. I tilfælde af habrahabr.ru vil svaret fra DNS indeholde en henvisning til webserverens IP-adresse: 178.248.237.68, og derefter vil browseren forsøge at oprette forbindelse til serveren med den angivne IP-adresse.
DNS-serveren, der modtager forespørgslen «hvilken IP-adresse har værten med navnet habrahabr.ru?», fastslår, om den ved noget om den angivne vært. Hvis ikke, anmoder den andre DNS-servere i verden, og trin for trin forsøger den at finde svaret på det stillede spørgsmål. Til sidst, når den endelige svar er fundet, sendes de fundne data til den stadig ventende klient og gemmes i cache på selve DNS-serveren, hvilket gør det muligt at besvare et lignende spørgsmål meget hurtigere næste gang.
Et almindeligt problem er, at for det første, DNS-forespørgsler sendes i klar tekst (hvilket giver alle, der har adgang til trafikstrømmen, mulighed for at udtrække DNS-forespørgslerne og de modtagne svar og derefter analysere dem til deres egne formål; dette giver mulighed for målrettet reklame med præcision for DNS-klienten, og det er ikke en lille ting!). For det andet har nogle internetudbydere (vi peger ikke fingre, men de er ikke de mindste) en tendens til at vise reklamer i stedet for den forespurgte side (hvilket er meget let at implementere: i stedet for den angivne IP-adresse for anmodningen om værtsnavn habranabr.ru, returneres en vilkårlig adresse for udbyderens webserver, hvor der vises en side, der indeholder reklame). For det tredje findes der internetadgangsudbydere, som implementerer metoder til at imødekomme anmodninger om blokering af bestemte websteder ved at ændre de rigtige DNS-svar for IP-adresserne til de blokerede webressourcer til IP-adressen på deres egen server, som indeholder sideskabeloner (som gør adgangen til sådanne websteder betydeligt mere besværlig), eller til adressen for deres egen proxyserver, som udfører filtrering.
Her burde man sandsynligvis indsætte et billede fra hjemmesiden http://1.1.1.1/, der beskriver forbindelsen til tjenesten. Forfatterne synes, som det fremgår, at de er fuldstændig overbeviste om kvaliteten af deres DNS (formentlig er det svært at forvente andet fra Cloudflare):
Man kan sagtens forstå virksomheden Cloudflare, skaberen af tjenesten: de tjener deres penge ved at vedligeholde og udvikle et af de mest populære CDN-netværk i verden (blandt funktionerne er ikke kun distribution af indhold, men også hosting af DNS-zoner), og fordi de ønsker at undervise dem, der ikke helt forstår,, om dem, de ikke kender,, i hvad, de skal besøge på det globale netværk, lider ofte under blokeringer af deres serveradresser fra lad os ikke nævne hvem, — så at have en DNS, der ikke påvirkes af «skrig, fløjt og papirklip», betyder for virksomheden mindre skade på deres forretning. De tekniske fordele (det er småting, men rart: især for kunder af Cloudflares gratis DNS vil opdateringen af DNS-poster for ressourcer, der er placeret på virksomhedens DNS-servere, være øjeblikkelig) gør brugen af den beskrevne tjeneste endnu mere interessant.
Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.
Vil du bruge den nye tjeneste?
- Ja, bare ved at angive den i OS og/eller på routeren.
- Ja, og jeg vil bruge de nye protokoller (DNS over HTTPs og DNS over TLS).
- Nej, jeg har nok med de nuværende servere (dette er en offentlig udbyder: Google, Yandex osv.).
- Nej, jeg ved ikke engang, hvad jeg bruger lige nu.
- Jeg bruger mine rekursive DNS med SSL tunnel til dem.
693 brugere stemte. 191 brugere afholdt sig.
Kilde: habr.com
