Defaults.Exposed › Soluciones › Configuración de servidores de nombres (diversidad y SOA)

Cómo arreglar Configuración de servidores de nombres (diversidad y SOA)

Tus servidores de nombres son el directorio que le dice a todo internet dónde encontrar tu sitio web y tu correo. Si todos están en una sola red y esta cae, tu negocio desaparece de internet en el mismo instante —sin sitio, sin correo, sin nada— y un ajuste de reloj descuidado en esos servidores puede dejar los cambios que hagas atascados durante días.

En resumen, para tu negocio: Si cada servidor de nombres de tu dominio vive en una sola red, una caída o un ataque a esa red deja tu sitio web Y tu correo fuera de línea a la vez: sigues pagando personal y anuncios mientras ningún cliente puede alcanzarte. Aparte, unos temporizadores SOA mal configurados pueden dejar tus cambios de DNS (un nuevo servidor, un cambio de proveedor de correo, una redirección de emergencia) propagándose durante días en lugar de horas.

Lo que esto te puede costar

La única red en la que están todos tus servidores de nombres tiene una mala tarde —una caída o un ataque DDoS— y tu sitio web y tu correo desaparecen al mismo tiempo. Los clientes reciben páginas de error, tu bandeja de ventas rebota, y lo único que puede hacer tu informático es esperar a que se recupere la red de otra persona.
El equipo de seguridad de un cliente grande hace una comprobación de proveedor, ve todos tus servidores de nombres en un solo proveedor sin redundancia y anota tu dominio como un punto único de fallo: fricción en un contrato que de otro modo habrías ganado.
Te mudas a un nuevo hosting web o cambias de proveedor de correo, pero un temporizador de «refresh» equivocado en tu registro SOA hace que otros servidores DNS sigan repartiendo tu dirección antigua durante días, de modo que algunos clientes aterrizan en un sitio muerto y tu correo se parte en dos.
Un incidente de seguridad te obliga a redirigir el tráfico con urgencia, pero tus temporizadores SOA le dicen al mundo que cachee tus registros antiguos durante una semana, así que el cambio que hiciste hace una hora aún no ha llegado a media internet mientras el problema continúa.
Tus dos servidores de nombres son técnicamente dos nombres, pero resuelven al mismo rack en la misma red, así que la redundancia que crees tener es una ilusión, y un solo fallo sigue tumbándolo todo.

Por qué importa. Cada visita a tu sitio web y cada correo que se te envía empieza con una consulta a tus servidores de nombres. Son los cimientos sobre los que se asienta el resto de tu presencia en línea. Si esos cimientos no tienen redundancia, un solo fallo lo derriba todo a la vez; si sus valores de tiempo están mal, cada cambio que hagas tarda en surtir efecto, justo cuando menos puedes permitírtelo.

Qué es esto, en palabras llanas

Antes de que nadie pueda alcanzar tu sitio web o enviarte un correo, su ordenador tiene que hacer una pregunta sencilla: «¿dónde vive realmente este dominio?». Los servidores que responden a esa pregunta son tus servidores de nombres. Son la entrada de directorio de toda tu presencia en línea: lo primerísimo que toca cada visitante y cada correo, antes incluso de que entren en juego tu sitio o tu bandeja de entrada.

Esta página cubre dos partes de acertar con ese directorio:

Diversidad — ¿tienes al menos dos servidores de nombres, y están en partes genuinamente separadas de la red, para que una sola caída no pueda silenciarlos todos a la vez?
El registro SOA — un pequeño registro de «inicio de autoridad» que contiene los valores de tiempo que controlan cuánto confía y cachea el resto de internet tus respuestas DNS. Si los temporizadores están mal, cada cambio que hagas tarda más en llegar al mundo.

Ninguna de las dos es glamurosa. Ambas son cimientos. Cuando están bien, nunca piensas en ellas; cuando están mal, te enteras en el peor momento posible.

Lo que esto puede costarte

