Il DNS cifrato può attivarsi da solo: come funziona DDR

Sapevate che un PC o un qualunque altro dispositivo possono ricevere dal router il normale indirizzo del resolver DNS tramite DHCP e usare quella sola informazione per scoprire se esiste una versione cifrata dello stesso servizio? Il meccanismo che rende possibile questo passaggio si chiama DDR, Discovery of Designated Resolvers. Un DNS cifrato, quando effettivamente disponibile, può quindi attivarsi in automatico senza che l’utente conosca un URL DoH, scelga manualmente un server DoT o modifichi parametri avanzati.

I DNS cifrati servono a proteggere le richieste che il dispositivo invia al resolver per tradurre un nome come www.ilsoftware.it nel relativo indirizzo IP. Con il servizio DNS tradizionale, queste interrogazioni viaggiano normalmente in chiaro sulla porta 53 e possono quindi essere osservate o manipolate da chi controlla il percorso di rete. Protocolli come DNS-over-HTTPS (DoH), DNS-over-TLS (DoT) e DNS-over-QUIC (DoQ) racchiudono invece le query all’interno di connessioni cifrate, impedendo a un osservatore intermedio di leggerne direttamente il contenuto.

La cifratura, va precisato, protegge il tragitto tra il dispositivo e il resolver: quest’ultimo continua a conoscere le richieste ricevute. Inoltre DoH, DoT e DoQ non svolgono lo stesso compito di DNSSEC, che serve invece a verificare l’autenticità e l’integrità dei dati DNS restituiti.

Come funziona l’individuazione di un DNS cifrato con DDR

Un dispositivo entra nella rete WiFi o cablata, riceve via DHCP l’indirizzo del server DNS e comincia a navigare. È il comportamento normale da decenni: al client basta conoscere l’indirizzo IP di un resolver, per inviare le richieste DNS sulla porta 53. Con i protocolli cifrati la faccenda si complica, perché un semplice IP non dice quale endpoint HTTPS contattare, quale nome verificare nel certificato TLS, quale porta utilizzare o se il resolver supporti DoH, DoT oppure DoQ.

DDR nasce precisamente per colmare questa lacuna: permette al client di partire dalla normale configurazione DNS ricevuta dalla rete (ad esempio dal router) e scoprire automaticamente la variante cifrata dello stesso servizio.

Grazie a DDR, il passaggio al DNS cifrato non richiede necessariamente che l’utente conosca l’URL di un server DoH o inserisca manualmente parametri avanzati. Se il sistema operativo o il client DNS supportano DDR, l’indirizzo distribuito dal router può diventare il punto di partenza per trovare un resolver DoH, DoT o DoQ equivalente. In pratica, la vecchia configurazione “usa questo IP come DNS” può trasformarsi automaticamente in una connessione protetta.

Il meccanismo ha raggiunto la forma definitiva con la RFC 9462, pubblicata dall’IETF (Internet Engineering Task Force) a novembre 2023, dopo anni di lavoro e sperimentazioni. Apple ne illustrava già l’impiego alla WWDC 2022; Microsoft ha integrato controlli specifici per DDR nel client DNS di Windows. È quindi una tecnologia concreta, non un esercizio teorico, e affronta un problema che diventa sempre più evidente man mano che la cifratura del DNS si sposta dai browser al sistema operativo.

Il PC chiede al DNS stesso se esista una versione cifrata

La procedura di discovery del DNS cifrato parte con una query particolare: il client interroga il nome _dns.resolver.arpa. La richiesta è riservata proprio allo scopo di individuare versioni cifrate del servizio DNS in uso e deve raggiungere proprio il resolver che il dispositivo sta già utilizzando.

Il resolver può rispondere annunciando uno o più endpoint. Un server potrebbe offrire DoH e DoT contemporaneamente, un altro aggiungere DoQ; tramite i record SVCB, Service Binding, può comunicare hostname, protocollo, porta, parametri specifici e ordine di preferenza.

Per DoH, per esempio, entra in gioco anche il parametro dohpath, che permette di comunicare il Template URI necessario per costruire le richieste HTTPS. Il parametro ALPN aiuta invece a distinguere i protocolli disponibili: dot identifica DoT, doq DoQ, mentre per DoH possono comparire protocolli HTTP quali h2 o h3.

Un client che supporta più alternative può rispettare la priorità indicata dal resolver. Uno che comprende soltanto DoH può ignorare DoT e DoQ.

Il caso pratico: il router assegna il DNS via DHCP, DDR fa il resto

