Windows Server DNS: stato del supporto DoT/DoH, workaround e guida completa

Vuoi abilitare DNS over TLS (DoT) o DNS over HTTPS (DoH) nel ruolo “DNS Server” di Windows Server per proteggere le query dei tuoi client? In questo articolo trovi lo stato reale del supporto, come richiedere la funzionalità a Microsoft e architetture pronte all’uso per colmare il gap subito.

Indice

Contesto: cosa sono DoT e DoH e perché interessano al mondo Windows Server

DoT e DoH cifrano le interrogazioni DNS tra client e resolver ricorsivo, mitigando intercettazioni, manipolazioni e profilazione del traffico. Il ruolo “DNS Server” di Windows Server è spesso collocato direttamente sui Domain Controller: qui vive l’autorità per le zone Active Directory–integrated, con caching e forwarding per il resto di Internet. Integrare cifratura anche lato server aiuterebbe a chiudere un anello debole tipico: la tratta “endpoint ⇄ DNS aziendale”.

Caratteristica	DoT	DoH
Pila protocollare	DNS su TLS (TCP/853)	DNS su HTTPS (HTTP/2 o HTTP/3 su TCP/443 o QUIC/443)
Visibilità per proxy HTTP	Nessuna (non è HTTP)	Alta (è traffico HTTP/HTTPS standard)
Bypass di filtraggio DPI	Medio	Alto: indistinguibile da normale web
Impatto su CPU	Moderato (TLS su TCP)	Superiore (TLS + HTTP/2/3)
Uso tipico	Ambienti enterprise, reti gestite	Client Internet, roaming, reti ostili

Problema posto

Molti amministratori chiedono se il ruolo “DNS Server” di Windows Server (versioni 2022 e anteprima 2025) sia in grado di erogare risposte direttamente tramite DoT o DoH. In caso negativo, come proporre l’aggiunta della funzionalità e quali workaround adottare nel frattempo?

Soluzione / stato attuale (oggi)

Assenza di supporto nativo: Windows Server 2022 e la build Preview 2025 non includono la capacità di servire richieste DNS tramite DoT o DoH direttamente dal ruolo “DNS Server”. Il servizio continua a esporre DNS classico su UDP/53 e TCP/53.
Roadmap: ad oggi Microsoft non ha annunciato piani ufficiali per introdurre questa funzione lato server.
Come proporre la funzione: occorre inviare feedback tramite i canali ufficiali (Windows Insider Feedback Hub, categoria Server → Networking, oppure il portale “Feedback per Windows Server” raggiungibile da aka.ms/serverfeedback). Le priorità vengono valutate anche in base a volume e qualità delle segnalazioni.

Perché chiedere il supporto nativo in Windows Server

Conformità: molte policy interne e normative spingono verso la cifratura end‑to‑end di protocolli storicamente in chiaro (NIS2, Zero Trust, hardening baseline).
Riduzione del rischio: minore esposizione a spoofing, MITM e tracciamento del traffico DNS interno.
Semplificazione: avere DoT/DoH integrati nel ruolo DNS riduce componenti esterni (proxy, container) e semplifica l’osservabilità.

Come inviare un feedback efficace a Microsoft

Per massimizzare l’impatto del feedback, non limitarti a una richiesta generica. Segui una struttura concreta e ripetibile.

Canali consigliati

Feedback Hub su Windows (categoria Server → Networking), indicando “Windows Server DNS Server: supporto DoT/DoH lato server”.
Portale “Feedback per Windows Server”: menziona esplicitamente il requisito DoT/DoH. Indirizzo di riferimento: aka.ms/serverfeedback (testo, non link).

Che cosa scrivere (modello)

Titolo: Aggiungere a DNS Server il supporto nativo a DNS over TLS (DoT) e DNS over HTTPS (DoH)

Scenario: In azienda adottiamo Windows Server DNS integrato con AD per le zone interne.
Necessitiamo di proteggere il traffico client⇄resolver utilizzando DoT/DoH per:

- conformità (policy Zero Trust)
- prevenire ispezioni/alterazioni del traffico DNS
- permettere connessioni sicure da reti non fidate (roaming, BYOD)

Impatto: ~12.000 endpoint; attuale workaround con proxy introduce complessità e costi.
Richiesta: implementare DoT (TCP/853) e DoH (HTTPS /dns-query con HTTP/2/3), gestione certificati
(TLS 1.2/1.3), logging e metriche, opzioni per mTLS e SNI.