Todo fuera de línea a la vez. Si todos tus servidores de nombres viven en una sola red y esa red tiene una caída o recibe un ataque DDoS, tu sitio web y tu correo se apagan juntos. Esto no es teórico: el ataque a un solo proveedor de DNS ha dejado a empresas grandes y con buenos recursos fuera de internet durante buena parte de un día. Con redundancia entre redes, un fallo es sobrevivible; sin ella, es total.
Un acuerdo perdido en una comprobación de proveedor. El equipo de seguridad o de compras de un cliente grande hace una comprobación antes de firmar, ve todos tus servidores de nombres concentrados en un proveedor sin respaldo y marca tu dominio como un punto único de fallo. Es el tipo de marca pequeña y evitable que añade fricción a un contrato que de otro modo ganarías.
Cambios que no cuajan. Cambias de hosting web, mudas de proveedor de correo o necesitas redirigir tráfico con prisa. Un temporizador «refresh» o «expire» equivocado en tu registro SOA hace que otros servidores DNS sigan sirviendo tu respuesta antigua durante días. La mitad de tus clientes aterrizan en el sitio nuevo, la mitad en el muerto; parte del correo fluye al proveedor antiguo, parte al nuevo. El cambio que hiciste hace una hora aún no está hecho.
Una emergencia que no puedes terminar deprisa. Durante un incidente de seguridad necesitas apartar el tráfico de un servidor comprometido ahora. Si tus temporizadores SOA le dijeron al mundo que cacheara tus registros una semana, tu solución se arrastra por internet mientras el problema sigue mordiendo.
Redundancia que no es real. Tienes dos servidores de nombres, así que supones que estás cubierto, pero ambos resuelven al mismo rack en la misma red. El primer fallo de hardware se lleva el lote, y la red de seguridad con la que contabas nunca estuvo ahí.

Qué es en realidad

Diversidad de servidores de nombres. Tu dominio debería listar al menos dos servidores de nombres, e idealmente deberían asentarse en rutas de red genuinamente independientes, no solo dos nombres que apuntan a la misma máquina. Entre bastidores, cada nombre de servidor de nombres resuelve a una o más direcciones IP, y lo que de verdad importa es si esas direcciones ocupan partes distintas del enrutamiento de internet. Un proveedor de DNS serio reparte sus servidores de nombres por muchos bloques de red y ubicaciones separadas en todo el mundo, así que incluso dos servidores de nombres del mismo proveedor te dan redundancia real e independiente. El caso de fallo es el opuesto: un único hosting pequeño donde ambos «servidores de nombres» son la misma máquina, de modo que un fallo es total.

Una nota para el lector técnico: nuestra comprobación cuenta tus registros NS y luego mira cuánta diversidad de red genuina hay detrás de ellos. La señal principal es la dispersión de bloques de red IP distintos a los que resuelven los servidores de nombres (a grandes rasgos, rangos /16 para IPv4 y /32 para IPv6), con el número de nombres de proveedor distintos como respaldo. Esto acredita deliberadamente a los hiperescaladores Anycast —Cloudflare, Google, AWS Route 53, Azure DNS—, que anuncian una identidad de red desde muchas rutas de enrutamiento globalmente separadas y, por tanto, ofrecen diversidad real incluso desde una sola marca. Tener menos de dos servidores de nombres puntúa cero en esta comprobación y se trata como severidad alta, porque es un punto único de fallo sin mitigar para todo el dominio.

El registro SOA. Toda zona DNS tiene exactamente un registro Start of Authority. Nombra al servidor de nombres primario y al contacto administrativo, lleva un número de serie que se incrementa con cada cambio y —la parte que importa para tu negocio— contiene cuatro temporizadores:

Refresh — con qué frecuencia los servidores de nombres secundarios vuelven a comprobar el primario en busca de cambios. Buen rango: aproximadamente de 1 a 24 horas (3.600-86.400 segundos).
Retry — cuánto tardar en reintentar si un refresh falla. Buen rango: aproximadamente de 5 a 60 minutos (300-3.600 segundos).
Expire — cuánto tiempo siguen los secundarios sirviendo tus registros si no pueden alcanzar el primario en absoluto. Buen rango: aproximadamente de 1 a 4 semanas (604.800-2.419.200 segundos).
Minimum TTL — el suelo de cuánto tiempo se cachean las respuestas (incluidas las de «este nombre no existe»). Debería ser un valor positivo sensato; 300 segundos es una elección común.

Cómo es lo «bueno»: un SOA que existe, tiene un contacto administrativo válido y lleva temporizadores dentro de esos rangos. Los valores fuera de rango no son fatales, pero o bien ralentizan tus cambios (temporizadores demasiado largos) o bien cargan tus servidores de nombres sin necesidad (demasiado cortos). Un SOA ausente o genuinamente roto es el caso más grave.

