Arreglar DNS en Windows: deja de usar “flushdns” como un ritual

febrero 25, 2026 • febrero 25, 2026 • Lectura: 23 min • Views: 1

¿Te fue útil?

Si estás leyendo esto, probablemente hayas visto a alguien escribir ipconfig /flushdns con la confianza de un mago lanzando un hechizo. A veces “funciona”, otras veces no cambia nada, y a veces empeora las cosas al borrar la única pista útil que tenías: lo que la máquina creía hace cinco segundos.

Los fallos de DNS en Windows rara vez se solucionan con un único comando. Se solucionan entendiendo qué resolvedor está en juego, qué caché está mintiendo y qué componente de red te está “ayudando” a cavar un hoyo. Dejemos de hacer exorcismos DNS y empecemos a diagnosticar.

Qué hace realmente `flushdns` (y qué no hace)

ipconfig /flushdns borra la caché del resolvedor del Cliente DNS de Windows. Eso es todo. No hace:

Cambiar qué servidores DNS estás usando.
Arreglar una política de DNS rota del VPN.
Deshacer una lista de sufijos de búsqueda incorrecta.
Eliminar un registro obsoleto del servidor DNS de tu empresa.
Reiniciar Winsock, reglas de firewall o ajustes de proxy.
Arreglar una aplicación que hace su propio DNS (muchas lo hacen).

Puede ayudar cuando la caché contiene una respuesta incorrecta o una entrada negativa (NXDOMAIN) que quieres volver a comprobar de inmediato. También puede ocultar la evidencia cuando estás intentando averiguar si la falla es “caché local” o “DNS aguas arriba”. No quieres borrar la evidencia hasta saber qué estás viendo.

Dos realidades importantes:

Los problemas de DNS suelen ser problemas de política. La máquina está haciendo exactamente lo que se le indicó, y lo que se le indicó está mal.
Windows no es tu único resolvedor. Los navegadores, clientes VPN, agentes de seguridad y herramientas de gestión de endpoints pueden introducir sus propias cachés y comportamientos DNS.

La mentalidad operativa: trata flushdns como reiniciar un servicio. A veces es un paso útil final. No es el primer paso. Si tu primer movimiento es eliminar estado, has elegido la ceguera.

Guía rápida de diagnóstico

Esta es la secuencia “estás en una llamada, alguien grita y necesitas señal en 90 segundos”. Ejecútala en orden. No improvises hasta haber identificado la categoría de fallo.

1) ¿Es esto DNS o no es DNS?

¿Puedes alcanzar una dirección IP pero no un nombre?
¿Es sólo un hostname o todos los hostnames?
¿Es sólo dentro de dominios corporativos (p. ej., corp.example)?

2) Identifica la ruta DNS activa

¿Qué interfaz se está usando (Wi‑Fi, Ethernet, VPN, adaptador virtual)?
¿Qué servidores DNS están configurados en esa interfaz ahora mismo?
¿Un VPN está imponiendo DNS o split tunneling?

3) Compara resolvedores

¿Funciona nslookup mientras el navegador falla?
¿Da resultados distintos PowerShell Resolve-DnsName frente a nslookup?

4) Comprueba caché y caché negativa

¿La caché local mantiene NXDOMAIN?
¿Estás compitiendo contra TTLs (respuestas que cambian durante el incidente)?

5) Sólo entonces: reinicia/borra como experimento controlado

Vacía la caché y vuelve a consultar el mismo nombre.
Registra qué cambió. Si nada cambió, deja de vaciar la caché.

Idea parafraseada de David J. Wheeler: Todos los problemas en informática pueden resolverse añadiendo otra capa de indirección—excepto los problemas causados por la indirección. DNS es indirección con sentimientos.

Cómo Windows resuelve nombres: el orden real de operaciones

Cuando alguien dice “DNS está roto”, normalmente se refiere a “la resolución de nombres está rota”. En Windows, la resolución de nombres puede involucrar:

