DNS over HTTPS su Windows Server 2025: configurazione completa e considerazioni enterprise

Cos’è DNS over HTTPS e perché cambia le regole del gioco

Il DNS tradizionale risolve i nomi di dominio inviando query in chiaro su UDP o TCP sulla porta 53. Chiunque si trovi sul percorso di rete — un ISP, un operatore Wi-Fi aziendale o un attaccante con accesso al segmento — può leggere o manipolare quelle query. DNS over HTTPS (DoH) risolve questo problema incapsulando le query DNS all’interno di connessioni HTTPS cifrate con TLS: lo stesso meccanismo di crittografia utilizzato dalla normale navigazione web.

Con l’aggiornamento cumulativo di giugno 2026 (KB5094125) per Windows Server 2025, Microsoft ha reso disponibile DoH in modalità General Availability per il ruolo DNS Server on-premises. Non è più necessario affidarsi a resolver di terze parti: la cifratura DNS parte ora direttamente dalla propria infrastruttura interna.

DoH vs DNS over TLS: quale scegliere in ambienti enterprise

Esiste un protocollo simile, DNS over TLS (DoT), che cifra anch’esso il traffico DNS ma utilizza la porta dedicata 853. Questa scelta ha una conseguenza pratica rilevante: i sistemi di monitoraggio di rete possono identificare e filtrare il traffico DoT separatamente, mantenendo la visibilità sulle query DNS.

DoH, invece, transita sulla porta 443 e si fonde con il normale traffico HTTPS. Da un lato questo lo rende più difficile da bloccare; dall’altro riduce la visibilità degli strumenti di ispezione DNS aziendali. Prima di scegliere DoH in un ambiente enterprise, occorre valutare se la propria security operations si affida all’ispezione del traffico DNS per rilevare minacce (data exfiltration via DNS, C2 beaconing, ecc.). In quel caso, DoT potrebbe essere preferibile, oppure occorre affiancare soluzioni di monitoring che lavorino a livello applicativo.

Requisiti di sistema

Per abilitare DoH sul ruolo DNS Server di Windows Server 2025 sono necessari:

Windows Server 2025 con l’aggiornamento cumulativo KB5094125 (9 giugno 2026) o successivo
Un certificato TLS valido con Extended Key Usage “Server Authentication” e un Subject Alternative Name (SAN) che corrisponda al template URI DoH
La chiave privata del certificato presente nel certificate store del computer locale, senza strong private key protection abilitata
Il certificato emesso da una CA trusted da server e client (Microsoft Enterprise CA, DigiCert, Let’s Encrypt — tutte funzionano)
Porta TCP 443 aperta in ingresso sul firewall del server
Accesso amministrativo al server

Da notare: al momento non è disponibile alcuna interfaccia grafica nel DNS Manager per gestire DoH. Tutta la configurazione avviene tramite PowerShell.

Configurazione passo per passo

Step 1 — Importare il certificato TLS

Copiare il file .pfx del certificato sul server e importarlo nel certificate store del computer locale:

