OARC 45 Ascolta Perché la Crittografia del Salto Resolver-to-Authoritative del DNS è in Stallo

Il Domain Name System (DNS), spesso descritto come la rubrica telefonica di Internet, traduce i nomi di dominio facili da usare negli indirizzi IP numerici utilizzati dai computer. Quasi ogni attività online inizia con una query DNS, e se qualcuno può osservare tutte le tue query DNS, può costruire un quadro dettagliato della tua vita online. Per anni questa debolezza della privacy ha attirato poca attenzione, ma le rivelazioni di Snowden nel 2013 hanno messo saldamente la sorveglianza di massa e la privacy del DNS nell'agenda. Per impostazione predefinita, le query e le risposte DNS viaggiano in testo semplice, il che le rende vulnerabili a intercettazioni e manipolazioni da parte di chiunque si trovi nel percorso di rete.

Per affrontare questo problema, la Internet Engineering Task Force (IETF) ha sviluppato protocolli DNS crittografati: DNS su TLS (DoT), DNS su QUIC (DoQ) e DNS su HTTPS (DoH), collettivamente noti come DoX. Questi aggiungono crittografia e autenticazione del server al collegamento tra il dispositivo dell'utente (il 'resolver stub') e un resolver ricorsivo, il server che svolge il lavoro vero e proprio di trovare le risposte DNS. L'impostazione di una sessione crittografata aggiunge overhead rispetto a una query UDP semplice, ma poiché il dispositivo può riutilizzare la stessa sessione crittografata per molte query, il costo viene ammortizzato. Geoff Huston nota che presso il resolver pubblico 1.1.1.1 di Cloudflare, DoH rappresenta circa il 15% del carico di query e DoT circa il 10%, anche se sospetta che i numeri siano molto più bassi per i resolver gestiti dagli ISP dove l'utente è già sulla rete dell'ISP.

Tuttavia, questo copre solo il primo salto. Il secondo salto è tra il resolver ricorsivo e i server dei nomi autoritativi che detengono i record ufficiali per un dominio. Questa tratta è meno un rischio per la privacy individuale perché l'indirizzo IP dell'utente non è incluso nella query, ma c'è ancora un'esposizione: le query rivelano quale dominio viene cercato, e se un attaccante può alterare una risposta, può avvelenare la cache del resolver ricorsivo così da servire risposte false a molti utenti finché la cache non scade, un attacco noto come avvelenamento della cache. Una mitigazione è la minimizzazione del nome della query (RFC 9516), in cui il resolver ricorsivo invia solo le etichette minime necessarie a ciascun server autoritativo durante il processo di scoperta e può nascondere il tipo di query originale. Uno studio di misurazione del 2020 ha rilevato che circa il 18% degli utenti Internet passa le proprie query attraverso resolver ricorsivi che eseguono la minimizzazione del nome della query.

Un altro approccio è la crittografia opportunistica del salto ricorsivo-autoritativo, descritta nella RFC 9539 'Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS'. Questo utilizza la crittografia senza autenticazione, seguendo il principio della sicurezza opportunistica nella RFC 7435. Uno studio recente presentato all'OARC 46 ha misurato il supporto per il DNS autoritativo opportunistico su trasporto crittografato (ADoX). Ha rilevato che i server autoritativi per 3.074.281 domini registrati (0,93%) supportano qualche forma di ADoX, e guardando agli indirizzi IP di questi nameserver, solo 2.585 nameserver unici (0,32%) supportano ADoX. Uno studio comparabile che utilizza le sonde RIPE Atlas ha trovato nessun resolver ricorsivo che utilizza ADoQ e solo 44 sonde dietro resolver ricorsivi che utilizzano ADoT, per lo più gestite dal servizio resolver aperto Quad9. In pratica, l'implementazione è in stallo: gli operatori dei server autoritativi vedono pochi benefici nel supportare ADoX se nessun resolver lo usa, e i costi incrementali del server per sessioni crittografate sono molto più alti rispetto a UDP senza stato. I resolver ricorsivi non vedono alcun motivo per supportare ADoX se nessun server autoritativo lo supporta.