Archivo hosts (C:\Windows\System32\drivers\etc\hosts)
Servicio Cliente DNS (caché + consulta a servidores DNS configurados)
Lista de sufijos de búsqueda DNS (convertir app en app.corp.example)
LLMNR (Link-Local Multicast Name Resolution) y NetBIOS en algunos entornos
mDNS para escenarios .local (depende de componentes instalados)
Proxy y scripts PAC (no es DNS, pero hace que “no se puede alcanzar por nombre” parezca DNS)
Resolvedores de aplicaciones (navegadores y runtimes pueden cachear o usar DoH)

Algunos de estos “ayudan” hasta que no lo hacen. Por ejemplo:

Si hosts sobreescribe un nombre, vaciar DNS no lo cambiará. Esa sobreescritura gana.
Si tu navegador usa DNS sobre HTTPS (DoH), vaciar el DNS de Windows puede no tocar la ruta de resolución del navegador.
Si el servidor DNS está bien pero consultas al equivocado (el adaptador VPN tomó precedencia), vaciar no arregla la precedencia.

Una matiz más: nslookup no es “el resolvedor de Windows”. Es una herramienta de diagnóstico que habla con un servidor DNS. Puede omitir partes de la pila de resolución y del comportamiento de caché de Windows. Cuando nslookup funciona pero la aplicación no, eso no es una contradicción: es tu pista.

Broma #1: Vaciar DNS para arreglar todo es como reiniciar una impresora para arreglar tu declaración de impuestos. Cambia tu estado de ánimo, no los hechos.

Hechos interesantes y contexto histórico (porque esto se volvió raro con el tiempo)

DNS es anterior a la web. DNS se diseñó a principios de los años 80 para reemplazar archivos HOSTS.TXT manuales que no escalaban.
La caché negativa es deliberada. Cachear NXDOMAIN evita consultas repetidas por nombres inexistentes que golpearían a los servidores autoritativos.
La caché del Cliente DNS de Windows ha sido “pegajosa” por diseño. La caché existe para reducir latencia y carga, lo que la convierte en sospechosa durante incidentes de cambios rápidos.
Los sufijos de búsqueda se construyeron para humanos. Las empresas querían que mail o intranet funcionaran sin teclear un dominio completo cada vez.
Split DNS es anterior al bombo moderno del VPN. Las organizaciones grandes necesitaban respuestas internas para zonas internas y respuestas distintas fuera de la red.
LLMNR existe porque a la gente le da pereza teclear. Es un protocolo de conveniencia para redes locales, pero también es un riesgo de seguridad y a menudo está deshabilitado en entornos endurecidos.
DoH es, en parte, reacción a redes hostiles. Encriptar consultas DNS reduce el espionaje y la manipulación en ruta, pero puede complicar la política corporativa y la respuesta a incidentes.
EDNS0 y respuestas más grandes cambiaron modos de fallo. Las respuestas DNS crecieron (piensa en DNSSEC, muchos registros), y problemas de path MTU/fragmentación empezaron a aparecer como “timeouts DNS aleatorios”.
“DNS server not responding” a menudo es una mentira. El servidor DNS puede estar bien; el cliente puede estar bloqueado para alcanzarlo por UDP/TCP 53, o está consultando la interfaz equivocada.

Tareas prácticas: comandos, salidas y decisiones (12+)

Cada tarea abajo incluye un comando, qué significa la salida y qué decisión tomar. Úsalas como caja de herramientas. No las ejecutes como un script sacado de un foro.

Task 1: Confirmar qué servidores DNS está usando realmente Windows

cr0x@server:~$ ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : LPT-0442
   Primary Dns Suffix  . . . . . . . : corp.example
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . . : corp.example
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11

Ethernet adapter VPN:

   Connection-specific DNS Suffix  . . : vpn.corp.example
   DNS Servers . . . . . . . . . . . : 172.16.50.53