Immaginiamo un notebook che entra in una rete. Attraverso DHCP riceve l’indirizzo 192.168.1.1 come server DNS: dal punto di vista dell’utente non cambia nulla: nelle impostazioni continua a comparire il resolver indicato dalla rete (in Windows lo si può verificare digitando ipconfig /all).

Un client compatibile DDR può però interrogare 192.168.1.1 per _dns.resolver.arpa. Il server risponde annunciando che il servizio cifrato è disponibile, per esempio, tramite DoH presso un determinato hostname. Il client verifica le informazioni ricevute, stabilisce la connessione TLS e, se le condizioni di sicurezza previste risultano soddisfatte, le successive richieste DNS possono viaggiare all’interno del canale cifrato.

L’utente non ha dovuto cercare il sito del provider, copiare un URL DoH o modificare manualmente la configurazione di rete. La ricerca del DNS cifrato e la configurazione automatica si concretizzano partendo proprio dalla configurazione esistente.

L’approccio descritto può risultare utile per dispositivi con interfacce di configurazione molto limitate: una smart TV, una console o un apparecchio embedded potrebbero permettere all’utente di impostare soltanto un indirizzo DNS; se però il suo stack di rete implementa DDR e almeno uno dei protocolli cifrati supportati dal resolver, quella singola informazione può bastare per effettuare il passaggio al DNS cifrato.

Ovviamente DDR non può configurare DoH, DoT o DoQ su un dispositivo che non supporta questi protocolli: si limita a facilitare la scoperta dell’endpoint per i client che possiedono già le necessarie capacità software.

Come verificare se Windows 11 supporta DDR e abilitarlo

Prima di attivare DDR conviene verificare che la versione di Windows 11 in uso esponga effettivamente il relativo controllo. Il comando netsh dnsclient show global non è sempre indicativo: su alcune build mostra soltanto lo stato globale di DoH e DoT e non riporta una voce specifica per DDR.

La verifica più affidabile consiste quindi nel digitare:

netsh dnsclient set global ?

Se nell’help compare il parametro ddr con i valori yes e no, il client DNS di Windows supporta Discovery of Designated Resolvers. Microsoft descrive ddr=yes come l’opzione che abilita l’uso di DDR in base alle impostazioni dell’interfaccia, del server DNS o di altre configurazioni.

Per abilitarlo globalmente si può quindi usare, da un terminale aperto con privilegi amministrativi:

netsh dnsclient set global ddr=yes

L’impostazione globale, da sola, autorizza Windows a utilizzare DDR. Il comportamento concreto dipende però anche dalla singola interfaccia di rete. Per esempio, sulla WiFi si può verificare quali opzioni siano disponibili con:

netsh dnsclient set interface ?

e quindi abilitare la discovery con:

netsh dnsclient set interface name="Wi-Fi" ddr=yes ddrfallback=yes

Con ddr=yes, Windows può tentare la scoperta di un resolver cifrato partendo dai server DNS non protetti configurati sulla scheda, compresi quelli ricevuti automaticamente tramite DHCP. ddrfallback=yes consente invece il ritorno al DNS tradizionale se l’endpoint cifrato individuato tramite DDR non è utilizzabile.

Ci sono effetti collaterali nell’attivare DDR?

In una rete normale, attivare DDR non significa obbligare Windows a usare un DNS cifrato a tutti i costi. Il client tenta la discovery soltanto sui resolver non cifrati configurati per l’interfaccia e l’upgrade riesce solo se il server supporta DDR e pubblica informazioni valide. Un normale resolver che non conosce DDR continua quindi a funzionare come prima; non viene trasformato automaticamente in un servizio DoH o DoT.

Gli effetti collaterali possono però emergere nelle reti aziendali, con VPN o installazioni nelle quali il DNS svolge funzioni locali particolari. Se Windows scopre e utilizza un resolver cifrato differente dal percorso DNS che l’amministratore si aspetta, possono cambiare alcuni comportamenti legati a split DNS, domini interni, filtri DNS, parental control o sistemi di logging.

Bisogna considerare anche firewall e apparati di sicurezza. Un’organizzazione potrebbe consentire l’uso del DNS tradizionale verso specifici indirizzi e bloccare invece HTTPS, TLS o QUIC verso l’endpoint scoperto. In una situazione del genere DDR può riuscire nella discovery ma il successivo collegamento cifrato può fallire. La scelta di ddrfallback=yes o no diventa quindi importante: con il fallback consentito la risoluzione può continuare in chiaro; senza fallback un problema sul canale cifrato può tradursi in un vero malfunzionamento della risoluzione dei nomi di dominio.