In ambienti isolati da Internet, Windows Server 2022 può generare numerosi Event ID 1014 (DNS) durante tentativi di contattare domini Microsoft. Questa guida operativa mostra come eliminare o ridurre tali eventi tramite GPO, WSUS/KMS interni, regole di firewall, sinkhole DNS e audit mirati.
Panoramica del problema
Evento coinvolto: Microsoft‑Windows‑DNS Client Events → ID 1014 — “Name resolution for the name … timed out”.
Scenario tipico: server Windows Server 2022 senza accesso a Internet (o con DNS interni che non inoltrano verso l’esterno) provano a risolvere FQDN quali login.live.com, microsoft.com, windows.net, microsoftonline.com, office.com, ctldl.windowsupdate.com, time.windows.com e altri endpoint di telemetria, attivazione, aggiornamento e convalida certificati. La richiesta fallisce con timeout e viene registrato l’evento 1014.
Obiettivo: impedire o minimizzare i tentativi di connessione verso Internet e, in parallelo, pulire i log senza compromettere patching, sicurezza e licensing.
Principi guida
- Centralizzare i blocchi (DNS/Firewall) per evitare configurazioni manuali su ogni host.
- Selezionare con cura cosa disabilitare: aggiornamenti, firme antimalware e attivazione devono continuare a funzionare tramite infrastrutture interne (WSUS, KMS/AVMA, repository di firme).
- Preferire una risposta DNS immediata (NXDOMAIN o sinkhole locale) al posto del timeout: riduce drasticamente gli Event ID 1014.
- Verificare gli effetti con strumenti di monitoraggio (Event Viewer, packet capture) prima e dopo ogni modifica.
Soluzioni operative a colpo d’occhio
| Area d’intervento | Azione pratica | Note / eventuali impatti | Comandi / Policy utili |
|---|---|---|---|
| Servizi Windows | Disabilitare componenti che chiamano Microsoft quando non necessari. Esempi: Windows Update (se non c’è WSUS), Telemetry/Diagnostic Data, Delivery Optimization, Windows Error Reporting. Per licensing, usare KMS interno o AVMA. | Riduce drasticamente richieste verso domini MS. Verificare dipendenze (patching, protezioni, licensing). | services.msc → disabilitare DiagTrack, valutare DoSvc, WerSvcGPO Telemetry: Allow Telemetry = 0 Attivazione: KMS/AVMA all’interno. |
| Firewall locale o di rete | Regole in uscita per bloccare IP/ASN Microsoft (lato perimeter o host). Meglio usare firewall di bordo con categorie “Microsoft” o liste IP aggiornate. | Metodo centralizzato; valutare l’impatto su servizi legittimi futuri. | New-NetFirewallRule -DisplayName "Block-Microsoft-Egress" -Direction Outbound -Action Block -RemoteAddress <lista IP/ASN> |
| File hosts (workaround mirato) | Aggiungere 127.0.0.1 login.live.com, ecc. solo per test o eccezioni. | Veloce ma non scalabile; evitare in ambienti grandi. | notepad C:\Windows\System32\drivers\etc\hosts |
| DNS interno / sinkhole | Restituire NXDOMAIN o instradare verso una “black‑hole” creando zone interne autorevoli per FQDN/domìni mirati (es. zona login.live.com o live.com con record vuoti). | Elegante e centralizzato; elimina i 1014 perché il client riceve una risposta immediata (no timeout). | PowerShell DNS: Add-DnsServerPrimaryZone -Name "login.live.com" -DynamicUpdate None |
| Attività pianificate e servizi terzi | Audit con Task Scheduler e servizi; disabilitare job che contattano Internet (es. Office Click‑to‑Run, updater di terze parti). | Elimina chiamate residue non coperte da GPO/DNS/Firewall. | Get-ScheduledTask / Disable-ScheduledTask; Get-Service / Set-Service |
| Monitoraggio e validazione | Packet capture (Wireshark/pktmon), Event Viewer filtrato su 1014; metriche prima/dopo le modifiche. | Fondamentale per capire l’origine esatta e validare la riduzione eventi. | Get-WinEvent -LogName "Microsoft-Windows-DNS Client Events/Operational" -FilterXPath '*[System[(EventID=1014)]]' |
Percorso consigliato passo‑passo
Raccogliere evidenze e dominî principali
Prima di toccare configurazioni, estrarre i FQDN più ricorrenti nei 1014:
# Top FQDN 1014 delle ultime 48 ore
$ev = Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-DNS Client Events/Operational'; Id=1014; StartTime=(Get-Date).AddHours(-48)}
$names = $ev | ForEach-Object { if ($ -and $.Message) { ($_.Message -split 'name\s+')[1] -split '\s' | Select-Object -First 1 } }
$names | Group-Object | Sort-Object Count -Descending | Select-Object Name,Count | Format-Table -Auto
Annotare i dominî (es. .microsoft.com, .windowsupdate.com, .windows.net, .microsoftonline.com, *.office.com, login.live.com, ctldl.windowsupdate.com, time.windows.com).
Stabilizzare Windows Update tramite WSUS
Se i server devono aggiornarsi in assenza di Internet, usare un WSUS interno. Nella GPO dei server, impostare:
- Specify intranet Microsoft update service location → Enabled e URL WSUS (http/https).
- Do not connect to any Windows Update Internet locations → Enabled.
- Configure Automatic Updates → pianificazione adatta alla manutenzione.
- Delivery Optimization → Download Mode = Bypass.
Queste impostazioni impediscono chiamate a .windowsupdate.com, .microsoft.com e riducono 1014 correlati all’update.
Ridurre Telemetry e comunicazioni non essenziali
Per Windows Server 2022, applicare le seguenti policy GPO (Computer Configuration → Administrative Templates):
| Ambito | Policy | Valore |
|---|---|---|
| Windows Components → Data Collection and Preview Builds | Allow Telemetry | Disabled (0) |
| Windows Components → Delivery Optimization | Download Mode | Bypass |
| System → Internet Communication Management → Internet Communication settings | Turn off Windows Error Reporting | Enabled |
| Windows Components → Windows Defender Antivirus → MAPS | Join Microsoft MAPS, Cloud-delivered protection, Automatic sample submission | Disabled (se l’ambiente è chiuso) |
Valutare inoltre la disabilitazione dei seguenti servizi dove appropriato:
# Telemetry (DiagTrack), Delivery Optimization, Windows Error Reporting
Set-Service diagtrack -StartupType Disabled -ErrorAction SilentlyContinue
Set-Service dosvc -StartupType Disabled -ErrorAction SilentlyContinue
Set-Service wersvc -StartupType Disabled -ErrorAction SilentlyContinue
Nota: in ambienti con Defender attivo e aggiornato via WSUS/SMB, disabilitare solo le componenti cloud; mantenere motore e pianificazioni di scansione.
Attivazione: KMS o AVMA
Per evitare chiamate all’attivazione online (activation.sls.microsoft.com e simili), configurare:
- KMS interno: registrare la chiave KMS sul KMS host (
slmgr /ipk <KMS‑HOST‑KEY>;slmgr /ato) e puntare i client al KMS (slmgr /skms kms.contoso.local:1688). - AVMA per VM su Hyper‑V: usare la chiave AVMA corretta per l’edizione della VM (
slmgr /ipk <AVMA‑KEY>); l’host Datacenter autentica l’attivazione all’interno dell’host.
NTP interno
Se vedi richieste a time.windows.com, definisci un server NTP aziendale e imposta w32time sui server:
w32tm /config /manualpeerlist:"ntp1.contoso.local ntp2.contoso.local" /syncfromflags:manual /update
net stop w32time & net start w32time
w32tm /resync /force
Root Certificate Update in ambiente chiuso
La “Automatic Root Certificates Update” tenta di scaricare root/CRL da Internet. In ambienti chiusi:
- GPO: Turn off Automatic Root Certificates Update → Enabled.
- Gestire i Trusted Root Certification Authorities via GPO aziendale.
- Valutare con attenzione le OCSP/CRL checks: disabilitarle globalmente riduce sicurezza; meglio pubblicare CRL interne per i certificati aziendali.
DNS sinkhole: il metodo più pulito contro i 1014
Creare zone DNS autorevoli per i nomi che vuoi “assorbire” evita il timeout: il resolver ottiene una risposta immediata (NXDOMAIN o IP sinkhole) e non registra l’evento 1014. Due strategie:
- Zona per FQDN specifico (consigliata): es.
login.live.com,settings-win.data.microsoft.com,v10.events.data.microsoft.com. La zona non contiene record A/CNAME (o include un recordAverso un IP sinkhole interno). - Zona per dominio base (più invasiva): es.
live.com,windows.net,microsoftonline.com. Utile quando molteplici sottodomini generano traffico, ma richiede attenzione perché può interrompere funzionalità collaterali.
Esempi con PowerShell (DNS Server module):
# Zona mirata per un solo FQDN: risponde NXDOMAIN a tutto sotto login.live.com
Add-DnsServerPrimaryZone -Name "login.live.com" -DynamicUpdate None
Zona per dominio base con wildcard che punta a sinkhole (opzionale)
Add-DnsServerPrimaryZone -Name "windows.net" -DynamicUpdate None
Add-DnsServerResourceRecordA -ZoneName "windows.net" -Name "*" -IPv4Address "10.254.254.254" -TimeToLive 01:00:00
(Facoltativo) record @ per l'apice della zona se vuoi una risposta esplicita
Add-DnsServerResourceRecordA -ZoneName "windows.net" -Name "@" -IPv4Address "10.254.254.254" -TimeToLive 01:00:00 Consiglio: preferisci NXDOMAIN (nessun record nella zona) se vuoi semplicemente eliminare i timeout. Se usi un IP sinkhole, registra quell’IP sul firewall con una regola “black‑hole” (DROP) per evitare tentativi TCP.
Firewall: egress filtering sensato
Il firewall di Windows non gestisce wildcard FQDN in modo nativo per le regole basate su “Remote Address”; per bloccare nomi, affidati a DNS sinkhole o a un proxy/firewall perimetrale in grado di filtrare per categoria/FQDN. Lato host, puoi comunque definire blocchi IP (utile per endpoint stabili come CDN o ASN noti):
# Esempio: blocco di IP/ASN raccolti dal monitoraggio
New-NetFirewallRule -DisplayName "Block-Egress-Microsoft" -Direction Outbound -Action Block `
-RemoteAddress 13.64.0.0/11,20.33.0.0/16,20.190.0.0/16,40.64.0.0/10 `
-Profile Any -Enabled True
Best practice: applica i blocchi IP al perimetro (firewall aziendale) dove puoi gestire liste dinamiche/ASN; usa il firewall host come cintura di sicurezza.
Attività pianificate e servizi di terze parti
Molte connessioni nascono da job e updater non evidenti. Esegui un audit e disabilita ciò che non serve:
# Elenco di attività note (CEIP/Compatibilità/Consolidator) e disabilitazione
Get-ScheduledTask | Where-Object {$_.TaskName -match 'CEIP|Customer|Consolidator|ProgramDataUpdater|Compatibility'} |
Disable-ScheduledTask -ErrorAction SilentlyContinue
Office Click-to-Run (se non usato sui server)
Stop-Service ClickToRunSvc -ErrorAction SilentlyContinue
Set-Service ClickToRunSvc -StartupType Disabled Defender: firme offline o percorso interno
Se usi Microsoft Defender su server isolati:
- Configura un percorso interno (SMB/HTTP) per le definizioni (Define the order of sources for security intelligence updates → prima UNC interna).
- Usa WSUS per distribuire Security intelligence updates.
- Disabilita MAPS/Cloud‑delivered protection per evitare traffico verso
*.wdcp.microsoft.come simili.
Implementazioni dettagliate
GPO: impostazioni chiave (riassunto)
| Percorso | Policy | Impostazione | Effetto atteso |
|---|---|---|---|
| Windows Components → Windows Update | Specify intranet Microsoft update service location | Enabled (http(s)://wsus…) | Evita contatti con Windows Update pubblico |
| Windows Components → Windows Update | Do not connect to any Windows Update Internet locations | Enabled | Blocca fallback allo store/Windows Update |
| Windows Components → Data Collection and Preview Builds | Allow Telemetry | Disabled (0) | Stop raccolta diagnostica verso cloud |
| Windows Components → Delivery Optimization | Download Mode | Bypass | Evita connessioni DO esterne |
| System → Internet Communication Management | Turn off Windows Error Reporting | Enabled | Non invia report a Microsoft |
| Windows Defender AV → MAPS | Cloud-delivered protection / MAPS / Sample submission | Disabled | Nessun contatto cloud antimalware |
| System → Time Service | Global NTP settings | Peer interni | Niente chiamate a time.windows.com |
DNS sinkhole con GUI (DNS Manager)
- Apri DNS Manager sul server che ospita il DNS interno.
- Click destro su Forward Lookup Zones → New Zone….
- Scegli Primary Zone, non permettere aggiornamenti dinamici.
- Inserisci il nome della zona (es.
login.live.comoppurewindows.net). - Opzione A: non aggiungere record → qualsiasi query riceve una risposta autorevole “non esiste” (NXDOMAIN).
Opzione B: aggiungi un recordA *verso un IP sinkhole interno non routabile.
Pro‑tip: preferisci zone per FQDN mirati (ad es. settings-win.data.microsoft.com) quando vuoi bloccare un solo endpoint senza toccare l’intero dominio (data.microsoft.com).
Firewall host: esempi pratici
# Blocca tutto il traffico in uscita verso una lista IP (modulare)
$msRanges = @(
"13.64.0.0/11", # esempio Azure/Microsoft
"20.33.0.0/16",
"20.190.0.0/16",
"40.64.0.0/10"
)
New-NetFirewallRule -DisplayName "Block-Microsoft-Ranges" -Direction Outbound -Action Block `
-RemoteAddress ($msRanges -join ",") -Profile Any
(Facoltativo) loggare i drop
Set-NetFirewallProfile -All -LogBlocked True -LogFileName "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" Nota: gli intervalli IP cambiano. Mantenerli aggiornati a mano è oneroso; per questo i blocchi IP vanno preferibilmente delegati al firewall perimetrale o sostituiti da un sinkhole DNS.
Analisi e verifica
Event Viewer: apri Applications and Services Logs → Microsoft → Windows → DNS Client Events → Operational, filtra su 1014 e confronta i conteggi prima/dopo le modifiche.
# Conteggio 1014 per giorno negli ultimi 7 giorni
1..7 | ForEach-Object {
$start=(Get-Date).Date.AddDays(-$_)
$end =$start.AddDays(1)
$n = (Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-DNS Client Events/Operational'; Id=1014; StartTime=$start; EndTime=$end}).Count
[PSCustomObject]@{ Data=$start.ToString('yyyy-MM-dd'); Event1014=$n }
} | Format-Table -Auto
Packet capture: su server con restrizioni puoi usare pktmon (nativo) per intercettare DNS/HTTPS:
# Cattura base
pktmon start --capture --comp nics --pkt-size 0
Start-Sleep -Seconds 600
pktmon stop
pktmon etl2pcap pktmon.etl -o capture.pcapng
Domande frequenti
È meglio NXDOMAIN o un IP sinkhole (es. 10.254.254.254)?
NXDOMAIN è più “pulito”: il client riceve subito la risposta autorevole e smette di ritentare (niente timeout → niente Event 1014). L’IP sinkhole può essere utile se vuoi contare/vedere i tentativi lato firewall, ma richiede una regola DROP (o black‑hole) per evitare handshake e log aggiuntivi.
Posso creare una zona microsoft.com e stop?
È possibile, ma sconsigliato come prima mossa: potresti inibire risoluzioni necessarie (CRL/OCSP di certificati, scenari di attivazione, diagnostica). Meglio agire per FQDN critici o per domini secondari (windows.net, microsoftonline.com) dopo un’analisi dei log.
Il file hosts basta?
È un workaround utile per test o su pochi server. In produzione è oneroso e fragile: nessuna visibilità centrale e rischio di conflitti. Preferisci DNS o GPO.
Perché continuano comparire pochi 1014 anche dopo le modifiche?
Di solito sono residui da servizi terzi (agent, updater), dal primo riavvio post‑GPO o da host che risolvono nomi non ancora coperti dalle zone sinkhole. Riesegui l’analisi dei log per identificare i nuovi FQDN e aggiungili alle zone mirate.
Esempi di set minimo di FQDN/zone da considerare
Adatta la lista al tuo ambiente, partendo dai log reali:
- Aggiornamenti:
ctldl.windowsupdate.com,windowsupdate.com,delivery.mp.microsoft.com - Telemetry/Diagnostica:
settings-win.data.microsoft.com,v10.events.data.microsoft.com - Accedi/Identità:
login.live.com,login.microsoftonline.com - Cloud generico:
.windows.net,.microsoft.com(usare con prudenza) - Office/Click‑to‑Run:
officeclient.microsoft.com,config.office.com,officecdn.microsoft.com - NTP:
time.windows.com
Checklist operativa
- Raccogli i FQDN più chiamati (Event 1014 e/o packet capture).
- Imposta WSUS e abilita le policy che impediscono fallback a Internet.
- Riduci Telemetry e disabilita servizi non essenziali (DiagTrack, WerSvc, DoSvc).
- Configura NTP interno e spegni le dipendenze da
time.windows.com. - Valuta Root/CRL e gestisci le radici via GPO; evita update cloud.
- Applica DNS sinkhole per i FQDN/domini osservati.
- Completa con firewall in uscita (perimetro e, all’occorrenza, host).
- Audita task e servizi di terze parti.
- Configura Defender con sorgenti di firme interne.
- Verifica il calo degli Event 1014 e affina la lista delle zone sinkhole.
Rischi e mitigazioni
| Rischio | Descrizione | Mitigazione |
|---|---|---|
| Interruzione funzionalità | Blocco troppo ampio (es. zona microsoft.com) | Parti da FQDN mirati, test a ondate, monitora i log applicativi |
| Defender non aggiornato | Mancato download delle firme | WSUS/UNC interno per definizioni; workflow di import manuale periodico |
| Licensing | Attivazione fallita | KMS/AVMA in sede; verifica stato con slmgr /dli |
| Time drift | Ora non sincronizzata | NTP interno ridondato; monitoraggio w32tm /query /status |
| Manutenzione liste IP | Blocchi IP obsoleti | Preferire DNS sinkhole e controlli a livello perimetrale |
Playbook rapido: eliminare i 1014 in meno di un ciclo di manutenzione
- Esegui l’estrazione dei FQDN dai log 1014.
- Applica (o verifica) GPO: WSUS interno + Do not connect…, Telemetry=0, DO=Bypass, WER off.
- Configura NTP interno per i server.
- Crea 3–5 zone mirate per i top FQDN e lascia vuote (NXDOMAIN).
- Riavvia il servizio DNS client o il server (se appropriato) e
ipconfig /flushdns. - Monitora per 24–48h: i 1014 dovrebbero calare sensibilmente.
- Facoltativo: aggiungi un IP sinkhole e una regola DROP per visibilità sui tentativi residui.
Esempi di comandi utili
# Flush cache e verifica
ipconfig /flushdns
Get-DnsClientCache | Select-Object -First 20
Stato time service
w32tm /query /status
w32tm /query /configuration
Stato attivazione
slmgr /dli
slmgr /xpr
Eventi 1014 recenti con estrazione del nome
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-DNS Client Events/Operational'; Id=1014; StartTime=(Get-Date).AddDays(-1)} |
Select-Object TimeCreated, @{n='Name';e={($_.Message -split 'for the name\s+')[1] -split '\s' | Select-Object -First 1}} Conclusioni
In un ambiente Windows Server 2022 senza Internet, gli Event ID 1014 sono sintomo di componenti che tentano (invano) la risoluzione di domini Microsoft. La combinazione di GPO ben impostate (WSUS/KMS/NTP/Telemetry), sinkhole DNS per i FQDN più rumorosi, filtri egress e un audit accurato delle attività pianificate consente di eliminare i timeout DNS e mantenere i log puliti, senza rinunciare a patching, sicurezza e compliance di licensing.
Indicazioni supplementari
- Sincronizzazione NTP: se i server cercano
time.windows.com, impostare un server NTP interno o disabilitare la sincronizzazione esterna tramitew32time. - Root Certificate Update: disabilitare l’attività/feature “Auto Root Update” se l’ambiente è chiuso e distribuire le radici via GPO.
- Aggiornamenti delle firme Defender: se usate Microsoft Defender, configurare un percorso interno (WSUS o UNC) o pianificare import manuali delle definizioni.
Implementando in combinazione GPO, WSUS/KMS interni, blocchi firewall/DNS e un audit accurato dei servizi, gli eventi 1014 dovrebbero cessare senza compromettere le funzionalità essenziali del sistema.