In questo articolo Indice dei contenuti 2 sezioni
Il DNS cifrato può accendersi da solo, senza che nessuno vada a cercare URL strani o a copiare indirizzi di server dentro le impostazioni di rete. Il meccanismo che rende possibile questa magia si chiama DDR, sigla di Discovery of Designated Resolvers, e parte da un dettaglio che sembra banale: l’indirizzo del resolver che il router distribuisce via DHCP. Da quella singola informazione un dispositivo compatibile riesce a capire se dello stesso servizio esiste anche una versione protetta, e a passarci sopra in automatico.
Il punto di partenza è noto. Le richieste DNS servono a tradurre un nome come www.ilsoftware.it nel relativo indirizzo IP, e nella versione tradizionale viaggiano in chiaro sulla porta 53. Chiunque controlli il percorso di rete può quindi osservarle o manipolarle. Protocolli come DNS over HTTPS (DoH), DNS over TLS (DoT) e DNS over QUIC (DoQ) chiudono invece quelle query dentro connessioni cifrate. Vale la pena precisare due cose: la cifratura protegge il tratto tra dispositivo e resolver, mentre il resolver continua a sapere benissimo cosa gli viene chiesto, e questi protocolli non sostituiscono DNSSEC, che ha il compito diverso di verificare autenticità e integrità dei dati restituiti.
Il dispositivo chiede al resolver se esiste una versione cifrata
Per decenni al client è bastato conoscere un indirizzo IP. 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 usare o quali protocolli siano supportati. DDR nasce esattamente per colmare quel vuoto e ha raggiunto la forma definitiva con la RFC 9462, pubblicata dall’IETF a novembre 2023 dopo anni di lavoro. Apple ne parlava già alla WWDC 2022, Microsoft ha inserito controlli dedicati nel client DNS di Windows.
La procedura comincia con una query particolare, rivolta al nome dns.resolver.arpa e indirizzata proprio al resolver già in uso. La risposta può annunciare uno o più endpoint, con i record SVCB che comunicano hostname, protocollo, porta, parametri e ordine di preferenza. Per DoH entra in gioco il parametro dohpath, che trasporta il Template URI necessario a costruire le richieste. Il parametro ALPN distingue invece le varianti disponibili, con dot per DoT, doq per DoQ e protocolli HTTP come h2 o h3 nel caso di DoH. Un client che ne supporta più di uno può seguire la priorità indicata, uno che capisce solo DoH ignora il resto.
Nel caso pratico un notebook entra in rete, riceve via DHCP l’indirizzo 192.168.1.1 come server DNS e nelle impostazioni continua a mostrare quel valore, verificabile in Windows con ipconfig /all. Dietro le quinte, però, il client interroga quell’indirizzo per dns.resolver.arpa, riceve l’annuncio di un endpoint DoH, controlla le informazioni, apre la connessione TLS e da lì in poi le richieste passano nel canale protetto. Utile soprattutto per apparecchi con interfacce spartane, tipo una smart TV, una console o un dispositivo embedded, dove l’unica cosa configurabile è un indirizzo DNS. Ovviamente DDR non può inventare capacità che non ci sono: se il dispositivo non supporta DoH, DoT o DoQ, non succede nulla.
Come attivare DDR su Windows 11 e cosa tenere d’occhio
Prima di abilitarlo conviene capire se la build installata espone il controllo. Il comando netsh dnsclient show global non sempre aiuta, perché su alcune versioni mostra solo lo stato di DoH e DoT. La verifica più affidabile è digitare netsh dnsclient set global ? e cercare nell’help il parametro ddr con i valori yes e no. In caso affermativo, da terminale con privilegi amministrativi si usa netsh dnsclient set global ddr=yes. L’impostazione globale autorizza Windows, ma il comportamento reale dipende anche dalla singola scheda di rete: con netsh dnsclient set interface ? si vedono le opzioni disponibili, mentre netsh dnsclient set interface name=”Wi-Fi” ddr=yes ddrfallback=yes abilita la discovery e consente il ritorno al DNS tradizionale se l’endpoint cifrato non risulta utilizzabile.
In una rete domestica l’attivazione non forza nulla. Il tentativo parte solo dai resolver non cifrati configurati sull’interfaccia e riesce soltanto se il server supporta DDR pubblicando informazioni valide. Le complicazioni arrivano altrove, in ambito aziendale, con VPN o dove il DNS svolge funzioni locali specifiche: split DNS, domini interni, filtri, parental control e sistemi di logging possono comportarsi diversamente. Da valutare anche firewall e apparati di sicurezza, capaci di permettere il DNS classico verso indirizzi precisi e bloccare HTTPS, TLS o QUIC verso l’endpoint scoperto. In quel caso la discovery riesce e il collegamento cifrato fallisce, ed è lì che la scelta su ddrfallback pesa davvero: con il fallback attivo la risoluzione continua in chiaro, senza fallback si rischia un blocco vero della risoluzione dei nomi.