L'approccio opportunistico ha chiari svantaggi. Richiede diversi scambi di round-trip per tentare una connessione TLS/TCP o QUIC con un server autoritativo; per una singola query, questo overhead è più alto di una semplice transazione UDP. A differenza del caso stub-resolver, non c'è certezza di riutilizzo della sessione: il resolver potrebbe non interrogare mai più quel server autoritativo. Inoltre, poiché il server non è autenticato nella crittografia opportunistica, un attaccante potrebbe comunque agire come un uomo nel mezzo; la validazione DNSSEC dei domini firmati è necessaria per confermare l'autenticità delle risposte. Sul lato positivo, il trasporto crittografato può gestire meglio risposte di grandi dimensioni e consente approcci sperimentali come le CHAIN Query Requests (RFC 7901).

Un approccio diverso utilizza il record di risorsa DELEG proposto per segnalare le capacità di trasporto crittografato di un server. DELEG si basa sul formato Service Binding (SVCB) e non è una modifica minore; rappresenta un cambiamento architetturale importante. In un record DELEG, la zona padre include informazioni che un'etichetta è un punto di delega, insieme ai nameserver della zona delegata, le loro chiavi crittografiche, gli indirizzi IP e le capacità di protocollo, tutto in un unico record firmato DNSSEC. Per un resolver, DELEG può comunicare in modo rigoroso quale trasporto crittografato supportano i server autoritativi, così il resolver può saltare il probing opportunistico e semplicemente usare il protocollo pubblicizzato. Tuttavia, Huston sottolinea che la validazione DNSSEC garantisce solo l'autenticità della risposta DNS finale; non garantisce che il resolver abbia effettivamente attraversato da padre a figlio o che ogni delega DELEG sia stata validata indipendentemente. Ci sono stati avvertimenti al workshop OARC che spostare l'intero DNS da UDP leggero a sessioni crittografate potrebbe avere 'conseguenze catastrofiche' se fatto frettolosamente.

Quindi questo lavoro è più di un esercizio accademico? Al momento, le specifiche per ADoX opportunistico e DELEG sono per lo più esercizi di carta. L'attuale quadro di Internet per autenticare le transazioni online si basa su certificati di dominio X.509 e TLS, non sulla garanzia dei risultati della risoluzione DNS. Un attaccante può ancora iniettare false informazioni DNS, ma quando un servizio applicativo usa TLS (ad esempio HTTPS), il server deve dimostrare di possedere la chiave privata per il nome di dominio; se non può, la connessione viene abbandonata. ADoX o DELEG non cambiano questo quadro. Non possono nemmeno sostituire DNSSEC; i due risolvono problemi diversi: ADoX riguarda come un resolver risolve un nome, mentre DNSSEC riguarda se un utente può fidarsi del risultato. Sono complementari.

Un purista della sicurezza vorrebbe controlli rigorosi in ogni fase: validare i record DELEG firmati, aprire sessioni crittografate e autenticate con endpoint con ogni server autoritativo, e validare DNSSEC la risposta finale. Ma la realtà pragmatica è che utenti e fornitori di servizi preferiscono DNS veloce ed economico. La funzione di autenticazione è spinta al livello applicativo tramite l'handshake TLS, e gli operatori dell'infrastruttura DNS non sopportano alcun costo incrementale. Tentare di spingere i costi di garanzia sull'infrastruttura di risoluzione dei nomi incontra una resistenza considerevole. In altre parole, l'agenda DPRIVE si è fermata al salto ricorsivo-autoritativo perché c'era un interesse insufficiente nel gestire quel modello di infrastruttura.

Qual è il futuro per la crittografia del salto ricorsivo-autoritativo? Huston non è sicuro di poter indicare un futuro assicurato. L'economia gioca contro gli operatori dell'infrastruttura DNS; assorbire costi extra per sessioni crittografate senza entrate incrementali non è una decisione aziendale sensata. Per gli utenti, il DNS rimane in gran parte gratuito perché l'autenticazione è fornita da TLS al livello applicativo. Questo quadro è improbabile che cambi presto. Per i lettori che vogliono una protezione pratica oggi, scegliere un resolver DNS crittografato incentrato sulla privacy come AEU DNS può aiutare a crittografare il primo salto tra i tuoi dispositivi e il resolver, anche se la crittografia più profonda resolver-autoritativo descritta qui rimane irrisolta.