L'azienda Cloudflare ha presentato DNS pubblici agli indirizzi:
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
Si afferma che viene utilizzata la politica «Privacy first», quindi gli utenti possono stare tranquilli riguardo al contenuto delle loro richieste.
Il servizio è interessante poiché oltre a fornire DNS standard offre la possibilità di utilizzare tecnologie DNS-over-TLS e DNS-over-HTTPS, il che rende difficile ai fornitori di monitorare le vostre richieste lungo il percorso — ed è possibile raccogliere statistiche, controllare la pubblicità. Cloudflare afferma che la data di annuncio (1 aprile 2018, o 04/01 nella notazione americana) è stata scelta non a caso: in quale altro giorno dell'anno presentare «quattro unità»?
Poiché il pubblico di Habr è tecnicamente esperto, posizionerò la sezione tradizionale «perché è necessario il DNS?» alla fine del post, mentre qui presenterò cose più pratiche:
Come utilizzare il nuovo servizio?
La cosa più semplice è indicare nei propri DNS-client (o come upstream nelle impostazioni del server DNS locale che utilizzate) gli indirizzi DNS sopra menzionatiserver. Ha senso sostituire i valori noti DNS di Google (8.8.8.8 ecc.), oppure quelli meno diffusi server DNS pubblici di Yandex (77.88.8.8 e simili) con i server di Cloudflare — dovrete decidere, ma a favore del principiante parla grafico delle velocità di risposta, secondo il quale Cloudflare è più veloce di tutti i concorrenti (preciso: le misurazioni sono state effettuate da un servizio terzo e la velocità per un cliente specifico, ovviamente, può variare).
È molto più interessante lavorare con le nuove modalità, in cui la richiesta viene inviata su server una connessione crittografata (in effetti, la risposta viene restituita sulla stessa connessione), menzionate DNS-over-TLS e DNS-over-HTTPS. Sfortunatamente, «di default» non sono supportate (gli autori credono che sia «per ora»), ma organizzare il loro funzionamento nel proprio software (o anche sul proprio hardware) non è difficile:
DNS over HTTPs (DoH)
Come suggerisce il nome, la comunicazione avviene sopra il canale HTTPS, il che implica
- la presenza di un punto finale (endpoint) — si trova all'indirizzo https://cloudflare-dns.com/dns-query, e
- un client che sa inviare richieste e ricevere risposte.
Le richieste possono essere nel formato DNS Wireformat, definito in RFC1035 (inviare tramite i metodi HTTP POST e GET), oppure in formato JSON (utilizzando il metodo HTTP GET). Personalmente, l'idea di effettuare richieste DNS tramite richieste HTTP mi è sembrata inaspettata, ma ha un fondo razionale: tale richiesta passerà attraverso molti sistemi di filtraggio del traffico, analizzare le risposte è abbastanza semplice e formare le richieste è ancora più facile. Le librerie e i protocolli abituali si occupano della sicurezza.
Esempi di richieste, tratti dalla documentazione:
Richiesta GET in formato DNS Wireformat
$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Utilizzando HTTP2, il server supporta l'uso multiplo
* Stato della connessione cambiato (HTTP/2 confermato)
* Copiando i dati HTTP/2 nel buffer della connessione dopo l'upgrade: len=0
* Utilizzando ID Stream: 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: */*
* Stato della connessione cambiato (MAX_CONCURRENT_STREAMS aggiornato)!
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
* La connessione #0 con l'host cloudflare-dns.com è rimasta intatta
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
Richiesta POST in formato 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
* La connessione #0 con l'host cloudflare-dns.com è rimasta intatta
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
Lo stesso, ma utilizzando 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"
}
]
}
È evidente che pochi (se non addirittura nessun) router domestici siano in grado di lavorare in questo modo con DNS, ma ciò non significa che il supporto non possa apparire domani — e ciò che è interessante è che qui possiamo realizzare la gestione di DNS nella nostra applicazione (come già sta per fare Mozilla, proprio sui server Cloudflare).
DNS over TLS
Per impostazione predefinita, le richieste DNS vengono inviate senza crittografia. DNS over TLS è un modo per inviarle tramite una connessione sicura. Cloudflare supporta DNS over TLS sulla porta standard 853, come stabilito da RFC7858. In questo modo viene utilizzato un certificato emesso per l'host cloudflare-dns.com, supportando TLS 1.2 e TLS 1.3.
La connessione e il funzionamento tramite protocollo avvengono più o meno in questo modo:
- Prima di stabilire la connessione, il client DNS memorizza l'hash SHA256 del certificato TLS di cloudflare-dns.com codificato in base64 (chiamato SPKI)
- Il client DNS stabilisce una connessione TCP con cloudflare-dns.com:853
- Il client DNS avvia la procedura di handshake TLS
- Durante il processo di handshake TLS, l'host cloudflare-dns.com presenta il proprio certificato TLS.
- Una volta che la connessione TLS è stabilita, il client DNS può inviare richieste DNS attraverso un canale protetto, il che impedisce l'intercettazione e la falsificazione delle richieste e delle risposte.
- Tutte le richieste DNS inviate attraverso la connessione TLS devono conformarsi alla specifica per l'invio di DNS sopra TCP.
Esempio di richiesta tramite DNS over TLS:
$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Interrogazione per owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, importati 170 certificati di sistema
;; DEBUG: TLS, ricevuta gerarchia dei certificati:
;; 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, controllo del PIN del certificato saltato
;; DEBUG: TLS, il certificato è fidato.
;; Sessione TLS (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
;; SEZIONE PSEUDO EDNS:
;; Versione: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B
;; SEZIONE DOMANDA:
;; example.com. IN A
;; SEZIONE RISPOSTA:
example.com. 2347 IN A 93.184.216.34
;; Ricevuti 468 B
;; Tempo 2018-03-31 15:20:57 PDT
;; Da 1.1.1.1@853(TCP) in 12.6 ms
Questa opzione sembra più adatta per i server DNS locali che soddisfano le esigenze di una rete locale o di un singolo utente. Tuttavia, il supporto per lo standard non è molto buono, ma speriamo bene!
Due parole di spiegazione su cosa stiamo parlando
L'acronimo DNS sta per Dominio Name Service (quindi dire "servizio DNS" è un po' ridondante, poiché l'acronimo contiene già la parola "servizio"), e viene utilizzato per risolvere un compito semplice: capire quale indirizzo IP corrisponde a un determinato nome host. Ogni volta che qualcuno clicca su un link o digita nella barra degli indirizzi del browser un indirizzo (per esempio, qualcosa come "https://habrahabr.ru/post/346430/Il computer dell'utente tenta di capire a quale server inviare la richiesta per ottenere il contenuto della pagina. Nel caso di habrahabr.ru, la risposta del DNS conterrà un'indicazione sull'indirizzo IP del server web: 178.248.237.68, e poi il browser cercherà di contattare il server con l'indirizzo IP indicato.
A sua volta, il server DNS, ricevuta la richiesta "qual è l'indirizzo IP dell'host con il nome habrahabr.ru?", determina se sa qualcosa riguardo l'host specificato. Se non lo sa, invia una richiesta ad altri server DNS nel mondo e, passo dopo passo, prova a trovare la risposta alla domanda posta. Alla fine, una volta trovata la risposta finale, i dati trovati vengono inviati al cliente che ancora li attende, inoltre vengono memorizzati nella cache del server DNS stesso, il che permetterà di rispondere a domande simili molto più rapidamente in futuro.
Un problema comune è che, innanzitutto, i dati delle richieste DNS vengono trasmessi in chiaro (il che consente a chiunque abbia accesso al flusso di traffico di estrarre le richieste DNS e le risposte ricevute, per poi analizzarle per i propri scopi; questo consente di effettuare pubblicità mirata con precisione sul cliente DNS, e questo non è poco!). In secondo luogo, alcuni provider di servizi Internet (non facciamo nomi, ma non sono i più piccoli) tendono a mostrare pubblicità invece di una determinata pagina richiesta (ciò avviene in modo molto semplice: anziché restituire l'indirizzo IP specificato per la richiesta del nome host habranabr.ru, alla persona viene restituito casualmente l'indirizzo del server web del provider, dove viene fornita una pagina contenente pubblicità). In terzo luogo, ci sono provider di accesso a Internet che attuano misure di blocco di determinati siti, sostituendo le risposte DNS corrette riguardanti gli indirizzi IP delle risorse web bloccate con l'indirizzo IP del proprio server, che contiene pagine di annuncio (il che rende notevolmente più difficile l'accesso a tali siti), oppure con l'indirizzo del proprio server proxy che effettua la filtrazione.
Qui, probabilmente, è necessario inserire un'immagine del sito http://1.1.1.1/, utilizzata per descrivere la connessione al servizio. Gli autori, come si può vedere, sono completamente sicuri della qualità del loro DNS (d'altra parte, da Cloudflare è difficile aspettarsi altro):
È comprensibile capire la compagnia Cloudflare, creatrice del servizio: guadagnano il loro pane supportando e sviluppando una delle reti CDN più popolari al mondo (tra le cui funzioni vi è non solo la distribuzione dei contenuti, ma anche l'hosting delle zone DNS), e, in virtù del desiderio di coloro che non hanno molta esperienza, insegnare a coloro che non conoscono, cosa dove andare nella rete globale, subiscono spesso blocchi degli indirizzi dei propri server da parte di non diciamo chi — quindi avere un DNS, non soggetto all'influenza di "urla, fischi e scritti", per l'azienda significa meno danni al loro business. E i vantaggi tecnici (un dettaglio, ma piacevole: in particolare, per i clienti del DNS gratuito di Cloudflare, l'aggiornamento dei record DNS delle risorse ospitate sui server DNS dell'azienda sarà istantaneo) rendono l'utilizzo del servizio descritto nel post ancora più interessante.
Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.
Utilizzerai il nuovo servizio?
- Sì, semplicemente specificandolo nel sistema operativo e/o nel router
- Sì, e utilizzerò i nuovi protocolli (DNS over HTTPs e DNS over TLS)
- No, mi bastano i server attuali (si tratta di un provider pubblico: Google, Yandex, ecc.)
- No, non so nemmeno cosa stia usando ora
- Utilizzo i miei DNS ricorsivi con tunnel SSL fino a loro
Hanno votato 693 utenti. 191 utenti si sono astenuti.
Fonte: habr.com