Significado: Puedes tener múltiples adaptadores, cada uno con servidores DNS distintos. Windows elegirá según métricas de interfaz y políticas.

Decisión: Si el adaptador VPN está activo y tiene un servidor DNS, valida si debería ser autoritativo para los nombres que fallan. Si no, estás ante un problema de precedencia/métrica o de política del VPN, no de caché.

Task 2: Identificar qué interfaz es preferida (métricas)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Select-Object -First 8 | Format-Table -AutoSize"

ifIndex InterfaceAlias     AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp   ConnectionState
------- --------------     ------------- ------------ --------------- ----   ---------------
24      VPN               IPv4          1400         5               Enabled Connected
12      Ethernet          IPv4          1500         25              Enabled Connected
9       Wi-Fi             IPv4          1500         55              Enabled Connected

Significado: La métrica más baja gana. Aquí, VPN es preferido para tráfico IPv4 y a menudo para comportamiento DNS.

Decisión: Si las fallas de DNS ocurren sólo cuando la VPN está conectada, enfócate en los servidores DNS del VPN, la configuración de split DNS y NRPT/políticas. No pierdas tiempo con flushdns todavía.

Task 3: Consultar usando el resolvedor de Windows (no nslookup)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName app.corp.example -Type A"

Name           Type TTL Section IPAddress
----           ---- --- ------- ---------
app.corp.example A   30 Answer  10.30.40.25

Significado: Esto muestra lo que el resolvedor de Windows devuelve y el TTL que ve.

Decisión: Si Resolve-DnsName falla pero nslookup funciona, probablemente tengas políticas/caché local u orden de resolución problemáticos. Si ambos fallan, sospecha DNS aguas arriba o alcance de red.

Task 4: Consultar un servidor DNS específico para evitar “lo que Windows eligió”

cr0x@server:~$ nslookup app.corp.example 10.20.0.10

Server:  dc01.corp.example
Address:  10.20.0.10

Name:    app.corp.example
Address: 10.30.40.25

Significado: Esto confirma si el servidor DNS objetivo puede responder correctamente.

Decisión: Si consultar un servidor conocido bueno funciona, pero las consultas por defecto fallan, enfócate en qué servidor el cliente está usando realmente (orden de adaptadores, VPN, opciones DHCP, DNS estático, agente de seguridad).

Task 5: Comprobar caché negativa y qué hay en la caché

cr0x@server:~$ ipconfig /displaydns

    app.corp.example
    ----------------------------------------
    Record Name . . . . . : app.corp.example
    Record Type . . . . . : 1
    Time To Live  . . . . : 18
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . . : 10.30.40.25

Significado: Puedes ver qué Windows cacheó y cuánto tiempo planea mantenerlo.

Decisión: Si la caché contiene NXDOMAIN o una IP antigua que ya no enruta, vaciar puede estar justificado. Pero pregunta: ¿por qué está mal? ¿Upstream malo? ¿Split brain? ¿Registros obsoletos? Arregla la fuente.

Task 6: Vaciar la caché DNS (como prueba controlada)

cr0x@server:~$ ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Significado: Caché borrada. No hay garantía de que la siguiente respuesta sea mejor.

Decisión: Vuelve a ejecutar inmediatamente la misma consulta y compara. Si la respuesta no cambia, la caché no era el problema.

Task 7: Verificar que el servicio Cliente DNS esté en ejecución

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Dnscache | Format-List Status,Name,StartType"

Status    : Running
Name      : Dnscache
StartType : Automatic

Significado: El servicio Cliente DNS proporciona caché y parte de la lógica de resolución.

Decisión: Si está detenido/deshabilitado (a veces por guías de “tuning”), espera comportamiento extraño y mal rendimiento. Vuélvelo a activar salvo que tengas un entorno controlado y específico.