Cómo solucionarlo (gratis, ~15 minutos)

Esta parte es para quien gestione tu dominio o tu DNS; si no eres tú, pásale este apartado. La solución es gratuita; solo cobramos por monitorizar que se mantenga arreglado.

Paso 1 — Asegúrate de tener al menos dos servidores de nombres en infraestructura diversa.

Comprueba lo que tienes hoy. Ejecuta dig NS tudominio.com (o usa cualquier herramienta web de «consulta DNS») y lee los servidores de nombres. Dos o más es el mínimo.
Si solo tienes uno, o ambos están en un único hosting pequeño, mueve tu DNS a un proveedor que te dé redundancia por defecto. Prácticamente todo proveedor serio lo hace:
- Cloudflare — asigna dos servidores de nombres repartidos por su red Anycast global automáticamente al añadir un dominio.
- AWS Route 53 — cada zona alojada obtiene cuatro servidores de nombres en redes Route 53 separadas.
- Google Cloud DNS / Microsoft 365 / Azure DNS — provisionan de forma similar varios servidores de nombres en infraestructura independiente.
Para cambiar, ajusta los servidores de nombres de tu dominio en tu registrador (donde compraste el dominio, p. ej. GoDaddy, Namecheap) a los que te dé tu nuevo proveedor de DNS. Este cambio puede tardar de 24 a 48 horas en propagarse del todo.
Para resiliencia con doble red, las empresas grandes o de mayor riesgo pueden usar DNS secundario de un segundo proveedor independiente (p. ej. Cloudflare + Route 53, o NS1 + Cloudflare). Para la mayoría de las empresas pequeñas esto es opcional: un solo proveedor de prestigio ya te da redundancia real entre redes.

Paso 2 — Comprueba (y si hace falta, arregla) tus temporizadores SOA.

Ejecuta dig SOA tudominio.com y lee los valores de refresh, retry, expire y minimum-TTL.
Compáralos con los rangos de arriba. En la gran mayoría de los casos, tu proveedor de DNS ya ha puesto valores por defecto sensatos y no hay nada que hacer.
Si un valor está fuera de rango, arréglalo donde esté alojado tu DNS:
- En proveedores gestionados (Cloudflare, Route 53, Google, Azure) el SOA está en gran medida gestionado por ti; normalmente lo ajustas a través de los ajustes de DNS del proveedor o de su soporte, en lugar de editarlo a mano.
- En un servidor de nombres autogestionado (BIND, PowerDNS) edita la línea SOA en el archivo de zona directamente y recarga la zona, recordando subir el número de serie para que los secundarios recojan el cambio.
Tras cualquier cambio, vuelve a ejecutar las consultas para confirmar que tanto la lista de servidores de nombres como los temporizadores SOA tienen buen aspecto.

Errores habituales

Tratar «dos nombres» como «dos redes». Dos nombres de servidor de nombres que resuelven a la misma máquina o rack son un punto único de fallo disfrazado. Lo que importa son las rutas de red independientes, no el recuento de nombres.
Suponer que más es siempre mejor, sin diversidad. Cinco servidores de nombres todos en un hosting frágil no son más seguros que uno. La diversidad gana a la cantidad.
Poner los temporizadores demasiado agresivos. Bajar el refresh o el minimum-TTL del SOA a tope para «hacer los cambios instantáneos» solo machaca tus servidores de nombres y puede empeorar las caídas, con poco beneficio real. Los valores por defecto sensatos ya equilibran velocidad contra carga.
Poner expire demasiado bajo. Si los secundarios dejan de servir tu zona demasiado pronto durante una caída del primario, un percance recuperable se convierte en una caída total. Mantén el expire en el rango de semanas.
Editar una zona a mano y olvidar el número de serie. En servidores de nombres autogestionados, los secundarios solo recogen los cambios cuando el serial del SOA aumenta. Cambia registros pero deja el serial igual y tu «solución» nunca se propaga.
Dejar el DNS en el ajuste por defecto escueto del registrador. El DNS integrado de algunos registradores es una configuración única y mínima. Mover el DNS a un proveedor en condiciones suele darte redundancia y temporizadores SOA sensatos de una sola vez.

En resumen

