DNSSEC SERVFAIL con forwarder su Windows Server 2019/2022: cause, fix e best practice

Se gestisci DNS di Windows Server 2019/2022 con DNSSEC attivo e forwarder pubblici, potresti ottenere SERVFAIL su alcuni nomi (es. xwkm5qky.r.eu‑west‑1.awstrack.me). In questa guida spiego perché accade, come verificarlo in modo riproducibile e quali soluzioni applicare senza sorprese.

Indice

Panoramica del problema

Un resolver Windows DNS configurato con convalida DNSSEC e uno o più forwarder esterni (ad esempio 9.9.9.9, 8.8.8.8, 1.1.1.1) può restituire SERVFAIL quando tenta di risolvere alcuni nomi FQDN. Dalle tracce emerge che il server:

invia query DS per sottodomini profondi (p.es. xwkm5qky.r.eu‑west‑1.awstrack.me e r.eu‑west‑1.awstrack.me),
invia query DS per domini non correlati come amazonaws.com e il TLD com,
non invia le query DS verso awstrack.me e il TLD me.

Quando il forwarder risponde — legittimamente — con record NSEC3 che provano l’assenza di DS per amazonaws.com, il resolver Windows, non avendo ricevuto prove d’insicurezza per awstrack.me/me, deduce (in modo errato) che awstrack.me sia una zona firmata ma “rotta” e termina con SERVFAIL. Se si rimuovono i forwarder e si usa la ricorsione completa (root hints), il server effettua correttamente anche le query DS verso me e awstrack.me, ottiene prove di insicurezza (NSEC3 “zona non firmata”) e la risoluzione ha esito positivo.

Contesto tecnico: perché succede

Per comprendere il comportamento, è utile ricordare come funziona la catena di fiducia DNSSEC:

Il resolver parte dalla radice (.
Segue le deleghe tramite record DS e DNSKEY fino alla zona autoritativa del nome cercato.
Se la zona è non firmata, deve ricevere una prova d’insicurezza (tipicamente NSEC/NSEC3) per accettare la risposta come valida senza firma.

Su Windows DNS, quando è configurato un trust‑anchor radice locale (di default quando si abilita la validazione) il server si aspetta sempre di poter costruire una catena DNSSEC completa o, in alternativa, di ricevere prove d’insicurezza per ogni tratto della delega. Con i forwarder, però, il resolver non sempre ottiene tutte le risposte intermedie (record DS e NSEC3 per ogni livello). Se manca la prova d’insicurezza per il dominio giusto (awstrack.me e/o me nel caso in esame) Windows tende a memorizzare lo stato BOGUS per quel nome, e a quel punto ogni successiva risoluzione termina in SERVFAIL finché la cache non scade o viene svuotata.

Il ruolo dei forwarder

Un forwarder fa ricorsione per conto del nostro server e, a seconda delle ottimizzazioni, può non inoltrare tutte le risposte DNSSEC intermedie. Windows DNS, non ricevendo la prova d’insicurezza esplicita per il dominio di interesse, interpreta la situazione come un’anomalia della firma. Questa logica è coerente con i principi DNSSEC (meglio fallire che accettare dati potenzialmente alterati), ma nella pratica genera falsi positivi su domini pubblici non firmati o su catene di delega complesse (CDN, tracciamento email, ecc.).

Sintomi e segnali da riconoscere

Client che ricevono SERVFAIL o errori “server failure”.
La risoluzione dello stesso nome funziona usando direttamente i resolver pubblici (es. 9.9.9.9) o dopo aver disattivato i forwarder e riabilitato i root hints.
Eventi DNS‑SERVER relativi a fallimenti di convalida (esempi tipici: 454/455) in Registri di Windows → Applicazioni e servizi → DNS Server.
Nella traccia di rete, query DS verso sottodomini e domini non pertinenti (es. amazonaws.com) ma assenza di query DS per awstrack.me e me.

Come verificare rapidamente

Svuota la cache del resolver per evitare effetti di stato: Clear-DnsServerCache -Force
Risolvi con convalida attiva dal server stesso: Resolve-DnsName -Name xwkm5qky.r.eu-west-1.awstrack.me -Type A -DnssecOk -Server 127.0.0.1 -Detailed
Confronta il comportamento con e senza forwarder:
- Con forwarder → spesso SERVFAIL.
- Con root hints → risposta valida e flag “insecure” correttamente attestato.
Sniffa il traffico DNS (Wireshark) filtrando DS/NSEC3: udp.port == 53 and (dns.qry.type == 43 or dns.resp.type == 50) Nota: 43 = DS, 50 = NSEC3.

Analisi approfondita: catena di delega e prove d’insicurezza

Nel caso reale analizzato (*.awstrack.me), la catena corretta dovrebbe comportare — tra le altre — le seguenti verifiche:

Radice (.) → me: complesso di DS e DNSKEY per attestare la delega al TLD me.
me → awstrack.me: se awstrack.me è non firmata, il resolver deve ricevere NSEC/NSEC3 che dimostrino l’assenza di DS per quella etichetta (prova d’insicurezza).
Host finale: la risposta A/AAAA/CNAME dovrà essere accettata come insecure, non firmata ma lecita.

Con i forwarder, la prova d’insicurezza per awstrack.me può non pervenire al nostro server, mentre arrivano invece risposte per altri domini (es. amazonaws.com) che nulla hanno a che vedere con la delega di awstrack.me. In assenza di NSEC/NSEC3 pertinenti, Windows DNS “gioca in difesa”: marca il dominio come BOGUS e rifiuta la risposta.

Soluzioni e work‑around (con pro e contro)

Approccio	Vantaggi	Svantaggi	Comandi/Note
1. Rimuovere il trust‑anchor radice	Risoluzione immediata; mantiene i forwarder.	DNSSEC disattivato globalmente → perdita di validazione end‑to‑end.	`# Rimuove l'anchor radice locale (.) Get-DnsServerTrustAnchor -Name . \| Remove-DnsServerTrustAnchor -Force` Rollback: `# Reimporta l'anchor radice Add-DnsServerTrustAnchor -Root`
2. Disattivare i forwarder e usare i root hints	Mantiene DNSSEC attivo; niente `SERVFAIL` per domini non firmati.	Più traffico DNS in uscita; tempi di risoluzione leggermente più lunghi; possibile revisione di policy aziendali.	`# Elimina i forwarder correnti (Get-DnsServerForwarder).IPAddress \| ForEach-Object { Remove-DnsServerForwarder -IPAddress $_ -Force } Assicurati che i root hints siano presenti Get-DnsServerRootHint (opzionale) Aggiungi un root hint mancante Add-DnsServerRootHint -NameServer a.root-servers.net -IPAddress 198.41.0.4` </td> </tr> <tr> <td><strong>3. Condizionale / stub zone per domini interni non firmati</strong></td> <td>Isola domini intranet non firmati evitando la convalida perimetrale.</td> <td>Amministrazione extra; non risolve i casi di domini pubblici non firmati dietro CDN/tracking.</td> <td> <p>Creare zone di tipo <em>Forward Lookup</em> “condizionale” o <em>Stub</em> per i namespace interni (es. <code>corp.local</code>), puntando ai DNS autoritativi interni.</p> </td> </tr> <tr> <td><strong>4. Aggiornare Windows e monitorare patch future</strong></td> <td>Possibile fix definitivo se Microsoft rilascia un aggiornamento.</td> <td>Alla data di pubblicazione (ottobre 2025) non risulta una KB che corregga specificamente questo comportamento; serve testing/regressione.</td> <td> <pre><code># Inventaria patch installate Get-HotFix \| Sort-Object InstalledOn -Descending \| Select-Object -First 20 Pianifica un test periodico post-aggiornamento Resolve-DnsName -Name xwkm5qky.r.eu-west-1.awstrack.me -DnssecOk -Server 127.0.0.1

Raccomandazioni operative

Valuta la priorità di DNSSEC: se la validazione non è requisito di conformità, l’approccio 1 è il più rapido e coerente con SLA stretti.
Se DNSSEC è obbligatorio (compliance, zero trust, supply‑chain hardening):
- preferisci l’approccio 2 (ricorsione completa con root hints),
- oppure mantieni i forwarder ma instrada i client direttamente verso resolver DNSSEC‑capable esterni, accettando la perdita di validazione locale lato server finché non arriva una correzione.
Documenta il change: la rimozione del trust‑anchor va registrata in un risk log; definisci controlli periodici su Get-DnsServerTrustAnchor e sugli eventi DNS‑SERVER 454/455.
Revisione nel tempo: monitora gli aggiornamenti cumulativi di Windows Server e le note di rilascio DNS; in caso di fix reimporta l’anchor radice: Add-DnsServerTrustAnchor -Root Clear-DnsServerCache -Force e verifica con: Resolve-DnsName -Name xwkm5qky.r.eu-west-1.awstrack.me -DnssecOk -Server 127.0.0.1 -Detailed

Procedura guidata: diagnosi completa passo‑passo

1) Cattura e lettura della traccia DNS