Task 8: Comprobar comportamiento de sufijos de búsqueda (por qué fallan nombres cortos)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientGlobalSetting | Format-List SuffixSearchList"

SuffixSearchList : {corp.example, prod.corp.example}

Significado: Cuando tecleas app, Windows puede intentar app.corp.example y otros sufijos.

Decisión: Si los usuarios reportan “los nombres cortos antes funcionaban”, valida la distribución de la lista de sufijos (GPO, opción DHCP 15/119, política VPN). Arregla la lista de sufijos, no la caché.

Task 9: Confirmar qué servidores DNS están establecidos por interfaz (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"

InterfaceAlias ServerAddresses
-------------- ---------------
Ethernet       {10.20.0.10, 10.20.0.11}
VPN            {172.16.50.53}
Wi-Fi          {192.168.1.1}

Significado: Esto deja claro cuando el DNS del Wi‑Fi doméstico o un portal cautivo están en la mezcla.

Decisión: Si ves DNS público o de consumo en una interfaz que no debería ser autoritativa para zonas internas, usa split DNS correctamente (VPN) o ajusta la precedencia de interfaces.

Task 10: Probar alcanzabilidad a servidores DNS (no asumas que “responden”)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.20.0.10 -Port 53"

ComputerName     : 10.20.0.10
RemoteAddress    : 10.20.0.10
RemotePort       : 53
InterfaceAlias   : Ethernet
TcpTestSucceeded : True

Significado: DNS usa principalmente UDP, pero TCP 53 importa para respuestas grandes y reintentos. Esto al menos prueba un camino a TCP 53.

Decisión: Si TCP 53 falla, puede haber reglas de firewall, ACLs del VPN o software de seguridad bloqueando DNS. Eso es una corrección de red/seguridad, no un arreglo de flushing.

Task 11: Detectar si un proxy/PAC se hace pasar por problema DNS

cr0x@server:~$ netsh winhttp show proxy

Current WinHTTP proxy settings:

    Proxy Server(s) :  proxy.corp.example:8080
    Bypass List     :  (none)

Significado: Algunas apps usan los ajustes de proxy WinHTTP. Un proxy roto puede parecer “falla DNS” porque la app no puede obtener nada por nombre.

Decisión: Si el nombre se resuelve pero HTTP falla, inspecciona proxy/PAC y autenticación. No sigas pinchando DNS.

Task 12: Revisar el archivo hosts por minas terrestres

cr0x@server:~$ type C:\Windows\System32\drivers\etc\hosts

# Copyright (c) Microsoft Corp.
# ...
10.30.40.99   app.corp.example

Significado: Esa línea única sobreescribe DNS. Para siempre. Hasta que alguien recuerde que existe.

Decisión: Si el archivo hosts fija una dirección antigua, elimínala y documenta por qué estaba ahí. Si es requerido (raro), gestionalo centralmente, no por conocimiento tribal.

Task 13: Resetear Winsock (sólo cuando coincidan síntomas)

cr0x@server:~$ netsh winsock reset

Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.

Significado: Esto repara algunos problemas a nivel de sockets causados por LSPs o software de red, no “registros DNS”.

Decisión: Úsalo cuando múltiples operaciones de red fallen de maneras extrañas (no sólo un hostname). Espera que requiera reinicio. Si DNS es el único síntoma, probablemente es exagerado.

Task 14: Resetear la pila IP (cuando el comportamiento de la interfaz está corrupto)

cr0x@server:~$ netsh int ip reset

Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting , OK!
Restart the computer to complete this action.

Significado: Restablece la configuración TCP/IP a los valores por defecto.

Decisión: Úsalo cuando sospeches que la pila está envenenada por drivers, clientes VPN o ajustes manuales. Si el problema es claramente DNS aguas arriba, esto no ayudará.

Task 15: Release/renew DHCP (cuando los servidores DNS vinieron por DHCP)

cr0x@server:~$ ipconfig /release

Windows IP Configuration

No operation can be performed on Ethernet while it has its media disconnected.

Significado: Aquí Ethernet no está conectada, así que release no aplica. Eso en sí mismo es una pista.

Decisión: Ejecuta esto en el escenario de interfaz activa. Si los servidores DNS están mal por opciones DHCP, renew puede traer ajustes correctos—si DHCP está configurado correctamente. Si DHCP está mal, arregla DHCP, no los endpoints.

Task 16: Validar si el nombre que falla devuelve múltiples direcciones (y si una está muerta)

cr0x@server:~$ nslookup api.corp.example 10.20.0.10

Server:  dc01.corp.example
Address:  10.20.0.10

Name:    api.corp.example
Addresses: 10.30.40.10
          10.30.40.11
          10.30.40.12

Significado: Round-robin o registros A múltiples pueden hacer que las fallas parezcan “intermitentes” si un backend está caído.

Decisión: Si una IP está muerta, no vacíes cachés en clientes. Elimina/verifica ese registro, arregla la estrategia de balanceo de carga o repara el backend caído.

Errores comunes: síntoma → causa raíz → solución

Aquí es donde la mayoría de equipos pierde tiempo: tratan un síntoma como diagnóstico. Aquí están los reincidentes.

1) “DNS está roto” pero sólo un sitio falla

