Cómo evitar fallos de DNS y dominios vencidos en los sitios de tus clientes

Los errores HTTP vienen con un código de estado y los fallos del servidor dejan logs. Cuando falla el DNS, el sitio simplemente deja de estar donde su nombre dice que está. Los visitantes ven un aviso del navegador de que no se puede acceder al sitio, o la página de otra persona.

Si eres freelancer y gestionas sitios de clientes, tres causas explican casi todo:

• El dominio venció. La renovación automática falló porque la tarjeta guardada había caducado, o los recordatorios de renovación llegaban a una dirección que nadie lee, como la antigua del cliente.
• Un registro salió mal en una migración. El registro A sigue apuntando al servidor antiguo, o un error tipográfico hace que no apunte a ninguna parte.
• Se cambiaron los servidores de nombres. Alguien trasladó el dominio a un nuevo proveedor de DNS, o una transferencia de registrador los cambió, y los registros no se volvieron a crear en el nuevo lugar.

Qué pasa realmente cuando vence un dominio

Para dominios genéricos como .com, .net y .org, la Expired Registration Recovery Policy de ICANN fija la secuencia:

1. El registrador envía recordatorios al titular registrado del dominio, normalmente por correo electrónico: alrededor de un mes y alrededor de una semana antes del vencimiento, y al menos uno más en los cinco días posteriores. Si el cliente registró el dominio, los recordatorios le llegan al cliente.
2. Tras el vencimiento, el registrador debe interrumpir la ruta de resolución DNS del dominio. Entonces el nombre deja de resolver o lleva a la página de aterrizaje del registrador, que debe indicar que el registro del dominio expiró y cómo renovarlo. Así que el sitio no siempre "desaparece": puede quedar sustituido por una página de renovación que sigue cargando.
3. Si nadie lo renueva y el registro del dominio se elimina, sigue un período de gracia de 30 días llamado Redemption Grace Period, durante el cual el operador del registro desactiva la resolución DNS. A partir de ahí las consultas fallan para todos, normalmente con NXDOMAIN ("no existe ese dominio"), hasta que se restaura el dominio.

Los dominios de país como .sk, .cz, .de o .uk siguen las reglas de su propio operador de registro, así que revisa las condiciones del registrador para el dominio de cada cliente.

La conclusión práctica: para una comprobación que solo lee el código de estado, el paso 2 puede parecer un sitio que funciona.

Un protocolo de diagnóstico

Cuando un cliente te diga "el sitio desapareció", ejecuta esto antes de tocar nada. Sustituye example.com por el dominio del cliente.

Mira el camino desde los servidores raíz hasta la respuesta, y dónde se corta:

dig +trace example.com

Compara los servidores de nombres que tiene el operador del registro con los que esperas:

dig +short NS example.com
whois example.com | grep -iE "name ?server|nserver"

Comprueba la fecha de expiración (el nombre del campo varía según el operador del registro, y algunos operadores de dominios de país no la publican):

whois example.com | grep -iE "expir"

Pregunta a cada servidor de nombres autoritativo su número de serie SOA. Si los números son distintos, un servidor de nombres aún no ha recibido la última versión de la zona, o un cambio todavía se está copiando:

for ns in $(dig +short NS example.com); do echo "$ns $(dig +short SOA example.com @$ns | awk '{print $3}')"; done

Compara un resolver público con la respuesta autoritativa. Si el servidor autoritativo está bien y el resolver público no, estás esperando a que caduque una caché, no ante un registro incorrecto:

dig +noall +answer example.com @1.1.1.1
dig +noall +answer example.com @<one of the NS names above>

Después corrige en el lugar adecuado: un dominio vencido en el registrador, servidores de nombres incorrectos en el registrador, un registro incorrecto en el proveedor de DNS.

Antes de una migración: baja primero el TTL

Los resolvers guardan una respuesta durante el tiempo que indica su TTL. Si el registro A tiene un TTL de 86400 segundos (un día), algunos visitantes pueden seguir llegando al servidor antiguo durante un día después de que lo cambies.

1. Comprueba el TTL actual en el servidor autoritativo: dig +noall +answer example.com @<nameserver> (segunda columna).
2. Bájalo a 300 segundos al menos un TTL antiguo antes del cambio; con un TTL de un día, uno o dos días antes.
3. Haz el cambio y luego confírmalo en el servidor autoritativo y en un resolver público.
4. Mantén el servidor antiguo en marcha hasta que haya pasado el TTL antiguo.
5. Vuelve a subir el TTL cuando todo apunte al nuevo lugar.

Qué monitorear

• La fecha de expiración de cada dominio de cliente, con recordatorios que te lleguen a ti, no solo al cliente.
• Los registros que importan: el registro A (o AAAA) del sitio y el registro MX si el correo del cliente depende de él.
• El valor de esos registros, no solo que existan, para detectar un registro que apunte al servidor equivocado.
• La propia página: durante la fase de la página de renovación descrita arriba, solo una comprobación que lee el contenido de la página nota la diferencia.

Qué cubren el monitor DNS y las alertas de dominio de Baromio

• Monitor DNS: consulta un tipo de registro (A, AAAA, MX, CNAME o TXT) de un nombre de host, a través del resolver normal del servidor de Baromio, con la frecuencia que permita tu plan: cada 5 minutos en Free, cada minuto en Pro, cada 30 segundos en Business. Falla cuando no vuelve ningún registro. Si completas el campo Valor Esperado, también falla cuando el primer registro de la respuesta no contiene ese texto, sin distinguir mayúsculas de minúsculas, así que google.com coincide con un registro MX como aspmx.l.google.com. En un nombre con varios registros A el primero puede variar, así que ahí deja vacío el valor esperado o usa una parte que todos compartan.
• Lo que no hace el monitor DNS: comprueba desde un solo servidor, no compara servidores de nombres ni números de serie SOA y no prueba la propagación entre resolvers. Para eso, usa el protocolo de arriba.
• Expiración de dominio: activa Monitorear Expiración de Dominio en un monitor HTTP o de palabra clave (viene desactivado por defecto). Una vez al día, Baromio lee en WHOIS la fecha de expiración del dominio y te avisa por correo electrónico y en tus canales conectados de Slack, Discord o webhook los días en que quedan 30, 14 y 7 días. No hay ninguna alerta después de la de 7 días, así que tómala como el último aviso. La tarjeta del monitor muestra una insignia WHOIS con los días restantes. Si el operador del registro no publica una fecha de expiración, no aparece ninguna fecha. Para dominios bajo un sufijo de dos partes como .co.uk la consulta todavía no funciona; revísalos a mano.
• Planes: ambos están disponibles en todos los planes; Free cubre 20 monitores, Pro (9 EUR al mes) 30 y Business (29 EUR al mes) 100.

Una lista de control para cada cliente

1. Anota el registrador, el proveedor de DNS y quién paga la renovación.
2. Asegúrate de que los recordatorios de renovación te lleguen a ti y de que la renovación automática tenga una tarjeta válida.
3. Pon un monitor DNS con valor esperado en el registro principal del sitio, y otro en MX si el correo importa.
4. Activa las alertas de expiración de dominio en el monitor HTTP o de palabra clave del sitio.
5. Baja el TTL uno o dos días antes de cualquier cambio de DNS y mantén el servidor antiguo en marcha hasta que haya pasado el TTL antiguo.

Fuentes

• ICANN, Expired Registration Recovery Policy: plazos de los recordatorios (2.1), interrupción de la ruta de resolución DNS y página de renovación tras el vencimiento (2.2), el Redemption Grace Period de 30 días tras la eliminación, con la resolución DNS desactivada (3.1, 3.2).