Avvia Wireshark sul DNS.
Filtro di cattura: udp port 53. Filtro di visualizzazione: dns && (dns.qry.type == 43 || dns.resp.type == 50).
Risolvi il nome problematico più volte per popolare la cache.
Controlla se mancano query DS per awstrack.me e me e se compaiono NSEC3 relativi a domini non attinenti.

2) Verifiche lato Windows DNS

Forwarder attivi: Get-DnsServerForwarder
Trust anchor presenti: Get-DnsServerTrustAnchor
Cache pulita e nuovo test: Clear-DnsServerCache -Force Resolve-DnsName -Name xwkm5qky.r.eu-west-1.awstrack.me -DnssecOk -Server 127.0.0.1
Event Viewer (DNS Server): cerca voci di validation failure correlate all’orario del test (es. 454/455).

3) Confronto tra percorsi di risoluzione

Effettua due prove identiche a distanza ravvicinata:

# Scenario A: con forwarder
Resolve-DnsName -Name xwkm5qky.r.eu-west-1.awstrack.me -DnssecOk -Server 127.0.0.1

Scenario B: senza forwarder, solo root hints

(Get-DnsServerForwarder).IPAddress | % { Remove-DnsServerForwarder -IPAddress $_ -Force }
Clear-DnsServerCache -Force
Resolve-DnsName -Name xwkm5qky.r.eu-west-1.awstrack.me -DnssecOk -Server 127.0.0.1

Nel B vedrai tipicamente una risposta insecure accettata e nessun SERVFAIL.

Domande frequenti

Questo problema dipende dal forwarder (Quad9, Google, Cloudflare)?

No. È legato alla logica di prova d’insicurezza del resolver Windows quando si appoggia a forwarder. Cambiare servizio spesso non modifica l’esito.

Perché succede solo con alcuni domini (es. `*.awstrack.me`)?

Perché la struttura a più livelli (tracking, CDN, deleghe specifiche di regione) e l’assenza di firma su parte della catena richiedono NSEC/NSEC3 pertinenti per dimostrare l’insicurezza. Se la prova non arriva al nostro server, la validazione fallisce.

Esistono “negative trust anchor” su Windows DNS?

Non in forma nativa amministrabile come su alcuni resolver pubblici. Le opzioni pratiche lato Windows sono quelle elencate nei work‑around (rimuovere anchor, usare root hints, isolare domini interni).

Posso mitigare senza rinunciare ai forwarder?

In alcuni ambienti aiuta ridurre la dipendenza dai forwarder per i domini pubblici problematici (creando conditional forwarding verso resolver autorevoli “vicini” o affidabili) e/o far risolvere direttamente i client verso un resolver DNSSEC‑capable. Tuttavia non elimina il difetto di fondo.