Síntoma: Sólo app.corp.example falla; todo lo demás se resuelve y funciona.

Causa raíz: Registro DNS obsoleto, expectativas de TTL equivocadas, o nombre con múltiples registros donde una IP está muerta.

Solución: Consulta directamente los servidores autoritativos e inspecciona los registros. Elimina registros malos, baja el TTL para migraciones, asegúrate de que el monitoreo retire endpoints muertos del DNS o que el balanceador los cubra.

2) `nslookup` funciona, el navegador no

Síntoma: nslookup muestra IP correcta, pero Chrome/Edge dice que el nombre no se puede resolver o no puede conectar.

Causa raíz: DoH del navegador activado, caché DNS del navegador obsoleta, problema de proxy/PAC, o el navegador intenta IPv6 primero y falla.

Solución: Revisa ajustes DNS del navegador (incluyendo DNS seguro/DoH), limpia la caché DNS del navegador si hace falta, valida la configuración del proxy y compara resolución IPv4 vs IPv6 y conectividad.

3) Funciona con VPN, falla sin VPN (o al revés)

Síntoma: Los nombres internos se resuelven sólo cuando la VPN está conectada, o la VPN rompe la resolución de nombres públicos.

Causa raíz: Split DNS mal configurado; el VPN empuja servidor DNS para todo; las métricas de interfaz hacen que DNS prefiera el adaptador equivocado.

Solución: Corrige el túnel dividido y las políticas DNS en el cliente/perfil VPN. Asegura que las zonas internas vayan al DNS corporativo y las zonas públicas al resolvedor local (o a un resolvedor sancionado), y que las métricas se comporten como se espera.

4) Timeouts aleatorios tras “endurecimiento de seguridad”

Síntoma: DNS a veces caduca por timeout; los reintentos tienen éxito; las respuestas grandes fallan más a menudo.

Causa raíz: Firewall bloquea TCP 53 o fragmentos; respuestas DNS exceden MTU; software de seguridad intercepta DNS.

Solución: Permite UDP y TCP 53 donde corresponda, valida MTU (especialmente con VPN), y asegura que productos de inspección DNS sean compatibles y estén configurados correctamente.

5) Los nombres cortos dejaron de funcionar

Síntoma: intranet antes resolvía; ahora sólo intranet.corp.example funciona.

Causa raíz: Lista de sufijos de búsqueda cambió (GPO, opción DHCP, política VPN), o cambiaste de red con políticas de sufijo distintas.

Solución: Restaura la lista de sufijos de búsqueda correcta y hazla determinista (GPO para dispositivos unidos al dominio, opciones DHCP bien definidas, ajustes VPN consistentes).

