Conectividad por nombre perdida hacia Windows 2000/SQL 2000 tras elevar el DC a Windows Server 2019: diagnóstico DNS/WINS y solución paso a paso

Después de elevar el controlador de dominio a Windows Server 2019, un servidor Windows 2000 con SQL Server 2000 deja de ser accesible por nombre pero sí por IP. Este artículo te guía para restaurar rápido el servicio y aplicar el arreglo estable centrado en DNS/WINS, sin depender de atajos inseguros.

Índice

Resumen del escenario y diagnóstico

Tras migrar el controlador de dominio desde Windows Server 2012 a Windows Server 2019, el servidor Windows 2000 (miembro del dominio) deja de responder por su nombre corto o nombre de host. La aplicación de negocio que conecta contra SQL Server 2000 en ese equipo falla por “no se puede resolver el servidor”, aunque si se usa la dirección IP la conectividad y la base de datos funcionan.

Este patrón es inequívoco: si por IP funciona y por nombre no, el problema es la resolución de nombres (DNS o NetBIOS/WINS), no la red física ni SQL. La elevación de DC suele introducir cambios en:

Configuración de DNS (zonas integradas en AD, permisos de actualización dinámica, scavenging, TTL).
Ausencia o desconfiguración de WINS si antes resolvías nombres de una sola etiqueta (p. ej., SERVER2000).
DHCP que deja de anunciar correctamente DNS primario y sufijo DNS del dominio a los clientes.
Políticas de seguridad más estrictas que afectan a NetBIOS/NTLM, con impacto colateral si aún dependías de WINS.

Acciones inmediatas para recuperar el servicio

Estas medidas son reversibles y permiten que los usuarios trabajen mientras corriges la causa raíz.

Usar FQDN o IP en la cadena de conexión:
Preferible: SERVER2000.dominio.local
Temporal: 10.x.x.x,1433 (si la instancia escucha en 1433).
Crear un alias de cliente de SQL que mapee el nombre antiguo al IP/puerto.
En clientes modernos, abre SQL Server Configuration Manager → SQL Native Client Configuration → Client Protocols → Aliases. En clientes legados ejecuta cliconfg.exe y agrega un alias TCP: Alias name: SERVER2000 Server: 10.x.x.x Protocol: TCP/IP Port: 1433 Nota: En sistemas de 64 bits, verifica tanto la versión de 32 como de 64 bits (%windir%\SysWOW64\cliconfg.exe y %windir%\System32\cliconfg.exe).
Archivo hosts (temporal): en los clientes, añade una línea: 10.x.x.x SERVER2000

Arreglo correcto y estable con DNS

El objetivo es que los clientes resuelvan SERVER2000 como SERVER2000.dominio.local y que ese FQDN apunte a la IP correcta.

Crear o validar los registros necesarios

Registro A estático en la zona del dominio para el nombre del equipo: Nombre: SERVER2000 Tipo: A Dirección IPv4: 10.x.x.x TTL: 1h (o acorde a tus políticas)
Registro PTR (opcional) en la zona inversa para facilitar diagnósticos.
Si la aplicación usa un alias “amigable” (APP-LEGACY), crea un CNAME: APP-LEGACY CNAME SERVER2000.dominio.local. Recomendación SEO/operativa interna: usa siempre CNAME de la app apuntando al host real para facilitar futuras migraciones.

Garantizar que todos los clientes usan el DNS del dominio

En tu servidor DHCP, publica:

Opción 006: direcciones IP de tus servidores DNS (normalmente tus DC 2019).
Opción 015: sufijo DNS del dominio (por ejemplo, dominio.local).

Ejemplo de verificación en un cliente:

ipconfig /all
nslookup SERVER2000
nslookup SERVER2000.dominio.local
ipconfig /flushdns

Si nslookup SERVER2000 no devuelve nada pero nslookup SERVER2000.dominio.local sí, el problema es la búsqueda por sufijo. Asegúrate de que la opción 015 está vigente o define una search list en GPO.

Configurar correctamente el servidor Windows 2000

