En casi todas las redes que nos encontramos hay dos direcciones de DNS configuradas, y en casi todas se da por hecho lo mismo: que la segunda está ahí para cuando la primera falle. La documentación de Microsoft es más precisa que eso. Dice que «el cliente prueba servidores nuevos solo si los anteriores son inalcanzables», y que cualquier respuesta de nombre inexistente detiene el proceso sin reintentar con el siguiente. Léelo dos veces, porque cambia el diseño: tu segunda entrada cubre el silencio. No cubre el error.
Una hora de oficina por un número entero
El 11 de octubre, a las 16:40 UTC, el servicio de DNS de pago de Control D dejó de contestar. No en una región: en todas sus ubicaciones, por todos los protocolos y en todos los dispositivos, según su propio informe. Las consultas de los clientes de pago se quedaron sin respuesta desde las 16:42. La recuperación empezó a las 17:31 y quedó completa a las 17:35. El servicio gratuito siguió funcionando todo el rato.
La causa, contada por ellos sin adornos: una actualización de su API del 16 de septiembre había empezado a guardar una anulación por dominio como número entero donde el software de DNS esperaba texto. El cambio llevaba casi un mes ahí sin molestar a nadie, porque nadie había guardado todavía uno de esos ajustes. El 11 de octubre alguien lo guardó por primera vez, el valor se propagó de golpe a todos los servidores de DNS del plan de pago, y un fallo en el manejo de errores hizo que el software se parase en vez de saltarse el valor que no sabía leer. Lo que arreglaron después lo cuentan igual de claro: ahora los valores ilegibles se apartan y se registran en vez de parar el servicio, la API vuelve a guardar texto, y la configuración pasará a desplegarse por fases, como ya hacían con el software.
Nos interesa una cosa de ese párrafo, y no es el bug. Es que el cambio que rompió el servicio no era software: era configuración, y la configuración no pasaba por el despliegue por fases que sí tenía el código. Es exactamente el mismo reparto que hay en la mayoría de las casas: el código va con revisión, pruebas y ventana; el ajuste va en caliente y a todas partes. Ellos lo han corregido. La pregunta honesta es cuántos de nosotros podemos decir lo mismo.
El reloj que no mira nadie
Todo post-mortem cuenta lo que rompió el proveedor. Ninguno cuenta lo que hizo tu red durante esos 54 minutos, y eso es lo que decide si tu gente notó un parpadeo o se quedó mirando la pantalla. Esa parte también está escrita, solo que en un documento de soporte que no sale en ningún titular. Windows, con dos servidores DNS configurados en el adaptador, se comporta así:
La buena noticia es ese 1: si el primario se queda callado, Windows pasa al segundo en un segundo, y una oficina normal apenas lo nota. La mala es todo lo demás. Si tienes tres o más servidores apuntados, el cuarto y siguientes no se preguntan hasta los 4 segundos —la propia documentación avisa de que, si el único alcanzable está en la posición 4 o posterior, hay un retraso mínimo de 4 segundos y una aplicación con un tiempo de espera más corto fallará sin que el DNS esté caído—. Y en Linux la cuenta es peor de serie: el resolver de glibc espera 5 segundos por servidor antes de pasar al siguiente, con dos intentos por defecto y un máximo de tres servidores leídos de >/etc/resolv.conf. Un resolver mudo cuesta ahí cinco segundos por consulta, y hay aplicaciones que resuelven decenas de nombres para pintar una pantalla.
Esos cinco segundos llevan una excepción grande, y conviene decirla antes de que alguien la use en una reunión: son los del resolver de glibc hablando con servidores reales. En un Ubuntu o un Fedora de serie, /etc/resolv.conf apunta a 127.0.0.53 y quien decide es systemd-resolved, que lleva su propia cuenta de reintentos y su propia lista; ahí lo que vale es lo que diga resolvectl status, y los tiempos no son estos. Míralo antes de dar por buena ninguna de las dos cifras en tu parque.
Hay un detalle más que cambia el diseño. Cuando el cliente de Windows se pasa al servidor alterno, se queda en él hasta que ese alterno falle o hasta que venza >ServerPriorityTimeLimit, que son 15 minutos por defecto. Es decir: el proveedor se recupera a las 17:35 y tus equipos pueden seguir preguntando al segundo servidor hasta un cuarto de hora después. Para disponibilidad es sensato —evita ir y venir—. Para una política de filtrado, como veremos, es justo lo contrario.
El silencio se cubre; el error, no
Aquí está el corazón del asunto, y no es opinión nuestra. El documento de tiempos de espera de Microsoft lo dice en dos frases secas, válidas para cualquier cliente de Windows: «cualquier respuesta de nombre inexistente hará que el proceso se detenga: el cliente no reintenta con el siguiente servidor si la respuesta fue negativa» y «el cliente prueba servidores nuevos solo si los anteriores son inalcanzables». En la guía de recomendaciones aparece la versión larga —«solo un fallo en responder hará que el cliente DNS cambie de servidor preferido; recibir una respuesta autoritativa pero incorrecta no hace que el cliente pruebe otro servidor»—, escrita pensando en controladores de dominio, pero apuntando a lo mismo: el disparador de la conmutación es el silencio, nunca el contenido.
Traducido a lo que pasa un martes a las nueve: si tu resolver contesta >NXDOMAIN al nombre de tu ERP porque una lista de filtrado se pasó de rosca, o devuelve una dirección vieja porque una zona no replicó, el segundo servidor no entra. No hay conmutación. No hay alerta, porque el puerto 53 responde y tu monitorización lo ve verde. Lo que hay es gente que no puede trabajar y un servicio que, técnicamente, está disponible. Ese es el fallo que la redundancia que compraste no cubre. En lo que nos llega a nosotros aparece más veces que una caída global de un proveedor, aunque no tenemos cifras públicas que lo sostengan: tómalo como lo que es, una impresión de taller.
Dos direcciones, un solo plano de configuración
Vuelve al 11 de octubre con esto en la cabeza. El valor malo se propagó a todos los servidores del plan de pago a la vez. Si tenías las dos direcciones de ese proveedor apuntadas en el DHCP —que es exactamente lo que recomienda cualquier guía de instalación—, no tenías dos servidores: tenías dos puertas al mismo sitio. El reparto geográfico de anycast te da diversidad de camino, que es real y sirve para un corte de fibra o para un nodo caído. No te da diversidad de configuración, y el fallo de ese día fue de configuración.
No es un caso aislado ni un proveedor pequeño haciéndolo mal. El 14 de julio de 2025, el resolver público 1.1.1.1 de Cloudflare dejó de servir a la mayoría de sus usuarios durante 62 minutos, de 21:52 a 22:54 UTC. La causa: un error de configuración interno introducido el 6 de junio que estuvo más de cinco semanas latente, sin efecto, hasta que otro cambio en el mismo servicio lo activó y retiró globalmente los prefijos del resolver. Sus palabras: «esta caída fue el resultado de un error de configuración interno y no de un ataque ni de un secuestro BGP». En los dos casos el cambio llevaba semanas guardado sin hacer nada, y cuando se activó lo hizo en todas las ubicaciones al mismo tiempo, que es justamente lo que el reparto geográfico no puede evitar.
Esta forma la hemos contado ya dos veces desde otros ángulos, porque se repite en capas distintas de la misma red: cuando el fallo está en el cerebro y no en las patas, el plano de control es lo primero que se cae; y en la factura de telefonía, donde dos operadores en la factura pueden ser un solo núcleo en la red. Cambia la tecnología; la pregunta es siempre la misma: ¿qué comparten de verdad mis dos caminos?
Cuándo NO hay que poner un segundo proveedor
El reflejo después de leer todo lo anterior es poner un resolver público de otra casa como segunda entrada del adaptador. En un dominio de Active Directory eso es un error, y tampoco lo decimos nosotros: «no configures los ajustes de DNS del cliente para que apunten a los servidores DNS de tu proveedor de Internet. Si lo haces, puedes tener problemas al intentar unir el servidor al dominio o al iniciar sesión en el dominio desde ese equipo. En su lugar, el servidor DNS interno debe configurar el reenvío a los servidores DNS del proveedor para resolver nombres externos.»
A ese motivo le añadimos el nuestro, que es de seguridad y rara vez se dice en voz alta. Si pagas un DNS que filtra —y hay quien lo paga sin saberlo, porque viene dentro de otro producto—, poner al lado un resolver público sin filtrar es documentar tu propio camino de evasión. Y ahora junta las dos piezas de este post: un parpadeo de un segundo basta para que el equipo se pase al alterno, y una vez allí se queda hasta 15 minutos. Un microcorte a las 9:03 puede dejar un puesto resolviendo fuera de tu política hasta las 9:18, sin que nadie se entere y sin una sola línea en ningún registro.
Dónde va la redundancia, entonces: en el resolver que controlas tú. Dos resolutores internos, cada uno con reenvío a dos proveedores independientes o a los servidores raíz. El cliente ve dos direcciones internas y una sola política; la diversidad de proveedor vive en la capa donde puedes razonarla, medirla y cambiarla en caliente sin tocar 200 puestos. Y la excepción honesta, porque existe: si eres una empresa de ocho personas sin servidor propio, dos resolutores públicos en el DHCP es un compromiso razonable. Lo único que pedimos es que sea una decisión escrita —«aceptamos que el filtrado es de mejor esfuerzo»— y no un descuido que descubres el día del incidente.
La comprobación de quince minutos
Esto se contesta hoy, con lo que ya tienes instalado y sin comprar nada. Empieza por mirar lo que de verdad reparte tu DHCP, no lo que crees que reparte:
# Windows: la lista real y su orden, por interfaz
Get-DnsClientServerAddress -AddressFamily IPv4
# Linux: si resolv.conf apunta a 127.0.0.53, la lista buena es la segunda
cat /etc/resolv.conf
resolvectl status
# Cuánto tarda cada resolver, uno por uno
for s in 10.0.0.1 10.0.0.2; do
echo -n "$s "
dig +tries=1 +time=2 @$s everywan.com +noall +stats | grep "Query time"
done- Escribe la lista por sede, en orden. Una tabla de tres columnas: dirección, quién la opera y —la que nadie rellena— quién controla su plano de configuración. Dos direcciones del mismo proveedor son una entrada en esa tercera columna, por mucho que estén en continentes distintos.
- Mide el silencio, no lo supongas. Bloquea el primario en el cortafuegos del puesto (una regla que descarte udp/53 hacia esa dirección) y cronometra una resolución real con la caché vacía, que si no medirás la caché y te saldrá cero:
Clear-DnsClientCache; Measure-Command { Resolve-DnsName tu-erp.interno }en Windows,time getent hosts tu-erp.internoen Linux (y comprueba antes si tienes nscd o resolved cacheando por debajo). El número que salga es el que notará tu gente. - Compara las respuestas, no solo que respondan. Pregunta el mismo nombre interno a cada resolver de la lista y pon los resultados uno al lado del otro. Si uno devuelve una dirección y otro un nombre inexistente, acabas de encontrar el fallo que tu segunda entrada no cubre, y lo has encontrado un día tranquilo en vez de un lunes a las nueve.
- Alerta sobre la respuesta. La comprobación que vale es «este nombre resuelve a esta dirección desde esta sede», no «el puerto 53 contesta». Nosotros monitorizamos con Zabbix y SmokePing, y la regla de la casa es que una alerta tiene que doler: aplicada al DNS, eso significa comprobar el registro que vuelve, no que el puerto conteste. La caída silenciosa la ve cualquiera; la respuesta equivocada no la ve nadie.
- Decide y escribe qué quieres cuando tu resolver no sepa contestar. O no contesta y la oficina se para, o contesta sin filtrar y pierdes la política durante el incidente. No hay tercera opción, y la decisión no es técnica: es del negocio. Lo grave no es elegir una u otra, es llegar al incidente sin haber elegido.
Dónde encaja esto en lo que hacemos
Operamos red propia —con BGP, tránsito y peering—, y de ahí sale este post: la parte difícil del DNS nunca ha sido montarlo, sino decidir qué pasa cuando contesta mal y tener forma de enterarte. Es lo que hacemos en redes y comunicaciones, y casi siempre empieza por la misma pregunta aburrida: a quién pregunta de verdad cada sede, y dónde está puesta la diversidad. Rara vez está donde dice el plano.
Si quieres que hagamos juntos la tabla de tres columnas de tus sedes y midamos de verdad cuánto cuesta un resolver callado en tus puestos, hablamos. Es una tarde. Si sale que ya estaba bien montado, te lo decimos y aquí no ha pasado nada.
Fuentes. Las fechas, la duración, el alcance y la causa del incidente del 11 de octubre de 2026 (16:40–17:35 UTC; consultas sin respuesta desde las 16:42; restauración iniciada a las 17:31; afectados todos los planes de pago en todas las ubicaciones y protocolos, no el servicio gratuito; actualización de la API del 16 de septiembre que guardaba la anulación por dominio como entero en vez de texto; fallo de manejo de errores que paraba el servicio en lugar de saltarse el valor; y las medidas posteriores) proceden del informe público del incidente publicado por Control D. Los tiempos de espera del cliente DNS de Windows (0-1-2-4-8-10 segundos, el comportamiento con uno, dos y tres o más servidores, y el aviso sobre los servidores en posición 4 o posterior) están en «DNS client resolution timeouts» de Microsoft Learn. Las dos citas sobre cuándo cambia de servidor el cliente, el valor por defecto de 15 minutos de ServerPriorityTimeLimit y la recomendación de no apuntar los clientes a los DNS del proveedor de Internet sino usar reenvío desde el DNS interno están en «Recommendations for DNS client settings», del mismo sitio. Los valores por defecto del resolver de glibc —tiempo de espera de 5 segundos, 2 intentos y un máximo de tres servidores— están en la página de manual resolv.conf(5). La caída de 1.1.1.1 del 14 de julio de 2025 (62 minutos, de 21:52 a 22:54 UTC, con el error de configuración introducido el 6 de junio y la cita sobre que no fue un ataque ni un secuestro BGP) está en el informe público de Cloudflare. Las traducciones de las citas son nuestras. Son criterio nuestro, y no afirmaciones de ninguna de esas fuentes: la lectura de que el plano de configuración de un proveedor es un dominio de fallo compartido por sus direcciones, la consecuencia de juntar el cambio a servidor alterno con los 15 minutos de permanencia en una política de filtrado, la recomendación de poner la diversidad de proveedor en el reenvío y no en el adaptador, y la comprobación de quince minutos. everyWAN presta servicios gestionados de red y seguridad: el conflicto de interés queda declarado. No revendemos ni somos partner de ninguno de los proveedores de DNS mencionados. Foto de portada: «The inside of a wiring closet at a small public university, 2014», de SnopdouS, Wikimedia Commons, CC0 1.0.
Microsoft 365
ES 
CAT 
EN