Vi møder tjenesten fra Cloudflare på adresserne 1.1.1.1 og 1.0.0.1, eller "den offentlige DNS-hylde er ankommet!"

Cloudflare Company fremlagde offentlig DNS på adresser:

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

Politikken siges at være "privatliv først", så brugerne kan have ro i sindet om indholdet af deres anmodninger.

Tjenesten er interessant ved, at den udover den sædvanlige DNS giver mulighed for at bruge teknologier DNS-over-TLS и DNS-over-HTTPS, hvilket i høj grad vil forhindre udbydere i at aflytte dine anmodninger langs forespørgslernes vej - og indsamle statistik, overvåge, administrere annoncering. Cloudflare hævder, at datoen for annonceringen (1. april 2018 eller 04/01 i amerikansk notation) ikke blev valgt tilfældigt: hvilken anden dag på året vil de "fire enheder" blive præsenteret?

Da Habrs publikum er teknisk kyndige, er den traditionelle sektion "hvorfor har du brug for DNS?" Jeg vil sætte det i slutningen af ​​indlægget, men her vil jeg angive mere praktisk nyttige ting:

Hvordan bruger man den nye service?

Det enkleste er at angive ovenstående DNS-serveradresser i din DNS-klient (eller som upstream i indstillingerne for den lokale DNS-server, du bruger). Giver det mening at erstatte de sædvanlige værdier Google DNS (8.8.8.8 osv.), eller lidt mindre almindelig Yandex offentlige DNS-servere (77.88.8.8 og andre som dem) til serverne fra Cloudflare - de bestemmer for dig, men taler for en nybegynder planlægge svarhastighed, ifølge hvilken Cloudflare er hurtigere end alle konkurrenter (jeg vil præcisere: målingerne blev taget af en tredjepartstjeneste, og hastigheden til en specifik klient kan selvfølgelig variere).

Det er meget mere interessant at arbejde med nye tilstande, hvor anmodningen flyver til serveren over en krypteret forbindelse (faktisk returneres svaret gennem den), de nævnte DNS-over-TLS og DNS-over-HTTPS. Desværre understøttes de ikke "ud af boksen" (forfatterne mener, at dette er "endnu"), men det er ikke svært at organisere deres arbejde i din software (eller endda på din hardware):

DNS over HTTPs (DoH)

Som navnet antyder, foregår kommunikationen over en HTTPS-kanal, hvilket betyder

1. tilstedeværelsen af ​​et landingspunkt (endepunkt) - det er placeret på adressen https://cloudflare-dns.com/dns-queryOg
2. en klient, der kan sende anmodninger og modtage svar.

Anmodninger kan enten være i DNS Wireformat-formatet defineret i RFC1035 (sendes ved hjælp af POST- og GET HTTP-metoderne), eller i JSON-format (ved hjælp af GET HTTP-metoden). For mig personligt virkede ideen om at lave DNS-anmodninger via HTTP-anmodninger uventet, men der er et rationelt korn i det: en sådan anmodning vil passere mange trafikfiltreringssystemer, parsing af svar er ret simpelt, og generering af anmodninger er endnu nemmere. De sædvanlige biblioteker og protokoller er ansvarlige for sikkerheden.

Anmod om eksempler direkte fra dokumentationen:

GET anmodning 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-anmodning i DNS Wireformat-format

$ 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

Samme men bruger 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 en sjælden (hvis mindst én) hjemmerouter kan arbejde med DNS på denne måde, men det betyder ikke, at support ikke vises i morgen - og interessant nok kan vi her ganske implementere arbejde med DNS i vores applikation (som allerede skal lave Mozilla, kun på Cloudflare-servere).

DNS over TLS

Som standard transmitteres DNS-forespørgsler uden kryptering. DNS over TLS er en måde at sende dem over en sikker forbindelse. Cloudflare understøtter DNS over TLS på standardport 853 som foreskrevet RFC7858. Dette bruger et certifikat udstedt til cloudflare-dns.com værten, TLS 1.2 og TLS 1.3 understøttes.

Etablering af en forbindelse og arbejde i henhold til protokollen foregår sådan her:

• Før der etableres en DNS-forbindelse, gemmer klienten en base64-kodet SHA256-hash af cloudflare-dns.com's TLS-certifikat (kaldet SPKI)
• DNS-klient etablerer en TCP-forbindelse til cloudflare-dns.com:853
• DNS-klient starter TLS-håndtryk
• Under TLS-håndtrykprocessen præsenterer cloudflare-dns.com-værten sit TLS-certifikat.
• Når en TLS-forbindelse er etableret, kan DNS-klienten sende DNS-anmodninger over en sikker kanal, som forhindrer anmodninger og svar i at blive afluret og spoofet.
• Alle DNS-forespørgsler sendt over en TLS-forbindelse skal overholde sende DNS over TCP.