En el TCP/IP del Windows 2000, establece como DNS primario el DC 2019. Evita DNS públicos en el cliente legacy.
Windows 2000 no maneja bien las secure dynamic updates. Mantén registros A/PTR estáticos y revisa que el scavenging de la zona no los elimine.

Replicación y cachés

Si tienes varios DC, valida que el registro A/CNAME se haya replicado. Comandos útiles: repadmin /replsummary repadmin /showobjmeta <DN del registro> dnscmd /enumrecords dominio.local SERVER2000 /type A
Tras cambios, vacía la caché DNS del servidor y clientes: dnscmd /clearcache ipconfig /flushdns

Si antes dependías de NetBIOS/WINS

Muchos entornos con Windows 2000 resolvían nombres de una sola etiqueta mediante WINS. Al migrar a Windows Server 2019, WINS suele quedar sin instalar ni integrar. Detecta si es tu caso:

Prueba en un cliente: nbtstat -a SERVER2000. Si responde pero DNS no, había dependencia de NetBIOS.
Revisa en DNS de la zona del dominio si existía “WINS forward lookup” (pestaña WINS de la zona). Si ya no está, los nombres cortos dejaron de resolverse.

Opciones para resolverlo

Eliminar dependencia de WINS y pasar todo a DNS + FQDN con registros A/CNAME. Es lo recomendado.
Reinstalar WINS como puente temporal: # En el DC 2019 (PowerShell elevado) Install-WindowsFeature WINS -IncludeManagementTools Configura el servidor WINS, agrega registros estáticos si procede y publica en DHCP:
- Opción 044 (NBNS/WINS): IP del servidor WINS.
- Opción 046 (Node Type): valor 0x8 (Híbrido) para priorizar consultas a WINS sobre broadcast.
Usar GlobalNames si tu problema son alias de una sola etiqueta a nivel de bosque. Crea la zona GlobalNames y habilita el soporte: dnscmd /config /EnableGlobalNamesSupport 1 Añade en esa zona CNAME estáticos para tus nombres “cortos” corporativos.

Recuerda: WINS está obsoleto. Úsalo solo como puente mientras migras a DNS completamente.

Consideraciones específicas de SQL Server 2000

Puerto fijo para la instancia (ideal 1433 en instancias predeterminadas). En el servidor Windows 2000 abre la utilidad de redes de SQL 2000 y fija el puerto TCP. Evita depender de UDP 1434 si no es imprescindible.
Alias de cliente si no puedes cambiar la cadena de conexión de la aplicación. En clientes define servidor,puerto o alias TCP como se explicó arriba.
Prueba rápida con OSQL desde un cliente: osql -S 10.x.x.x,1433 -E -- o autenticación SQL osql -S 10.x.x.x,1433 -U sa -P <password>
Si usabas Named Pipes, recuerda que también requieren resolución por nombre para rutas tipo \\SERVER2000\pipe\sql\query. Preferible migrar a TCP.

Compatibilidad y seguridad en entornos modernos

Es posible que, además de la resolución de nombres, aparezcan fallos de autenticación por el endurecimiento de políticas en DC 2019. Señales típicas: eventos de Netlogon, errores de “relación de confianza” o denegaciones por NTLMv1.

Si no puedes reubicar el equipo legacy fuera del dominio, crea una OU específica y vincula una GPO relajada solo para ese equipo (por ejemplo, valores menos estrictos de “Network security: LAN Manager authentication level” o “Microsoft network client/server: digitally sign communications”).
Aísla y segmenta el servidor Windows 2000 (VLAN/ACL), exponiendo únicamente los puertos necesarios (p. ej., 1433/TCP y 3389/TCP si RDP es imprescindible). Supervisa y registra accesos.
Evita habilitar de forma global configuraciones inseguras como NTLMv1 o desactivar firma SMB para todo el dominio.

Por qué suele romperse tras subir a Windows Server 2019

Aunque DNS “siga ahí”, la migración cambia sutilezas:

Zonas integradas en AD que ahora exigen actualizaciones seguras y no aceptan registros enviados por clientes antiguos.
El antiguo servidor DNS quizá tenía configurado WINS lookup en la zona, y el nuevo no.
DHCP puede seguir anunciando el DNS viejo (apagado) o un sufijo DNS incorrecto.
Limpieza (scavenging) aguda de registros huérfanos que borra entradas del servidor legacy.