Import-PfxCertificate `
    -FilePath "C:\Certs\dns-server.pfx" `
    -CertStoreLocation "Cert:\LocalMachine\My" `
    -Password (Read-Host -AsSecureString "Password PFX")

Step 2 — Associare il certificato alla porta 443

Generare un GUID univoco e associare il certificato alla porta tramite netsh:

$guid = New-Guid
$cert = Get-ChildItem -Path Cert:\LocalMachine\My |
        Where-Object { $_.Subject -match "dns.dominio.local" }

netsh http add sslcert ipport=0.0.0.0:443 `
    certhash=$($cert.Thumbprint) `
    appid="{$guid}"

Per vincolare il binding a un indirizzo IP specifico anziché a tutti gli indirizzi, sostituire 0.0.0.0 con l’indirizzo desiderato.

Step 3 — Aprire la porta 443 nel firewall di Windows

New-NetFirewallRule `
    -DisplayName "DNS over HTTPS" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 443 `
    -Action Allow

Step 4 — Abilitare DoH e configurare il template URI

Sostituire dns.dominio.local con il hostname presente nel SAN del certificato:

Set-DnsServerEncryptionProtocol `
    -EnableDoh $true `
    -UriTemplate "https://dns.dominio.local:443/dns-query"

Restart-Service -Name DNS

Step 5 — Verificare la configurazione

Get-DnsServerEncryptionProtocol

Aprire il Visualizzatore eventi sotto Applications and Services Logs > DNS Server e verificare la presenza dell’evento ID 822, che conferma l’avvio del servizio DoH.

Configurare i client Windows per usare DoH

Windows supporta DoH lato client da Windows 11 (e da Windows Server 2022 nel ruolo di client DNS). Esistono due metodi principali per puntare i client al resolver DoH interno:

Interfaccia grafica (Windows 11)

Navigare in Impostazioni > Rete e Internet > Ethernet (o Wi-Fi) > Assegnazione server DNS, inserire l’indirizzo IP del server DNS e impostare la cifratura DNS su Solo cifrato (DNS over HTTPS).

Group Policy (Windows Server 2022 e successivi)

Applicare il criterio in Configurazione computer > Criteri > Modelli amministrativi > Rete > Client DNS > Configura risoluzione dei nomi DNS over HTTPS (DoH). Il criterio offre tre opzioni:

Consenti DoH — usa DoH se il resolver lo supporta
Proibisci DoH — impedisce l’uso di DoH
Richiedi DoH — richiede sempre DoH

Attenzione: Microsoft sconsiglia di impostare “Richiedi DoH” su computer appartenenti a un dominio Active Directory se i server DNS non supportano ancora DoH come resolver. AD dipende pesantemente dal DNS, e forzare DoH su una rete senza resolver compatibile interrompe la risoluzione dei nomi e, di conseguenza, l’autenticazione e i GPO. Ora che Windows Server 2025 supporta il lato server, l’opzione “Richiedi DoH” diventa praticabile in ambienti completamente migrati.

Limitazioni attuali da tenere presenti

Prima di pianificare un deployment in produzione, è importante conoscere i limiti della GA attuale:

Nessuna cifratura verso gli upstream resolver. DoH cifra solo il traffico tra i client e il DNS Server Windows. Le query che il DNS Server invia ai forwarder upstream o ai server autorevoli viaggiano ancora in chiaro sulla porta 53. Microsoft ha annunciato il supporto per query upstream cifrate in un aggiornamento futuro, ma senza timeline confermata.
Nessuna interfaccia grafica. Il DNS Manager non include ancora le impostazioni DoH. Tutta la gestione richiede PowerShell.
Punti ciechi nel monitoraggio. Il traffico DoH su porta 443 è cifrato e indistinguibile dall’HTTPS web. Gli strumenti di monitoring DNS a livello di rete perdono visibilità. Valutare l’impatto sulla security operations prima di abilitare DoH in modo capillare.
DoH non sostituisce DNSSEC. DoH cifra il trasporto; DNSSEC verifica l’integrità delle risposte DNS con firme crittografiche. Le due tecnologie sono complementari e indipendenti: DoH senza DNSSEC protegge dalla sorveglianza ma non dalla manipolazione delle risposte da parte del server stesso.

Considerazioni per il deployment

Un approccio pragmatico per l’introduzione di DoH in un ambiente enterprise prevede di partire con la policy “Consenti DoH” — non forzata — su un gruppo pilota di macchine, verificare che i log di audit DNS continuino a funzionare (adattando gli strumenti di monitoraggio se necessario) e solo successivamente estendere il rollout. Per gli ambienti con requisiti di compliance legati all’ispezione del traffico DNS, è consigliabile documentare la strategia di visibilità alternativa prima di procedere con “Richiedi DoH”.

Il supporto nativo sul DNS Server on-premises è un passo significativo: elimina la dipendenza da resolver cloud di terze parti e permette di mantenere la cifratura DNS all’interno del perimetro aziendale, con pieno controllo sul certificato e sul logging.

Fonte: DNS over HTTPS (DoH) for Windows Server 2025 DNS Server is generally available — 4sysops