Checklist di decisione

Disponi di requisiti formali per DNSSEC? → Sì: preferisci ricorsione con root hints. No: valuta rimozione dell’anchor radice.
Hai policy che impongono forwarder centralizzati? → Se Sì, prepara un’eccezione documentata oppure una soluzione ibrida (client verso resolver esterni, server senza anchor).
Hai osservabilità e logging? → Abilita auditing DNS, pianifica test periodici con Resolve-DnsName -DnssecOk.

Implicazioni di sicurezza

Disattivare la validazione (rimozione del trust‑anchor) elimina la protezione contro risposte manomesse o downgrade. L’uso dei root hints preserva la validazione end‑to‑end, ma aumenta la superficie di traffico verso Internet e richiede cura nel rate limiting e nel monitoraggio. In contesti regolamentati (PA, finance, healthcare) è generalmente preferibile mantenere DNSSEC attivo, documentando il rischio residuo e le motivazioni architetturali.

Operatività e manutenzione continuativa

Verifiche post‑change: esegui test su un campione di domini firmati (dnssec-failed.org non deve risolversi) e non firmati (es. example.com deve risolversi come insecure).
Hardening: limita le query ricorsive ai soli host di rete interna; abilita rate‑limit (se presente sull’appliance front‑end) e sorveglia il QPS verso i root server.
Incident playbook: in caso di nuove segnalazioni SERVFAIL, applica rapidamente il fallback temporaneo (rimozione anchor o bypass forwarder) e programma la diagnosi con traccia.

Caso d’uso riproducibile in lab

Allestisci un Windows Server 2019/2022 pulito, aggiungi il ruolo DNS.
Abilita la convalida DNSSEC e importa il trust‑anchor radice: Add-DnsServerTrustAnchor -Root
Imposta forwarder pubblici (es. 9.9.9.9, 8.8.8.8, 1.1.1.1).
Svuota cache e prova: Clear-DnsServerCache -Force Resolve-DnsName -Name xwkm5qky.r.eu-west-1.awstrack.me -DnssecOk -Server 127.0.0.1 Atteso: SERVFAIL.
Rimuovi i forwarder, usa root hints, svuota cache e riprova. Atteso: risposta insecure valida.

Appendice: comandi utili

# Elenco/gestione forwarder
Get-DnsServerForwarder
Remove-DnsServerForwarder -IPAddress 9.9.9.9 -Force

Root hints

Get-DnsServerRootHint

Add-DnsServerRootHint -NameServer a.root-servers.net -IPAddress 198.41.0.4

Trust anchor

Get-DnsServerTrustAnchor
Add-DnsServerTrustAnchor -Root
Get-DnsServerTrustAnchor -Name . | Remove-DnsServerTrustAnchor -Force

Cache e test

Clear-DnsServerCache -Force
Resolve-DnsName -Name xwkm5qky.r.eu-west-1.awstrack.me -DnssecOk -Server 127.0.0.1 -Detailed

Conclusioni

Il comportamento osservato nasce dall’interazione tra validazione DNSSEC e uso di forwarder: quando manca la prova d’insicurezza per il dominio corretto, Windows DNS classifica il nome come BOGUS e restituisce SERVFAIL. La soluzione più pulita per mantenere DNSSEC è evitare i forwarder e usare la ricorsione completa tramite root hints. In alternativa, si può rimuovere temporaneamente il trust‑anchor radice accettando la rinuncia alla validazione. Finché non verrà rilasciata una correzione specifica, la scelta è tra sicurezza (DNSSEC) e funzionalità (forwarder), con pro e contro qui riportati e procedure di rollback chiare.

Nota finale: il problema non dipende dal provider di forwarder scelto; nasce dalla gestione delle prove d’insicurezza lungo la catena di delega quando il server Windows opera in modalità “validazione con trust‑anchor locale”. Tenere monitorati eventi DNS e aggiornamenti cumulativi aiuta a rientrare rapidamente in caso di regressioni.