Si en Windows Server 2022 ves repetidos “Event 1014 – DNS Client” contra dominios de Microsoft y tus servidores no tienen salida a Internet, esta guía te explica cómo detener los intentos de conexión, suprimir los timeouts y eliminar los avisos sin romper servicios internos.
Resumen del problema
En servidores aislados (sin Internet), el registro del sistema muestra advertencias Evento 1014 como:
Name resolution for
login.live.com
timed out after none of the configured DNS servers responded.
Los FQDN afectados suelen pertenecer a Microsoft (microsoft.com
, live.com
, windows.net
, msftconnecttest.com
, edge.microsoft.com
, etc.). La causa es que distintos componentes de Windows (Windows Update/DO, telemetría, activación, NCSI, Defender, Edge Update, WER, etc.) intentan “llamar a casa”; sin resolución externa, las consultas expiran y el cliente registra el evento.
Objetivo de la solución
- Eliminar la causa: impedir que el sistema intente contactar a Microsoft cuando el entorno es cerrado.
- Responder localmente esas consultas para evitar timeouts y, por tanto, los Evento 1014.
Estrategia general
- Aplicar un sinkhole/blackhole DNS interno para los dominios observados: respuesta instantánea (A/AAAA 0.0.0.0/:: o NXDOMAIN).
- Ajustar el servicio DNS (quitar root hints / deshabilitar recursión) si el entorno es totalmente cerrado.
- Configurar GPO para que Windows deje de intentar salir (WU/DO, Telemetría, WER, NCSI, Defender, Activación, Edge Update, MSA).
- Verificar con trazas y pruebas controladas, y mantener auditoría periódica.
Soluciones inmediatas: eliminar timeouts y eventos
Opción recomendada: hundimiento DNS (sinkhole/blackhole)
En tu servidor DNS interno (Windows DNS), crea zonas autoritativas para cada dominio que veas en los eventos y respóndelas localmente.
¿Qué devuelve el sinkhole?
- Wildcard A/AAAA → 0.0.0.0 / ::: devuelve IP nula de forma inmediata. El cliente no espera recursión y no hay Evento 1014.
- Zona vacía: autoritativa sin registros; las consultas inexistentes responden NXDOMAIN de inmediato.
Pasos (GUI en Windows DNS)
- Abrir DNS Manager → árbol del servidor → Forward Lookup Zones → New Zone….
- Primary zone, almacenar en AD si el DNS es integrado, o en archivo si es independiente.
- Nombre de zona: p. ej.
live.com
,microsoft.com
,windows.net
,msftconnecttest.com
,edge.microsoft.com
. - Crear en cada zona un registro wildcard:
- New Host (A or AAAA)… → Name:
*
→ IP:0.0.0.0
y, opcional, AAAA::
.
- New Host (A or AAAA)… → Name:
- Establecer TTL corto (60 s–5 min) para facilitar cambios.
Pasos (PowerShell en Windows DNS)
# Crear zona primaria autoritativa (sin recursión externa)
Add-DnsServerPrimaryZone -Name "live.com" -DynamicUpdate None
Respuesta inmediata con A 0.0.0.0 y AAAA ::
Add-DnsServerResourceRecordA -ZoneName "live.com" -Name "*" -IPv4Address "0.0.0.0" -TimeToLive 00:01:00
Add-DnsServerResourceRecordAAAA -ZoneName "live.com" -Name "*" -IPv6Address "::" -TimeToLive 00:01:00
Repite para microsoft.com, windows.net, msftconnecttest.com, edge.microsoft.com, etc.
Notas:
- Los wildcards no afectan a registros explícitos que tú mismo definas (tienen prioridad los registros específicos).
- Si prefieres NXDOMAIN, omite los registros wildcard: solo la zona + SOA bastan para respuesta autoritativa inmediata.
- Evita hundir dominios indiscriminadamente: céntrate en los que se observan en tus logs para no interferir con servicios internos legítimos.
Ajustes del servidor DNS (entornos cerrados)
Si tu red es 100 % cerrada, puedes hacer que el servidor DNS no intente Internet:
- Quitar root hints y deshabilitar recursión:
# Deshabilitar recursión Set-DnsServerRecursion -Enable $false Eliminar root hints (ejecuta en cada servidor DNS) Get-DnsServerRootHint | Remove-DnsServerRootHint -Force
Resultado: el servidor responderá de inmediato con NXDOMAIN/SERVFAIL cuando no sea autoritativo, sin agotar timeouts. - Quitar forwarders externos si existen.
Archivo hosts
(solo casos puntuales)
Como paliativo temporal en un equipo específico:
127.0.0.1 login.live.com
0.0.0.0 settings-win.data.microsoft.com
No es escalable ni centralizado; úsalo solo para pruebas o equipos aislados.
Cortafuegos perimetral
Debes mantener el bloqueo de salida a Internet, pero recuerda: el firewall por sí solo no evita timeouts DNS. Por eso el sinkhole o la respuesta autoritativa local es la pieza clave para eliminar el Evento 1014.
Atajar la raíz: impedir que Windows “salga”
Aplica las siguientes configuraciones por GPO (rutas en inglés/español pueden variar levemente según edición/idioma):
Componente | Ruta GPO | Directiva | Valor recomendado | Notas |
---|---|---|---|---|
Windows Update | Computer Configuration → Administrative Templates → Windows Components → Windows Update | Specify intranet Microsoft update service location | Habilitar y apuntar a WSUS (http(s)://wsus.fqdn ) | Define WUServer y WUStatusServer. Evita consultas a windowsupdate.com /microsoft.com . |
Windows Update | Windows Components → Windows Update | Do not connect to any Windows Update Internet locations | Enabled | Bloquea acceso a Microsoft Update en Internet. |
Windows Update | Windows Components → Windows Update | Configure Automatic Updates | Disabled (si no usas WSUS) o configurado para WSUS | Evita ciclos de sondeo a la nube si el origen es WSUS o no hay actualizaciones. |
Delivery Optimization | Windows Components → Delivery Optimization | Download Mode | 99 – Bypass | Impide que DO contacte servicios externos. |
Telemetría | Windows Components → Data Collection and Preview Builds | Allow Telemetry | 0 – Security (en Server) | Nivel mínimo admitido en Server 2022. |
DiagTrack | Services (vía GPO Preferences o plantilla de seguridad) | Connected User Experiences and Telemetry (DiagTrack) | Startup: Disabled | Detiene las salidas de telemetría del servicio. |
WER | Windows Components → Windows Error Reporting | Disable Windows Error Reporting | Enabled | Evita envíos de informes a Microsoft. |
NCSI | Network → Network Connectivity Status Indicator | Turn off active probes | Enabled | Elimina consultas a msftconnecttest.com / msftncsi.com . |
Activación | Plantillas/Script | slmgr /skms <kms.fqdn> + KMS/AVMA/ADBA | Usar orígenes internos | Evita activation.sls.microsoft.com . |
Microsoft Defender | Windows Components → Microsoft Defender Antivirus → MAPS | Join Microsoft MAPS / Cloud-delivered protection / Sample submission | Disabled / Not configured para offline | Firmas vía WSUS o UNC interno. |
Edge Update | System → Scheduled Tasks (GPP) o Windows Components → Microsoft Edge Update | Deshabilitar tareas MachineCore/MachineUA o gestionar por WSUS | Disable si no se usa en servidores | Reduce llamadas a edge.microsoft.com y dl.delivery.mp.microsoft.com . |
Cuentas Microsoft (MSA) | Security Options | Accounts: Block Microsoft accounts | Users can’t add or log on with MSA | Evita accesos a login.live.com . |
Equivalentes de registro (ejemplos rápidos)
Para entornos sin AD/GPO, puedes aplicar claves por script (prueba primero en un laboratorio):
# Windows Update: no conectarse a ubicaciones de Microsoft
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v DoNotConnectToWindowsUpdateInternetLocations /t REG_DWORD /d 1 /f
WSUS
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /t REG\_SZ /d [http://wsus.fqdn](http://wsus.fqdn) /f
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer /t REG\_SZ /d [http://wsus.fqdn](http://wsus.fqdn) /f
Delivery Optimization: Bypass (99)
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization /v DODownloadMode /t REG\_DWORD /d 99 /f
NCSI: desactivar pruebas activas
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator /v NoActiveProbe /t REG\_DWORD /d 1 /f
Monitorización y verificación
¿Quién hace la consulta?
- Visor de eventos → Microsoft‑Windows‑DNS‑Client/Operational (habilítalo si no aparece).
- Registro del sistema (Origen: DNS Client Events), Id 1014.
- Sysmon (evento 22) o
netsh trace
/Wireshark para ver el proceso de origen.
Pruebas rápidas
ipconfig /flushdns
Debe responder instantáneo con 0.0.0.0/:: o NXDOMAIN (según tu diseño)
nslookup login.live.com \
Resolve-DnsName login.live.com -Server \
Si el sinkhole está bien, ya no aparecerán nuevos 1014 por esos dominios. Repite con los FQDN que aún veas en los logs.
Checklist de dominios comunes para sinkhole (ajusta a tu entorno)
Dominio | Motivo habitual | Respuesta sugerida |
---|---|---|
login.live.com | Intentos de inicio de sesión MSA / servicios asociados | A/AAAA → 0.0.0.0 / :: |
msftconnecttest.com | NCSI (comprobación de conectividad) | Zona vacía o A/AAAA nulos |
microsoft.com | Varios componentes de sistema | Zona con cuidado; evita romper CRL si dependes de ella |
windows.net | Servicios en la nube, WU/DO CDN | A/AAAA nulos |
edge.microsoft.com | Actualizaciones/telemetría de Edge | A/AAAA nulos |
dl.delivery.mp.microsoft.com | Content delivery de actualizaciones | A/AAAA nulos |
Importante: no uses listas “masivas” a ciegas; añade dominios al sinkhole solo si aparecen en tus registros. Si algún rol necesita acceso puntual (p. ej., validación de CRL/OCSP, NTP, repositorios internos), proporciónalo desde orígenes internos.
Script de ejemplo para automatizar el sinkhole
Este script crea zonas y registros wildcard para una lista controlada de dominios. Ejecútalo en cada servidor DNS (o en uno con replicación AD integrada).
$domains = @(
"live.com",
"msftconnecttest.com",
"windows.net",
"edge.microsoft.com",
"microsoft.com"
)
foreach (\$d in \$domains) {
if (-not (Get-DnsServerZone -Name \$d -ErrorAction SilentlyContinue)) {
Write-Host "Creando zona \$d..."
Add-DnsServerPrimaryZone -Name \$d -DynamicUpdate None | Out-Null
}
A 0.0.0.0
if (-not (Get-DnsServerResourceRecord -ZoneName \$d -Name "*" -RRType "A" -ErrorAction SilentlyContinue)) {
Add-DnsServerResourceRecordA -ZoneName \$d -Name "*" -IPv4Address "0.0.0.0" -TimeToLive 00:01:00 | Out-Null
}
AAAA ::
if (-not (Get-DnsServerResourceRecord -ZoneName \$d -Name "*" -RRType "AAAA" -ErrorAction SilentlyContinue)) {
Add-DnsServerResourceRecordAAAA -ZoneName \$d -Name "*" -IPv6Address "::" -TimeToLive 00:01:00 | Out-Null
}
}
Write-Host "Sinkhole aplicado. Prueba con: Resolve-DnsName login.live.com -Server \"
Orden de implementación sugerido
- Aplicar sinkhole DNS para los dominios observados → efecto inmediato: desaparecen los 1014 por timeouts.
- Configurar GPO (Windows Update/DO, Telemetría, WER, NCSI, Defender, Activación, Edge Update, MSA).
- Revisar tareas/servicios (Edge Update, CEIP, programador de tareas), desinstalar Edge si no se usa en servidores.
- Mantener bloqueo en firewall y auditoría DNS periódica para detectar nuevos dominios que debas hundir.
Métricas de éxito
- 0 eventos nuevos 1014 en 24–72 h.
- Consultas a dominios hundidos resueltas < 5 ms (según latencia local).
- Sin impacto en servicios internos ni validaciones (CRL/OCSP/NTP) gracias a orígenes internos.
Riesgos y consideraciones
- CRL/OCSP: algunos roles pueden requerir validar certificados. Proporciona mirrors internos o PKI propia. Evita hundir dominios de CA de terceros que necesites.
- Actualizaciones: si no usas WSUS ni repositorio de firmas para Defender, planifica un método offline antes de bloquear por completo.
- IPv6: devuelve también AAAA (::) para evitar que el cliente pruebe la pila IPv6 y genere nuevos intentos.
- Split‑brain DNS: si tienes zonas internas con el mismo nombre que dominios públicos, define explícitamente los registros necesarios para no romper resoluciones internas.
Rollback (si necesitas revertir)
# Eliminar registros wildcard
Remove-DnsServerResourceRecord -ZoneName "live.com" -RRType "A" -Name "*" -Force
Remove-DnsServerResourceRecord -ZoneName "live.com" -RRType "AAAA" -Name "*" -Force
Eliminar la zona completa (si procede)
Remove-DnsServerZone -Name "live.com" -Force
Antes de eliminar zonas del sinkhole, verifica que ya no se generan 1014 o que has reemplazado la funcionalidad por otra medida (p. ej., GPO aplicada o excepción controlada).
Preguntas frecuentes
¿Basta con bloquear “todo Internet” en el firewall?
No. El firewall evita la salida, pero el cliente DNS seguirá intentando resolver y esperará a que expire la recursión. El sinkhole o la respuesta autoritativa local eliminan el tiempo de espera y, por tanto, el evento.
¿Mejor A 0.0.0.0 o NXDOMAIN?
Ambos funcionan. 0.0.0.0 corta de inmediato cualquier intento de conexión TCP/HTTPS; NXDOMAIN comunica que el nombre no existe. Elige el que mejor se adapte a tu telemetría y a cómo quieres ver los fallos en aplicaciones.
¿Puedo hundir el dominio microsoft.com
entero?
Es posible, pero hazlo solo si lo has validado en tu entorno. Algunos componentes o herramientas pueden resolver subdominios bajo microsoft.com
. Empieza por dominios específicos observados en los eventos y amplía según tus hallazgos.
¿Qué pasa con servidores que sí necesitan Internet?
Usa GPO por OU para aplicar estas políticas solo a los servidores desconectados. En servidores con salida controlada, contemplar listas de permitidos y evita hundir dominios que realmente necesiten.
¿Cómo detecto rápidamente el proceso que origina la consulta?
Habilita el log Microsoft‑Windows‑DNS‑Client/Operational y, si tienes Sysmon, revisa el evento 22. También puedes usar netsh trace start capture=yes scenario=InternetClient
y analizar la traza.
Plantilla de implementación rápida
- Registrar dominios observados (de 1014 y trazas DNS).
- Crear zonas de sinkhole (A/AAAA
0.0.0.0
/::
o zonas vacías). - Aplicar GPO (WU/DO, Telemetría, WER, NCSI, Defender, Activación, Edge Update, MSA).
- Validar con
Resolve-DnsName
y revisión de eventos 24–72 h. - Añadir nuevos dominios al sinkhole si aparecen en logs.
Conclusión
El Evento 1014 en Windows Server 2022 no es un fallo del DNS local: es un síntoma de que el equipo intenta resolver dominios externos a los que no puede llegar. La forma más limpia de silenciar esos avisos sin perder visibilidad es doble: (1) responder localmente (sinkhole/NXDOMAIN) para eliminar timeouts y (2) reducir la necesidad de salir aplicando GPO alineadas con un entorno sin Internet. Con ello logras estabilidad, menos ruido en el visor de eventos y control total de qué dominios se consultan desde tus servidores.