DoH o DoT: cosa protegge la cifratura DNS e cosa no

Il DNS classico invia le query in chiaro, quasi sempre sulla porta 53. L'RFC 7626, l'analisi dell'IETF sulla privacy del DNS, osserva che tale traffico può essere visto da un intercettatore come qualsiasi altro, e che un avversario che ha osservato le query di un utente potrebbe essere in grado di reidentificare quell'utente in seguito, dal solo schema delle query, da qualunque rete si colleghi. DNS over TLS (DoT) e DNS over HTTPS (DoH) sono stati standardizzati per proteggere quel primo tratto.

Quale tratto è protetto

Un lookup attraversa più collegamenti: lo stub resolver del tuo dispositivo interroga un resolver ricorsivo, che a sua volta interroga i server autorevoli. L'RFC 7858 dichiara di concentrarsi sulla protezione del primo di questi collegamenti, da stub a resolver ricorsivo. Il DoH, definito nell'RFC 8484, copre lo stesso collegamento. Negli scenari di impiego a cui mirano questi RFC, entrambi proteggono il contenuto della query e della risposta su quel collegamento e nulla oltre. L'RFC 7858 aggiunge che nulla impedisce di applicare in seguito il protocollo tra resolver ricorsivi e server autorevoli.

DNS over TLS (RFC 7858, 2016)

Il DoT incapsula i normali messaggi DNS in una sessione TLS su TCP. Client e server usano per impostazione predefinita la porta 853, e l'RFC vieta di usare quella porta per il DNS non cifrato. L'RFC 7858 definiva due profili d'uso: la privacy opportunistica, in cui il client prova la cifratura senza insistere nell'autenticare il server, e l'autenticazione out-of-band con key pinning, per i client che si fidano già di un server specifico. L'RFC 8310, che aggiorna l'RFC 7858, li ha generalizzati nei profili Strict e Opportunistic Privacy. Strict si rifiuta di procedere a meno che la connessione sia cifrata e il server autenticato. Opportunistic tenta cifratura e autenticazione ma non le richiede, quindi può finire in una connessione in chiaro e protegge solo da intercettatori passivi, non da un attaccante attivo sul percorso.

DNS over HTTPS (RFC 8484, 2018)

Il DoH associa ogni query e risposta DNS a uno scambio HTTP. Un client invia una GET, con il messaggio DNS codificato in base64url senza padding in un parametro di query dns, oppure una POST con il messaggio come corpo della richiesta. I server devono implementare entrambe, e il media type predefinito, che ogni client e server deve supportare, è application/dns-message. Questo è l'esempio dell'RFC stesso, una query per www.example.com:

:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message

Il valore dns si decodifica nella stessa query in formato wire di 33 byte che riceverebbe un resolver classico, header compreso, quindi tutto ciò che si trova in Dentro un messaggio DNS vale senza modifiche. Due dettagli sono pensati per la cache: le richieste GET si adattano alle cache HTTP, e i client dovrebbero inviare un ID DNS pari a 0, perché un ID variabile farebbe sì che query equivalenti vengano messe in cache separatamente. L'RFC indica HTTP/2 come versione minima raccomandata; le versioni precedenti possono trasportare il DoH ma potrebbero offrire prestazioni molto scarse.

Cosa vede un osservatore della rete

Mettere affiancati i tre trasporti mostra cosa cambia e cosa no, dal punto di vista di chi osserva la tua connessione di rete, una volta stabilita una sessione cifrata (modalità Strict, oppure modalità Opportunistic senza un attaccante attivo).

Cosa la cifratura non nasconde

• Il resolver vede tutto. DoT e DoH spostano la fiducia dal percorso di rete all'operatore del resolver, e le query restano comunque legate al tuo indirizzo presso quel resolver. Scegliere un resolver è una decisione sulla privacy oltre che sulla velocità.
• La connessione successiva è visibile. Dopo il lookup, il tuo dispositivo si connette all'indirizzo IP restituito, e la rete può vedere quell'indirizzo. Di norma anche il nome del server è visibile nell'handshake della connessione TLS che segue.
• L'integrità della risposta è un problema separato. La cifratura del trasporto protegge il collegamento con il resolver. Non dimostra che la risposta del resolver corrisponda a ciò che il titolare del dominio ha pubblicato; quello è compito del DNSSEC, trattato in DNSSEC spiegato.
• Il resto del percorso è fuori ambito. L'RFC 7858 si concentra sul traffico da stub a resolver ricorsivo. Il modo in cui un resolver interroga poi i server autorevoli è un'altra questione.

Compromessi per reti e operatori

Il DoT usa una porta propria, quindi una rete può riconoscerlo e decidere se consentirlo. Il DoH condivide la porta 443 con il normale traffico web, il che lo rende più difficile da individuare in base alla porta. L'RFC 8484 è esplicito sull'effetto operativo della cifratura del canale: i sistemi di filtraggio e ispezione che si basano su un trasporto DNS non protetto non funzioneranno in un ambiente DoH, e la scelta del server DNS da parte di un client può cambiare le risposte che ottiene, per esempio con lo split DNS. Una rete che dipende dal proprio resolver per il filtraggio o per i nomi interni deve sapere quali applicazioni portano con sé un resolver proprio.

Cambiano anche le prestazioni. Entrambi i trasporti richiedono un handshake TCP e TLS prima della prima query, quindi il riutilizzo della connessione conta; l'RFC 7858 raccomanda ai client di riutilizzare una connessione esistente invece di aprirne una per query. Un terzo trasporto, DNS over dedicated QUIC connections, è stato pubblicato come RFC 9250 nel 2022. Offre proprietà di cifratura simili a TLS evitando il blocco head-of-line di TCP, e usa la porta UDP 853.

Cosa significa per i lookup su questo sito

Gli strumenti di questo sito risolvono i nomi sul server, quindi l'impostazione di DNS cifrato del tuo dispositivo non cambia ciò che riportano. Per vedere cosa fanno i tuoi dispositivi, cerca l'impostazione DNS privato di Android, che usa il DoT, e le opzioni di DNS sicuro nei browser come Chrome e Firefox, che usano il DoH.

Fonti e letture di approfondimento

• RFC 7626: DNS Privacy Considerations (Bortzmeyer, 2015)
• RFC 7858: Specification for DNS over Transport Layer Security (TLS) (Hu et al., 2016)
• RFC 8310: Usage Profiles for DNS over TLS and DNS over DTLS (Dickinson, Gillmor and Reddy, 2018)
• RFC 8484: DNS Queries over HTTPS (DoH) (Hoffman and McManus, 2018)
• RFC 9250: DNS over Dedicated QUIC Connections (Huitema, Dickinson and Mankin, 2022)