6) “Flushdns lo arregló ayer” se convierte en el proceso del equipo

Síntoma: Gente vacía cachés diariamente; las notas de incidentes dicen “resuelto con flushdns”.

Causa raíz: Cambio frecuente de registros DNS, migraciones con TTL bajo o fallos intermitentes aguas arriba—vaciar sólo fuerza reconsulta y a veces cae en un servidor bueno.

Solución: Añade observabilidad: registra la salud de servidores DNS, mide tasas de NXDOMAIN, verifica replicación/transferencia de zonas y deja de usar endpoints como canarios.

Tres mini-historias corporativas (cómo falla esto en la vida real)

Mini-historia 1: El incidente causado por una suposición equivocada

En una empresa mediana, un equipo migró un servicio interno de una subred a otra. Actualizaron el registro A, vieron la nueva IP resolverse en sus propios portátiles y declararon victoria. Unas horas después, la mitad de los tickets de helpdesk decían “no puedo iniciar sesión” y la otra mitad “a mí me funciona”. El peor tipo de caída: la caída de Schrödinger.

La suposición equivocada fue simple: “Una vez que actualizamos DNS, todo el mundo lo verá rápido”. El TTL no era bajo y algunos clientes conservaban respuestas antiguas. Peor aún, un puñado de servidores de aplicaciones usaba una caché DNS local dentro del runtime, con un TTL por defecto que ignoraba el TTL del registro. Eran los que fallaban más y los que nadie revisó primero.

El equipo de respuesta empezó con consejos para endpoints. Vaciar DNS. Reiniciar navegadores. Rebootear. Predeciblemente, “arregló” algunas máquinas y no tocó los servidores que importaban. Cada flush hacía el troubleshooting más ruidoso porque el estado cacheado se destruía y recreaba constantemente.

La solución fue aburrida: validaron TTL, identificaron los servidores autoritativos, confirmaron replicación y luego desplegaron la migración con una ventana de solapamiento planificada. También documentaron los ajustes de caché a nivel de runtime y los ajustaron para respetar TTLs o usar una librería de resolver con comportamiento de caché sensato.

Después del postmortem, el equipo prohibió anotar “flushdns fixed it” como resolución. Si no puedes decir qué estuvo mal, no lo arreglaste—sólo dejaste de mirarlo.

Mini-historia 2: La optimización que salió mal

Un equipo de seguridad desplegó una base de “mejora de privacidad”: preferir DNS encriptado. Suena bien en abstracto. Habilitaron una política que empujaba clientes hacia DoH con un conjunto pequeño de resolvedores aprobados. En teoría, reducía la exposición en Wi‑Fi hostil. En producción, rompió el split DNS para zonas internas porque esos resolvedores externos no sabían nada de nombres internos.

Al principio, los síntomas fueron sutiles. Sitios públicos funcionaban. Apps internas fallaban intermitentemente, especialmente cuando usuarios estaban fuera de la red. La gente culpó a la VPN. Helpdesk culpó a los portátiles. El equipo de VPN culpó al DNS. Todos tenían razón de la peor manera posible.

Mientras tanto, algunas apps usaban el resolvedor del SO; otras usaban resolvedores embebidos. Así la misma máquina podía resolver git.corp.example en una herramienta y no en otra. Los ingenieros empezaron a hacer lo que hacen bajo presión: escribieron un script “arreglo DNS” que vaciaba cachés, reiniciaba servicios y alternaba adaptadores. Redujo tickets mientras hacía más difícil el análisis de causa raíz.

La solución final no fue “desactivar DoH para siempre”. Fue implementar una política que respetara split DNS: zonas internas por DNS corporativo (típicamente vía VPN) y zonas públicas por DNS encriptado si se permitía. También mejoraron la telemetría: “¿qué resolvedor usó realmente esta consulta?” resultó ser el gráfico que faltaba.

