Ir al contenido
Ayotl
English

← Todas las notas

4 de noviembre de 2026 · En Ayotl

Tres dominios que abrían para unos y para otros no

El servidor estaba perfecto y el chequeo decía «success» toda la noche. Aun así, para Cloudflare, OpenDNS y el verificador de Google, mercadito.cx no existía. Al día siguiente le pasó a jlptest.org, y a mediodía le estaba pasando a dailychallenge.click sin que nadie lo supiera. Era el DNS, los tres estaban en el mismo sitio, y esto es lo que aprendimos al moverlos.

Qué pasó

La noche del 3 de noviembre, Google Play rechazó la app de Mercadito porque su verificador no pudo abrir la URL de la política de privacidad. La política estaba en línea. Dos teléfonos abrían la página sin problema, por caché; Cloudflare, OpenDNS y el verificador de Google, no. El servidor en Railway estaba perfecto y el chequeo de salud en GitHub había dicho «success» toda la noche. Si esa revisión no hubiera estado en curso, la caída parcial habría seguido hasta que algún negocio dijera «no me abre el menú».

A la mañana siguiente le tocó a jlptest.org, con los mismos síntomas. Y al correr las comprobaciones sobre el tercer dominio de la casa, dailychallenge.click estaba fallando en ese preciso momento: los dos servidores de nombres de Hostinger devolvían SERVFAIL en siete de cada ocho consultas del registro A de la raíz; Cloudflare, Google y OpenDNS ya no lo resolvían, y sólo Quad9 seguía contestando desde su caché. Ninguna queja, ningún aviso. La única huella era que la publicación automática de la mañana había salido en Facebook y no en Instagram: Instagram descarga la imagen desde el dominio, y no pudo resolverlo.

A las 12:40 del 4 de noviembre los tres dominios estaban en Cloudflare y resolvían en todos los resolvedores públicos; tres minutos después, los registros de .org y .click ya apuntaban a los servidores de nombres nuevos.

Por qué

Los tres dominios apuntaban a Railway con un registro ALIAS en la raíz, en el DNS de Hostinger. Railway te da un nombre, no una IP; en un subdominio eso se resuelve con un CNAME normal, pero el estándar DNS no permite CNAME en la raíz, así que algunos proveedores ofrecen un «ALIAS» que resuelve el nombre por detrás y devuelve la IP cada vez que alguien pregunta. Hostinger lo ofrece, y Railway documenta que ahí no funciona de forma confiable. Esa resolución fue la que falló, en los tres, con un día de diferencia.

La falla fue silenciosa y parcial. Los servidores de Hostinger seguían contestando el SOA, las TXT y los NS; sólo el registro A de la raíz devolvía SERVFAIL, y no siempre: una de cada ocho consultas salía bien. Como los resolvedores grandes tienen varios puntos de presencia y guardan caché, unos seguían dando la IP y otros no. Nadie recibió un aviso, ni de Hostinger, ni de Railway, ni del chequeo de salud, porque el servidor estaba perfecto y el chequeo le preguntaba a un resolvedor que todavía tenía la respuesta en caché. Un fallo de DNS se ve desde fuera como cualquier otra cosa: como «política de privacidad inválida», o como un reel que no sale en Instagram.

Cómo se arregla

En dos pasos, y en este orden. Primero el parche: cambiar el ALIAS por un registro A con la IP que el nombre de Railway devuelve en ese momento, con TTL de cinco minutos. Funciona en minutos, pero es frágil, porque Railway no promete que esa IP sea fija: de hecho, entre la mañana y el mediodía el nombre de uno de los dominios ya devolvía otra. Sirve para sostener el dominio mientras se hace el arreglo, y para que los resolvedores que sigan preguntándole al proveedor viejo durante la mudanza reciban respuesta.

Después el arreglo: mover el DNS a Cloudflare, que sí aplana el CNAME en la raíz y que Railway soporta explícitamente. Es gratis y no mueve el dominio de registrador: sólo cambian los servidores de nombres. Lo que aprendimos haciéndolo tres veces en un día:

Qué hacer distinto

Los comandos

# ¿contesta el servidor que manda? (SERVFAIL = la falla)
dig @atlas.dns-parking.com dailychallenge.click A

# ¿coinciden los resolvedores públicos?
dig @1.1.1.1 dailychallenge.click A
dig @8.8.8.8 dailychallenge.click A

# ¿el servidor sirve si lo alcanzas directo, sin DNS?
curl --resolve dailychallenge.click:443:<IP> https://dailychallenge.click/
Tres comandos lo resuelven en un minuto. Si el tercero funciona y el primero no, el problema es DNS y no el código.
# los hermanos, de un tirón: un SERVFAIL en cualquiera es la falla
for d in mercadito.cx jlptest.org dailychallenge.click; do
  for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
    echo "$d @$r: $(dig @$r $d A +time=3 +tries=1 | grep -o 'status: [A-Z]*')"
  done
done

# antes de cambiar los servidores de nombres: ¿la zona nueva contesta bien?
dig @alec.ns.cloudflare.com dailychallenge.click A
dig @alec.ns.cloudflare.com kazan.dailychallenge.click CNAME
dig @alec.ns.cloudflare.com _railway-verify.dailychallenge.click TXT

# después: ¿ya cambió en el registro?
dig +short NS dailychallenge.click @8.8.8.8
El bucle tarda un minuto y da nueve respuestas; vale la pena correrlo cada vez que un dominio de la familia dé un susto, y mejor aún, que lo corra solo un chequeo externo. Los otros tres se corren una vez, antes y después de la mudanza.

Y una lección de otro tipo, que apareció en el camino: lo que no se mira no se actualiza. El manifest del sitio de Mercadito y su política de privacidad seguían describiendo el reparto a domicilio dos meses y medio después de quitarlo. Cada vez que un producto cambia de modelo, conviene una lista corta de «textos fuera de la app» (política, tiendas, manifest, metadatos, correos automáticos) para revisarlos el mismo día.

Todas las notas