Et eksempel på en anmodning 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

Denne mulighed ser ud til at fungere bedst for lokale DNS-servere, der tjener et lokalt netværks eller en enkelt brugers behov. Sandt nok, med støtte fra standarden er ikke særlig god, men - lad os håbe!

To ord til forklaring på, hvad samtalen handler om

Forkortelsen DNS står for Domain Name Service (så at sige "DNS service" er noget overflødigt, forkortelsen indeholder allerede ordet "service") og bruges til at løse en simpel opgave - at forstå, hvilken IP-adresse et bestemt værtsnavn har. Hver gang en person klikker på et link eller indtaster en adresse i browserens adresselinje (f.eks. noget som "https://habrahabr.ru/post/346430/"), forsøger den menneskelige computer at finde ud af, hvilken server der skal sende en anmodning om at få sidens indhold. I tilfælde af habrahabr.ru vil svaret fra DNS indeholde en indikation af webserverens IP-adresse: 178.248.237.68, og så vil browseren allerede forsøge at kontakte serveren med den angivne IP-adresse.

Til gengæld bestemmer DNS-serveren, efter at have modtaget anmodningen "hvad er IP-adressen på værten ved navn habrahabr.ru?", om den ved noget om den angivne vært. Hvis ikke, sender den en anmodning til andre DNS-servere i verden og forsøger trin for trin at finde ud af svaret på det stillede spørgsmål. Som et resultat, når du har fundet det endelige svar, sendes de fundne data til klienten, der stadig venter på dem, plus de gemmes i cachen på selve DNS-serveren, hvilket giver dig mulighed for at besvare et lignende spørgsmål meget hurtigere næste gang.

Et almindeligt problem er, at DNS-forespørgselsdata for det første transmitteres i det klare (hvilket giver alle med adgang til trafikstrømmen mulighed for at isolere DNS-forespørgslerne og de svar, de modtager, og derefter analysere dem til deres egne formål; dette giver muligheden for at målrette annoncer med nøjagtighed for en DNS-klient, hvilket er ret meget!). For det andet har nogle internetudbydere (vi peger ikke fingre, men ikke de mindste) tendens til at vise annoncer i stedet for en eller anden anmodet side (som er implementeret ganske enkelt: i stedet for den angivne IP-adresse for en forespørgsel fra habranabr.ru værtsnavn, en tilfældig person. Således returneres adressen på udbyderens webserver, hvor siden med annoncen vises). For det tredje er der internetadgangsudbydere, der implementerer en mekanisme til at opfylde kravene til blokering af individuelle websteder ved at erstatte de korrekte DNS-svar om IP-adresserne på blokerede webressourcer med IP-adressen på deres server, der indeholder stubsider (som følge heraf adgang til sådanne websteder mærkbart mere komplicerede), eller til adressen på din proxyserver, der udfører filtrering.

Dette skal nok være et billede fra siden. http://1.1.1.1/, bruges til at beskrive forbindelsen til tjenesten. Forfatterne ser ud til at være ret sikre på kvaliteten af ​​deres DNS (det er dog svært at forvente andet fra Cloudflare):

Man kan fuldt ud forstå Cloudflare, skaberen af ​​tjenesten: de tjener deres brød ved at vedligeholde og udvikle et af de mest populære CDN-netværk i verden (hvilket funktioner omfatter ikke kun distribution af indhold, men også hosting af DNS-zoner), og pga. disses ønske, som ikke er velbevandret, undervis dem som de ikke kender, til den hvor skal vi hen i det globale netværk, lider ret ofte af at blokere adresserne på deres servere fra lad os ikke sige hvem - så det at have en DNS, der ikke er påvirket af "råb, fløjt og skriblerier" for virksomheden, betyder mindre skade for deres forretning. Og tekniske fordele (en bagatel, men rart: især for klienter med den gratis DNS Cloudflare vil opdatering af DNS-registreringer af ressourcer, der er hostet på virksomhedens DNS-servere, være øjeblikkelig) gør brugen af ​​tjenesten beskrevet i indlægget endnu mere interessant.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Vil du bruge den nye tjeneste?

• Ja, ved blot at angive det i OS og/eller på routeren

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

• Nej, jeg har nok nuværende servere (dette er en offentlig udbyder: Google, Yandex osv.)

• Nej, jeg ved ikke engang, hvad jeg bruger lige nu

• Jeg bruger min rekursive DNS med en SSL-tunnel til dem

693 brugere stemte. 191 bruger undlod at stemme.

Kilde: www.habr.com