Tus servidores de nombres y su registro SOA son los cimientos sobre los que se asienta todo lo demás. Dos servidores de nombres en redes genuinamente separadas significan que un solo fallo no puede dejar todo tu negocio fuera de línea a la vez; unos temporizadores SOA sensatos significan que los cambios que hagas llegan al mundo con prontitud. Ambos son gratuitos de acertar, ambos suelen estar ya en buena forma en cuanto estás en un proveedor de DNS en condiciones, y ambos merecen una comprobación de dos minutos, porque el día en que importan es el día en que menos puedes permitirte que estén mal.

Preguntas frecuentes

No soy una persona técnica, ¿es esto algo que pueda resolver yo?

No necesitas entender los entresijos del DNS. La diversidad de servidores de nombres suele estar resuelta por ti en cuanto pones tu dominio en un proveedor de DNS serio (Cloudflare, AWS Route 53, tu hosting): te dan dos o más servidores de nombres repartidos por su red automáticamente. Los temporizadores SOA también suelen venir bien puestos por defecto. El trabajo es sobre todo comprobar lo que tienes y, si estás en una configuración frágil de uno solo, mudarte a un proveedor que te dé redundancia. Pásale el apartado técnico de abajo a tu informático o proveedor de IT; la solución es gratuita.

¿Cuál es la diferencia entre las dos cosas que comprueba esta página?

Dos partes relacionadas de unos mismos cimientos. La primera —la diversidad de servidores de nombres— es sobre resiliencia: ¿tienes al menos dos servidores de nombres, y están en partes genuinamente distintas de la red para que un fallo no pueda tumbarlos todos? La segunda —el registro SOA— es sobre tiempos: contiene los valores de reloj que le dicen al resto de internet cuánto tiempo confiar y cachear tus respuestas DNS. Una es «no pongas todos los huevos en la misma cesta»; la otra es «ajusta los temporizadores para que los cambios fluyan limpiamente».

Tengo dos servidores de nombres de la misma empresa, ¿es suficiente?

Normalmente sí, si esa empresa es un proveedor de DNS serio. Los grandes proveedores como Cloudflare, Google y AWS reparten sus servidores de nombres por muchas redes y ubicaciones separadas en todo el mundo, así que dos nombres suyos sí se asientan en infraestructura independiente: eso es redundancia real. El caso de riesgo es un único hosting pequeño donde ambos «servidores de nombres» son en realidad la misma máquina o el mismo rack. Si quieres doble red, puedes usar servidores de nombres de dos proveedores independientes, pero para la mayoría de las empresas pequeñas un solo proveedor de DNS de prestigio basta de sobra.

¿Qué le hace a mi negocio el valor «refresh» o «expire» del SOA?

Son temporizadores que indican a otros servidores DNS cuánto esperar antes de volver a comprobar tus registros, y cuánto seguir sirviéndolos si no pueden alcanzarte. Puestos demasiado altos, un cambio que hagas —una IP de servidor nueva, un nuevo proveedor de correo, una redirección de emergencia— tarda mucho más en llegar a todos. Puestos demasiado bajos, tus servidores de nombres reciben tráfico extra innecesario. Unos valores por defecto sensatos (refresh medido en horas, expire en semanas) mantienen los cambios fluyendo con prontitud sin dejar de ser robustos durante una caída. La mayoría de los proveedores los ponen bien de fábrica.

¿Esto cambia mi nota, y cuánto?

Sí, ambas partes cuentan para tu puntuación de DNS. Tener menos de dos servidores de nombres se trata como un hueco grave porque es un punto único de fallo para toda tu presencia en línea. Un SOA mal configurado es un problema más moderado: no te deja fuera de línea, pero ralentiza tu capacidad de responder cuando algo cambia. Ambos son gratuitos de arreglar y, para la mayoría de las empresas, ya están en buena forma una vez que estás en un proveedor de DNS en condiciones.

¿Hay truco? ¿Tengo que pagaros para arreglar esto?

No. Conseguir servidores de nombres redundantes y temporizadores SOA sensatos es gratis en todos los grandes proveedores de DNS, y los pasos de abajo son todo lo que necesitas. Solo cobramos si más adelante quieres que sigamos vigilando tu dominio y te avisemos si la redundancia vuelve a caer a un punto único de fallo o los temporizadores se descuadran.