Broma #2: DNS sobre HTTPS es genial hasta que necesitas DNS sobre “¿por qué no se resuelve nada?”.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa financiera tenía un proceso riguroso de cambios DNS. A los ingenieros les molestaba porque requería ticket, revisión por pares y un campo obligatorio de “TTL y plan de rollback”. Parecía burocracia hasta el día en que una zona interna se actualizó accidentalmente con una typo que apuntó un nombre crítico a una IP inexistente.

El incidente comenzó como una tormenta de alertas: fallos de conexión, reintentos, caídas parciales. Alguien sugirió vaciar cachés en la llamada. El comandante del incidente dijo no—mantén el estado, recoge evidencia. Ahí fue cuando la disciplina dio resultados.

Sacaron el conjunto de registros actual de los servidores autoritativos, lo compararon con la solicitud de cambio aprobada y vieron la discrepancia de inmediato. Como el proceso de cambio requería registrar los valores previos, el rollback fue un revert limpio. Porque exigían un plan de TTL, el radio de afectación fue predecible. Y porque tenían un runbook que empezaba con “verifica autoritativos”, no perdieron 45 minutos discutiendo qué portátil tenía qué caché.

La solución tomó minutos, no por genialidad, sino por consistencia. “Aburrido” es un cumplido en operaciones.

Listas de verificación / plan paso a paso

Este es el plan que puedes dar a un equipo y esperar resultados relativamente consistentes. Evita superstición y te obliga a decidir basado en evidencia.

Checklist A: Cuando un usuario dice “DNS está caído”

Obtén el nombre(s) exacto(s) que fallan y el mensaje de error. ¿Un nombre o muchos?
Pide si falla con VPN, sin VPN o en ambos casos.
Ejecuta ipconfig /all y captura servidores DNS y sufijos.
Ejecuta Resolve-DnsName the.name y guarda la salida.
Ejecuta nslookup the.name configured-dns-server para validar aguas arriba.
Si los resultados difieren, identifica qué ruta de resolvedor usa la aplicación (DoH del navegador, proxy).
Sólo después de eso: considera ipconfig /displaydns y /flushdns como prueba controlada.

Checklist B: Cuando sólo fallan nombres internos

Confirma que el usuario está usando servidores DNS corporativos (no el DNS del router doméstico).
Revisa métricas del adaptador VPN y servidores DNS.
Valida que la lista de sufijos de búsqueda incluya el dominio interno.
Consulta directamente al servidor autoritativo de la zona interna.
Inspecciona si el nombre interno existe accidentalmente en DNS público (riesgo de split-brain).

Checklist C: Cuando las fallas son intermitentes

Consulta varias veces y registra respuestas y TTLs. Busca direcciones rotativas.
Prueba conectividad a cada IP devuelta (ping no es suficiente; prueba el puerto/protocolo real).
Busca un backend muerto en un conjunto de registros A múltiples.
Valida alcanzabilidad UDP y TCP 53 a servidores DNS (especialmente sobre VPN).
Revisa si un producto de seguridad está interceptando consultas DNS o reescribiendo respuestas.

Plan paso a paso “detener la hemorragia” para helpdesk

Recopila: hostname que falla, si la VPN está conectada y una marca de tiempo.
Ejecuta y pega: ipconfig /all.
Ejecuta y pega: nslookup failing.name y nslookup failing.name <dns server from ipconfig>.
Si el servidor DNS en ipconfig es incorrecto (p. ej., router doméstico mientras está en VPN), escala a VPN/red con esa evidencia.
Si el servidor DNS es correcto pero las respuestas son incorrectas, escala a operaciones DNS con la evidencia del registro.
Sólo si la caché claramente tiene una respuesta errónea: ejecuta ipconfig /flushdns y vuelve a probar. Documenta antes/después.

Preguntas frecuentes

1) ¿Por qué a veces `ipconfig /flushdns` “lo arregla”?

