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 si utilizzi una politica "Privacy first", quindi gli utenti possono stare tranquilli riguardo ai contenuti delle loro richieste.
Il servizio è interessante poiché, oltre al normale DNS, offre la possibilità di utilizzare tecnologie DNS-over-TLS e DNS-over-HTTPS, il che impedisce notevolmente ai fornitori di monitorare le vostre richieste lungo il percorso e di raccogliere statistiche, controllare la pubblicità. Cloudflare sostiene che la data di annuncio (1 aprile 2018, o 04/01 nella notazione americana) sia stata scelta non a caso: in quale altro giorno dell'anno presentare "quattro unità"?
Poiché il pubblico di Habr è tecnicamente esperto, posizionerò la tradizionale sezione "perché è necessario il DNS?" alla fine del post, mentre qui illustrerò cose più pratiche e utili:
Come utilizzare il nuovo servizio?
La cosa più semplice è indicare nei propri client DNS (o come upstream nelle impostazioni del server DNS locale che stai utilizzando) gli indirizzi DNS sopra citatiserver.Ha senso sostituire i valori abituali dei DNS di Google (8.8.8.8 e così via), o quelli un po' meno comuni. server DNS pubblici di Yandex (77.88.8.8 e simili) ai server di Cloudflare - lo risolveranno per te, ma parla per i principianti grafico velocità di risposta, secondo il quale Cloudflare è più veloce di tutti i concorrenti (preciso: le misurazioni sono state effettuate da un servizio esterno e la velocità per il cliente specifico può ovviamente differire).
È molto più interessante lavorare con le nuove modalità, in cui la richiesta viene inviata su un server una connessione crittografata (in effetti, la risposta viene restituita su quella stessa), chiamate DNS-over-TLS e DNS-over-HTTPS. Sfortunatamente, non sono supportate 'di default' (gli autori credono che sia 'per ora'), ma non è difficile organizzare il loro funzionamento nel proprio software (o addirittura sul proprio hardware):
DNS over HTTPs (DoH)
Come suggerisce il nome, la comunicazione avviene sopra un canale HTTPS, il che richiede
- la presenza di un punto di atterraggio (endpoint) - che si trova all'indirizzo https://cloudflare-dns.com/dns-query, e
- un client che sa inviare richieste e ricevere risposte.
Le richieste possono essere sia nel formato DNS Wireformat, definito in RFC1035 (inviare tramite metodi HTTP POST e GET), oppure in formato JSON (usando il metodo HTTP GET). Personalmente, l'idea di effettuare richieste DNS tramite richieste HTTP mi è sembrata inaspettata, tuttavia ha un fondamento razionale: tale richiesta supererà molti sistemi di filtraggio del traffico, analizzare le risposte è abbastanza semplice e formare richieste è ancora più facile. La sicurezza è garantita dalle biblioteche e dai protocolli abituali.
Esempi di richieste, direttamente 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 multiuso
* Stato della connessione cambiato (HTTP/2 confermato)
* Copiando i dati HTTP/2 nel buffer di connessione dopo l'aggiornamento: len=0
* Utilizzando 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: */*
* 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 al host cloudflare-dns.com è rimasta attiva
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 al host cloudflare-dns.com è rimasta attiva
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
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 nessuno) router domestici riescono a gestire il DNS in questo modo, ma ciò non significa che il supporto non possa arrivare domani — e, cosa interessante, qui possiamo implementare la gestione del DNS nella nostra applicazione (come già sta per fare Mozilla, proprio sui server di Cloudflare).
DNS over TLS
Per impostazione predefinita, le richieste DNS vengono inviate senza crittografia. DNS over TLS è un modo per inviarle attraverso una connessione sicura. Cloudflare supporta DNS over TLS sulla porta standard 853, come stabilito da RFC7858. In questo caso, viene utilizzato un certificato rilasciato per l'host cloudflare-dns.com, supportando TLS 1.2 e TLS 1.3.
L'instaurazione della connessione e il funzionamento tramite il protocollo avvengono all'incirca in questo modo:
- Prima di stabilire la connessione, il client DNS conserva l'hash SHA256 del certificato TLS di cloudflare-dns.com (denominato SPKI) codificato in base64.
- 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 suo certificato TLS.
- Una volta stabilita la connessione TLS, il client DNS può inviare richieste DNS su un canale protetto, il che previene l'intercettazione e la falsificazione di richieste e risposte.
- Tutte le richieste DNS inviate attraverso la connessione TLS devono conformarsi alla specifica per l'invio di DNS su TCP.
Esempio di richiesta tramite 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
Questa opzione sembra più adatta per i server DNS locali che servono le esigenze di una rete locale o di un singolo utente. Certo, il supporto per lo standard non è molto buono, ma speriamo bene!
Due parole di chiarimento su cosa si tratta
L'abbreviazione DNS sta per Dominio Name Service (quindi dire «servizio DNS» è un po' ridondante, dato che nell'abbreviazione è già presente la parola «servizio»), e viene utilizzata per risolvere un compito semplice: capire quale indirizzo IP corrisponde a un determinato nome host. Ogni volta che una persona clicca su un link o inserisce un indirizzo nella barra degli indirizzi del browser (diciamo, qualcosa come «https://habrahabr.ru/post/346430/«), il computer della persona cerca di capire a quale server deve inviare la richiesta per ricevere il contenuto della pagina. Nel caso di habrahabr.ru, la risposta dal DNS conterrà l'indirizzo IP del server web: 178.248.237.68, e poi il browser cercherà di connettersi al server all'indirizzo IP specificato.
Il server DNS, ricevendo una richiesta del tipo "qual è l'indirizzo IP dell'host con il nome habrahabr.ru?", verifica se ha informazioni riguardo a quell'host. Se non le ha, invia una richiesta ad altri server DNS nel mondo e, passo dopo passo, cerca di trovare risposta alla domanda. Alla fine, una volta trovato il risultato, i dati vengono inviati al cliente che ha effettuato la richiesta, oltre a essere memorizzati nella cache del server DNS stesso, il che permetterà di rispondere a domande simili molto più rapidamente la prossima volta.
Un problema comune è che, in primo luogo, i dati delle query DNS vengono trasmessi in chiaro (il che consente a chiunque abbia accesso al flusso di traffico di estrarre le query DNS e le risposte ricevute per analizzarle per i propri scopi; questo permette di targetizzare la pubblicità con precisione sul cliente DNS, il che non è poco!). In secondo luogo, alcuni fornitori di servizi Internet (non faremo nomi, ma non sono di certo i più piccoli) tendono a mostrare pubblicità invece della pagina richiesta (ciò avviene piuttosto facilmente: al posto dell'indirizzo IP specificato per la query al nome host habranabr.ru, all'utente viene restituito casualmente l'indirizzo di un server web del provider, dove viene mostrata una pagina contenente pubblicità). In terzo luogo, esistono fornitori di accesso a Internet che implementano un meccanismo per soddisfare le richieste di blocco di singoli siti, sostituendo le risposte DNS corrette per gli indirizzi IP delle risorse web bloccate con l'indirizzo del proprio server contenente pagine placeholder (di conseguenza, l'accesso a tali siti diventa significativamente più complicato), oppure con l'indirizzo del proprio server proxy che svolge la filtrazione.
Qui probabilmente dovrebbe essere inserita un'immagine del sito http://1.1.1.1/, utilizzata per descrivere la connessione al servizio. Gli autori, a quanto pare, sono assolutamente certi della qualità del loro DNS (del resto, da Cloudflare è difficile aspettarsi altro):
Si può ben comprendere l'azienda Cloudflare, creatrice del servizio: guadagnano da vivere sostenendo e sviluppando una delle reti CDN più popolari al mondo (tra le cui funzioni ci sono non solo la distribuzione di contenuti, ma anche l'hosting di zone DNS), e, a causa del desiderio di quelli che non sono molto esperti, di insegnare a quelli che non conoscono, dove andare nella rete globale, frequentemente soffrono di blocchi degli indirizzi dei loro server da parte di non diciamo chi — quindi avere un DNS non soggetto all'influenza di 'grida, fischi e scritti' significa per l'azienda 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à immediato) rendono l'utilizzo del servizio descritto nel post ancora più interessante. Utilizzerete il nuovo servizio?
Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.
Sì, semplicemente specificandolo nel sistema operativo e/o sul router
- Sì, basta indicarlo nel sistema operativo e/o nel router
- Sì, e utilizzerò i nuovi protocolli (DNS over HTTPs e DNS over TLS)
- No, mi basta il servizio attuale (questo è un provider pubblico: Google, Yandex, ecc.)
- No, non so nemmeno quale servizio stia usando ora
- Utilizzo i miei DNS ricorsivi con tunnel SSL verso di loro
Hanno votato 693 utenti. 191 utenti si sono astenuti.
Fonte: habr.com