Tabla de decisión rápida

Síntoma	Cómo confirmarlo	Acción recomendada
Por IP funciona, por nombre no	`nslookup SERVER2000` falla; `ping 10.x.x.x` responde	Crear A/CNAME, asegurar Opción 006 y 015, usar FQDN
Nombre corto falla, FQDN funciona	`nslookup SERVER2000.dominio.local` ok; corto falla	Publicar sufijo DNS por DHCP o configurar search list
NetBIOS resuelve pero DNS no	`nbtstat -a SERVER2000` muestra tabla	Migrar a DNS; si urge, reinstalar WINS y difundir 044/046
Resolución intermitente	Registro A existe en un DC pero no en otro	Revisar replicación de zonas AD-integrated; forzar y validar
Falla autenticación de dominio	Eventos Netlogon; errores de confianza	OU aislada con GPO específica o cuenta local/SQL; segmentar

Procedimiento paso a paso recomendado

Comprobar desde un cliente representativo: ipconfig /all Resolve-DnsName SERVER2000 -Type A # en PowerShell moderno nslookup SERVER2000 nslookup SERVER2000.dominio.local
Crear/validar registros en DNS (en un DC 2019): PowerShell (DNS Server Tools): Add-DnsServerResourceRecordA -ZoneName "dominio.local" -Name "SERVER2000" -IPv4Address "10.x.x.x" -TimeToLive 01:00:00 Add-DnsServerResourceRecordCName -ZoneName "dominio.local" -Name "APP-LEGACY" -HostNameAlias "SERVER2000.dominio.local"
Configurar DHCP para apuntar a los DNS correctos (006) y publicar el sufijo (015). Renueva concesión en clientes: ipconfig /release ipconfig /renew
Fijar DNS en el servidor Windows 2000 al DC 2019 y dejar el registro A como estático.
Si la app usa nombre corto y no puedes cambiarla de inmediato:
- Implementa GlobalNames para crear un alias de una etiqueta; o
- Reinstala WINS temporalmente y publica por DHCP 044/046.
En clientes críticos, crea un alias de SQL o una entrada temporal en hosts hasta completar el cambio.
Verifica conectividad de SQL: Test-NetConnection -ComputerName SERVER2000.dominio.local -Port 1433 o osql -S SERVER2000.dominio.local,1433 -E

Buenas prácticas de DNS para legados

Usa CNAME por aplicación (p. ej., erp-legacy) apuntando al host. El día que migres, solo cambias el CNAME.
TTL de una hora para facilitar cambios sin saturar cachés.
Evita scavenging agresivo en registros estáticos; marca “no caducar” si tu política lo permite.
Documenta en el registro DNS la dependencia: agrega comentario “usado por App X”.

Trampas comunes

Confiar en LLMNR/mDNS: son mecanismos de descubrimiento local que no aplican a entornos de dominio ni a Windows 2000.
Apuntar clientes a DNS públicos “para que Internet vaya rápido”: romperás la resolución interna y Kerberos.
Habilitar políticas inseguras a todo el dominio “por el legacy”: hazlo solo en una OU aislada y solo si no hay alternativa inmediata.

Lista de verificación

[ ] Registro A/PTR del servidor 2000 creado y resolviendo correctamente.
[ ] Clientes usando el DNS del DC 2019 (DHCP Opción 006) y sufijo DNS (Opción 015).
[ ] nslookup del FQDN funciona desde varios clientes y subredes.
[ ] Si aplica, dependencia de WINS migrada a DNS o WINS reconfigurado temporalmente.
[ ] SQL 2000 con puerto fijo y alias en clientes cuando sea necesario.
[ ] Servidor legacy segmentado y con reglas de firewall estrictas.

Plan de medio plazo y salida limpia del legado

Windows 2000 y SQL Server 2000 están fuera de soporte. Para reducir riesgo operativo y de seguridad:

Migración de base de datos: en muchos casos necesitarás un salto intermedio (p. ej., restaurar en SQL 2008/2008 R2 y de ahí a versiones soportadas) por la versión de compatibilidad. Planifica pruebas de funcionalidad de la aplicación.
Congela cambios en el servidor legacy (no parches, no roles adicionales) y limítalo a su función de SQL hasta su desmantelamiento.
Monitoriza y alerta ante cualquier consulta fuera de patrón (IDS/IPS, Sysmon en un recolector aparte, exportación de registros).

Ejemplo completo de corrección en una tarde

En DC 2019 agrega A de SERVER2000 y CNAME APP-LEGACY → SERVER2000.dominio.local.
Asegura DHCP 006 y 015 a todos los segmentos.
En el servidor Windows 2000, DNS primario = DC 2019; desmarca dinámicas si no son necesarias.
En tres clientes piloto, ipconfig /flushdns y prueba: Resolve-DnsName APP-LEGACY Test-NetConnection APP-LEGACY -Port 1433
Si hay urgencia de nombre corto, habilita GlobalNames o WINS temporalmente.
Como red de seguridad, crea alias de SQL en clientes críticos durante la transición.

Preguntas frecuentes

¿Por qué funcionaba antes sin FQDN?
Probablemente porque WINS estaba instalado o la zona DNS tenía habilitado “WINS lookup”. Al migrar a 2019 eso desapareció.

¿Puedo solucionar solo con el archivo hosts y olvidarme?
Es válido para una emergencia, pero difícil de mantener y fuente de errores. El arreglo estable es DNS.

¿Qué hay de Kerberos y SPN de SQL 2000?
Para el problema de resolución de nombres no son determinantes. Si usas seguridad integrada y cambias de nombre o alias, valida SPN para evitar fallback a NTLM. Con SQL 2000 suele usarse NTLM, pero no habilites NTLMv1 de forma global.

¿Puedo usar registros pinpoint con TTL muy bajo?
Sí, durante la transición. Luego sube a valores normales para evitar cargas innecesarias.

Conclusión

La pérdida de conectividad por nombre hacia Windows 2000/SQL 2000 tras subir a Windows Server 2019 es, en la inmensa mayoría de los casos, una consecuencia de cambios en DNS/WINS y en la distribución del sufijo DNS. Con las acciones inmediatas puedes restablecer el servicio en minutos; con el arreglo estable basado en DNS, eliminas la fragilidad histórica y preparas el camino para retirar el legado con seguridad.

Nota útil: El “modo de compatibilidad” de Windows para ejecutables no corrige problemas de conectividad de servicios como SQL Server. El foco debe estar en DNS/WINS y en la compatibilidad de protocolos del dominio.

Anexo: orden simplificado de resolución de nombres en clientes Windows

En un equipo de dominio, el orden típico es: hosts → DNS (con lista de sufijos) → cache local → LLMNR/mDNS (según políticas) → WINS → broadcast NetBIOS. Si desactivaste LLMNR por seguridad, un nombre corto que no esté en DNS ni WINS fallará.
Anexo: comandos útiles para tu “caja de herramientas”

# En clientes modernos
Resolve-DnsName SERVER2000
Resolve-DnsName APP-LEGACY -Type CNAME
Test-NetConnection SERVER2000.dominio.local -Port 1433
Get-DnsClientServerAddress

En DC 2019

Get-DnsServerResourceRecord -ZoneName dominio.local -Name SERVER2000
Add-DnsServerResourceRecordA -ZoneName dominio.local -Name SERVER2000 -IPv4Address 10.x.x.x
Add-DnsServerResourceRecordCName -ZoneName dominio.local -Name APP-LEGACY -HostNameAlias SERVER2000.dominio.local
dnscmd /clearcache
repadmin /replsummary

NetBIOS/WINS

nbtstat -a SERVER2000
ipconfig /all

Lista de verificación rápida

[ ] Registro A/PTR del servidor 2000 creado y resolviendo.
[ ] Clientes con DNS del DC 2019 (opción 006) y sufijo DNS (opción 015).
[ ] nslookup del FQDN responde desde las subredes implicadas.
[ ] Si aplicaba WINS, migrado a DNS o reconfigurado temporalmente.
[ ] SQL 2000 con puerto fijo y alias de cliente donde sea necesario.
[ ] Servidor legacy aislado, con ACL y monitoreo activo.