Benefici: riduzione rischio, semplificazione architetturale, allineamento alle best practice di settore.

Coinvolgi più stakeholder

Coincorda il feedback con Security, Networking e Compliance: un maggiore volume di richieste, ben motivate e con numeri (endpoint, siti, casi d’uso), aumenta la probabilità che la funzionalità entri in roadmap.

Soluzioni alternative nell’attesa

Senza supporto nativo, esistono due macro-strade:

Terminare DoT/DoH a monte con un reverse‑proxy o “terminator” che traduca DoT/DoH in DNS classico verso il tuo Windows DNS.
Usare un resolver di terze parti (ricorsivo/autorevole) che supporti direttamente DoT/DoH e integri Active Directory tramite conditional/stub forwarding.

Pattern A — Reverse‑proxy / terminator DoT/DoH davanti a Windows DNS

Il proxy ascolta su 853/TCP (DoT) e/o 443/TCP (DoH), gestisce TLS e parla con Windows DNS su 53/UDP o 53/TCP. Architettura tipica:

Client DoT/DoH ──TLS──&gt; Terminator (DoT/DoH) ──DNS──&gt; Windows DNS Server (UDP/TCP 53)

Componenti possibili:

dnsdist (PowerDNS): terminazione nativa DoT e DoH; eccellente per ambienti enterprise; instrada verso backend 53/UDP/TCP.
CoreDNS: terminazione DoT nativa; per DoH si può affiancare un componente specifico o usare un build con plugin appropriato.
AdGuard Home: semplice da configurare, supporta DoT/DoH in ingresso; adatto a SMB/lab, valutare attentamente funzionalità extra (filtri) in contesti enterprise.
stunnel o NGINX (stream): validi per DoT (TLS su TCP), con inoltro verso 53/TCP del DNS di Windows. Per DoH serve un backend che parli il protocollo DoH.

Esempio con dnsdist (DoT + DoH)

In uno appliance Linux/VM o container:

# /etc/dnsdist/dnsdist.conf
-- Server DNS di backend (Windows DNS)
newServer({address="192.168.10.10:53", name="win-dns-1"})
newServer({address="192.168.10.11:53", name="win-dns-2"})

-- ACL: consenti solo reti aziendali
setACL({"10.0.0.0/8", "192.168.0.0/16", "172.16.0.0/12"})

-- Listener DoT (TLS su 853)
addTLSLocal("0.0.0.0:853", "/etc/pki/dns/fullchain.pem", "/etc/pki/dns/privkey.pem")

-- Listener DoH (HTTPS su 443, percorso /dns-query)
addDOHLocal("0.0.0.0:443", "/etc/pki/dns/fullchain.pem", "/etc/pki/dns/privkey.pem", "/dns-query")

-- Politica di forwarding
addAction(AllRule(), PoolAction("default"))

Note operative:

Configura i backend Windows per accettare anche TCP/53 (oltre a UDP), perché DoT, una volta terminato, si traduce in traffico TCP.
Imposta keep‑alive/session resumption per ridurre l’overhead TLS.
Separa certificati per ambienti lab e prod; usa nomi DNS dedicati (es. dns.example.com).

Esempio con CoreDNS (terminazione DoT → forwarding a Windows)

# /etc/coredns/Corefile
tls://0.0.0.0:853 {
    tls /etc/pki/dns/fullchain.pem /etc/pki/dns/privkey.pem
    cache 120
    errors
    log
    forward . 192.168.10.10:53 192.168.10.11:53 {
        prefer_udp
    }
    health
}

Esempio DoT minimale con NGINX (stream)

Per chi desidera solo DoT (non DoH) con terminazione TLS molto semplice:

stream {
  upstream windnstcp {
    server 192.168.10.10:53;
    server 192.168.10.11:53;
  }
  server {
    listen 853 ssl;
    ssl_certificate     /etc/pki/dns/fullchain.pem;
    sslcertificatekey /etc/pki/dns/privkey.pem;
    proxypass windns_tcp;
  }
}

Questo approccio inoltra il traffico DNS “decrittato” in TCP/53 ai server Windows. Ricorda che non gestisce DoH.

Pattern B — Resolver di terze parti con integrazione AD