Porque forzaste una reconsulta, y la siguiente consulta golpeó por casualidad otro servidor DNS, una ruta distinta (la VPN se activó) o el registro acababa de corregirse aguas arriba. Eso es correlación, no una solución duradera.

2) Si no es primero vaciar, ¿qué es?

Identifica los servidores DNS y la interfaz en uso (ipconfig /all más métricas de interfaz), luego compara resultados del resolvedor del SO (Resolve-DnsName) con consultas directas a servidores (nslookup name server).

3) ¿Por qué `nslookup` discrepa con lo que hacen las apps?

nslookup consulta un servidor DNS directamente y no siempre refleja el comportamiento completo del resolvedor de Windows, el comportamiento de sufijos de búsqueda o el DNS específico de la aplicación (como DoH). Es útil, no autoritativo para “lo que hará la app”.

4) ¿Cuál es la diferencia entre limpiar caché DNS y resetear Winsock?

Limpiar caché DNS elimina respuestas nombre→IP cacheadas. Resetear Winsock repara configuración de la capa de sockets y catálogos de proveedores. El reset de Winsock es para síntomas más amplios de “la pila de red está corrupta”, no para un solo registro DNS obsoleto.

5) ¿El servicio Cliente DNS deshabilitado puede causar problemas?

Sí. Deshabilitarlo puede romper comportamiento de caché y rendimiento, y puede afectar cómo el sistema maneja la resolución de nombres. A menos que tengas una razón estricta y probada, mantenlo en funcionamiento.

6) ¿Por qué fallan nombres internos cuando estoy sin VPN?

Porque tus servidores DNS actuales (router doméstico, ISP, resolvedor público) no conocen las zonas internas. La solución es un split DNS correcto y enrutar vía VPN, no vaciar cachés repetidamente.

7) ¿Cómo sé si está involucrado DNS sobre HTTPS?

Si los navegadores resuelven distinto que las herramientas del SO, sospecha DoH. Revisa ajustes de “secure DNS” en el navegador y las políticas empresariales. También puedes comparar resultados entre Resolve-DnsName y el comportamiento del navegador.

8) ¿Y si DNS resuelve, pero las conexiones aún fallan?

Entonces probablemente no sea DNS. Puede ser enrutamiento, firewall, proxy, inspección TLS o el propio servicio. Valida conectividad a la IP y puerto resueltos e inspecciona la configuración del proxy.

9) ¿Deberíamos bajar TTLs para que los cambios DNS se propaguen más rápido?

A veces sí—antes de una migración planificada, baja el TTL con antelación y súbelo después. Pero no consideres TTL bajo como “propagación instantánea”, y no olvides que cachés a nivel de aplicación pueden ignorar TTLs.

10) ¿Editar el archivo hosts es una solución válida?

Como parche de emergencia para una sola máquina, ocasionalmente. Como solución general, no. Evita el control central, complica incidentes y tiende a perdurar más allá de la razón que lo creó.

Conclusión: próximos pasos que realmente perduran

Deja de permitir que ipconfig /flushdns sea el mecanismo de afrontamiento de tu equipo. Es una herramienta, no una cura. La cura es averiguar qué ruta de resolvedor falla y por qué.

Pasos prácticos a seguir:

Adopta la guía rápida de diagnóstico. Úsala en cada ticket “DNS está caído” hasta que sea memoria muscular.
Estandariza la evidencia que recopilas: ipconfig /all, Resolve-DnsName y una consulta directa nslookup name server.
Endurece tu proceso de cambios DNS: exige planificación de TTL y valores de rollback. Hazlo aburrido a propósito.
Audita split DNS y políticas DoH conjuntamente. Si seguridad y redes no se coordinan, los usuarios serán tu banco de pruebas.
Cuando vacíes cachés, documenta el resultado antes/después y la hipótesis que probabas. Si no, sólo estás aporreando botones.