Al posto del DNS di Windows in prima linea, puoi adottare un resolver con DoT/DoH nativi e integrare AD tramite conditional forwarding o stub zones. Esempi:

Unbound: DoT lato server; per DoH può essere affiancato a un terminator HTTP (es. dnsdist) davanti.
Knot Resolver o PowerDNS Recursor: eccellenti performance e configurabilità; gestione DoT/DoH tramite componenti nativi o dnsdist.
BIND 9: supporto DoT lato server nelle versioni recenti; per DoH tipicamente si usa dnsdist come terminator.

Esempio integrazione con Unbound

# /etc/unbound/unbound.conf (estratto)
server:
  interface: 0.0.0.0
  interface: ::0
  tls-port: 853
  tls-service-key: "/etc/pki/dns/privkey.pem"
  tls-service-pem: "/etc/pki/dns/fullchain.pem"
  do-tcp: yes
  do-udp: yes
  cache-min-ttl: 60
  cache-max-ttl: 86400

Le query per il dominio AD restano interne ai DNS Windows

forward-zone:
name: "corp.local."
forward-addr: 192.168.10.10
forward-addr: 192.168.10.11

Pattern C — Servizi gestiti / cloud

Per workload ibridi o cloud‑native considera servizi gestiti (es. resolver privati nel cloud) ed eventuale terminazione TLS con componenti PaaS/IaaS. Per esempio, un Private DNS Resolver in cloud per la ricorsione e un proxy TLS/HTTP per DoT/DoH nella VNet/VPC, con peering verso la rete on‑prem. Valuta attentamente latenza, costi di egress e affidabilità WAN.

Considerazioni di sicurezza e performance

Overhead: DoH introduce più CPU rispetto a DoT per via di HTTP/2/3; investire in caching, pipelining e session resumption riduce la latenza.
Certificati TLS: usa SAN corretti (FQDN usati dai client), catena completa e automatizza i rinnovi (ACME). In ambienti interni, una CA aziendale semplifica la fiducia sui client.
mTLS: opzionale per contesti ad alta sicurezza; richiede gestione client certificate e CRL/OCSP.
DNSSEC ≠ DoH/DoT: DNSSEC garantisce autenticità/integrità dei dati DNS; DoH/DoT garantiscono confidenzialità del canale. Sono complementari.
Logging: abilita log strutturati sul terminator (query, codice di risposta, SNI, JA3 opzionale), con retention conforme alle policy privacy.

Certificati: come organizzarli bene

Opzione	Pro	Contro	Quando sceglierla
CA interna (AD CS)	Controllo totale, automazione con GPO	Non trusted esternamente	Ambienti interni, device gestiti
CA pubblica	Trust immediato	Costo/gestione validazioni	Accesso da device non gestiti
ACME (win‑acme / Certify)	Rinnovo automatico	Richiede connettività/record DNS	Ambienti dinamici, multi‑sito

Firewall e networking: porte da aprire

Direzione	Porta/Protocollo	Componente	Note
Inbound	853/TCP	Terminatore DoT	Obbligatorio per DoT
Inbound	443/TCP	Terminatore DoH	Obbligatorio per DoH
East‑West	53/UDP, 53/TCP	Terminatore ⇄ Windows DNS	Assicurare low latency intra‑LAN
Outbound	80/443/TCP	Terminatore	Solo se usi ACME/telemetria

Compatibilità lato client Windows

Windows 10/11 supportano nativamente DoH come client. Per usare un tuo endpoint DoH:

# Esempio PowerShell su Windows 11
Add-DnsClientDohServerAddress `
  -ServerAddress 203.0.113.10 `
  -DohTemplate "https://dns.example.com/dns-query" `
  -AllowFallbackToUdp $false -AutoUpgrade $true

Punta l'interfaccia al resolver

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 203.0.113.10

In ambienti gestiti, configura via GPO: Computer Configuration → Administrative Templates → Network → DNS Client → Enable DNS over HTTPS e definisci l’indirizzo del server DoH con il relativo template /dns-query. Windows non offre un client DoT nativo per l’endpoint, ma molti sistemi (Android, alcune distro Linux) sì: utile se progetti di esporre anche DoT.

Monitoraggio e capacità

Proxy/terminator: esporta metriche (Prometheus/JSON) su QPS, latenza P50/P90/P99, error rate, TLS handshakes, session reuse. Allerta su saturazione CPU e spike di 5xx/ServFail.
Windows DNS: monitora contatori di Performance Monitor su “DNS Server” (Query Received, TCP/UDP Packets, Recursion Time), oltre a CPU e memoria. Abilita il log analitico DNS per indagare anomalie.
Test di carico: usa dnsperf per traffico DNS classico e generatori specifici per DoH/DoT (es. k6 con HTTP/2 o tool dedicati) per dimensionare correttamente.

Hardening e privacy

Restrizione perimetro: limita DoT/DoH ai segmenti dove serve (ACL sul terminatore) per evitare esfiltrazioni DNS non controllate.
Policy di logging: conserva solo i campi indispensabili e applica pseudonimizzazione ove possibile.
Validazione certificati: imposta SNI e verifica hostname lato client; rimuovi cipher suite deboli; preferisci TLS 1.3 dove disponibile.
Fail‑safe: decidere se consentire fallback a DNS in chiaro in caso di guasto (spesso no per requisiti di sicurezza) e prevedere alta affidabilità del terminatore.

Integrazione con Active Directory: tre modelli

Terminatore davanti a Windows DNS (modello più semplice): tutte le query, incluse quelle per corp.local, arrivano al terminatore che inoltra ai Windows DNS interni.
Resolver esterno + conditional forwarding: il resolver (Unbound/Knot/PowerDNS) svolge la ricorsione per Internet; per le zone AD inoltra ai DNS Windows.
Mixed: DoH pubblico per device esterni/roaming, DoT interno per device on‑prem; entrambi terminano verso Windows DNS per le zone interne e verso upstream per Internet.

Qualunque modello tu scelga, assicurati che le zone AD‑integrated restino autorevoli sui Domain Controller e che i terminator non “cachino” in modo aggressivo record dinamici interni con TTL bassi (DHCP/DNS).

Checklist di implementazione rapida

Seleziona il modello (terminatore, resolver terze parti, cloud).
Assegna un FQDN (es. dns.example.com) e prepara il certificato (CA interna o pubblica).
Distribuisci il terminatore (dnsdist/CoreDNS/AdGuard Home): ascolto su 853 e/o 443; backend verso i tuoi Windows DNS.
Configura firewall e segmentazione (solo reti fidate).
Abilita metriche e log: verifica handshakes TLS, rate di errore, latenza.
Configura i client (GPO DoH per Windows; profili MDM per mobile).
Failover: almeno due istanze di terminatore in HA (IP diversi, Anycast o bilanciatore L4).
Piano di rinnovo certificati (ACME/AD CS) e runbook di emergenza.

Troubleshooting rapido

DoT: prova kdig @dns.example.com +tls +tls-host=dns.example.com -p 853 example.com A. Se fallisce handshake, verifica certificato e porte.
DoH: verifica HTTP/2 e header application/dns-message con un client DoH o curl verso /dns-query (solo per test).
Loop DNS: controlla che il terminatore non punti a se stesso; definisci chiaramente i backend.
Prestazioni: osserva session reuse TLS e dimensiona l’keep‑alive.

Domande frequenti

Posso attivare DoH/DoT direttamente nel ruolo DNS di Windows Server?
No, non oggi. Servono componenti esterni o resolver terzi.

Posso usare solo DoT o solo DoH?
Sì. Molti ambienti interni preferiscono DoT per semplicità; DoH è comodo per endpoint fuori dal perimetro (roaming) dove 443 è sempre aperta.

Serve un certificato pubblico?
Non necessariamente: se tutti i client sono gestiti puoi distribuire una CA interna. Se prevedi device non gestiti, un certificato pubblico semplifica molto.

Come spingo Microsoft a implementare la funzione?
Invia feedback strutturato tramite Feedback Hub (Server → Networking) e il portale dedicato, coinvolgendo più stakeholder e quantificando l’impatto.

Take‑away

Stato attuale: Windows Server non supporta DoH/DoT come server nel ruolo DNS. Azioni: invia feedback formale sui canali ufficiali per spingere la roadmap. Nel frattempo: implementa un terminatore DoT/DoH o adotta un resolver alternativo integrato con AD. Con una corretta gestione di certificati, firewall, metriche e GPO, puoi ottenere da subito cifratura, affidabilità e controlli di sicurezza senza attendere un aggiornamento del prodotto.