Los servidores autoritativos del TLD .shop devuelven NXDOMAIN y tumban el dominio entero
El registro de GMO dejó de responder consultas para .shop durante unos 50 minutos y contestaba NXDOMAIN con bit autoritativo, según reportan varios administradores en r/sysadmin.
Los servidores autoritativos de .shop dejaron de resolver. Quien preguntara a a.gmoregistry.net, uno de los nameservers del registro que opera GMO, recibía NXDOMAIN con el bit AA activado: la respuesta autoritativa de que ese nombre no existe. No un timeout, no un SERVFAIL. Una negación con autoridad.
El hilo lo abrió un administrador que se comió una avalancha de alertas de madrugada porque sus sistemas no alcanzaban ciertos endpoints. Su primer reflejo fue pensar que se les había pasado renovar el dominio. No era eso: el dominio estaba activo hasta 2027.
Qué se veía desde fuera
Las consultas contra el servidor del registro fallaban para cualquier nombre dentro del TLD, incluido el de la propia web de marketing del registro, get.shop, que también estaba inaccesible. El episodio arrancó alrededor de las 00:27 UTC+8 y hacia las 01:17 UTC+8 empezaba a recuperarse de forma parcial, según el mismo autor del hilo.
Que un registro conteste NXDOMAIN desde su servidor autoritativo es peor que un corte seco. Un resolver que recibe una negación con AA la cachea siguiendo el TTL mínimo del SOA de la zona, así que los efectos se alargan más allá del momento en que GMO arregle lo que sea que se rompió. Durante ese rato, cualquier cosa que dependa de resolver un .shop —resolución directa, validación DNSSEC, certificados que renovar, correo— se cae aunque el servidor de destino esté perfectamente vivo.
De momento no hay explicación pública del registro ni aviso en sus canales. Lo único que hay es el reporte de un puñado de administradores afectados y las consultas dig que pegaron en el hilo, que apuntan a un fallo en la capa de servicio del propio registro y no a un problema de los resolvers de los usuarios.
Por qué importa
Un TLD es un único punto de fallo para todo lo que cuelga de él, y eso no se puede mitigar desde el lado del cliente. No hay failover que configurar: si el registro deja de responder con autoridad, no queda nada que consultar. Lo que sí conviene es tener a mano el nombre de los nameservers autoritativos para distinguir un NXDOMAIN legítimo de uno servido por un registro caído, porque las alertas de los monitores se parecen demasiado.
Queda por ver si GMO publica un postmortem con la causa y si el incidente afectó también a la firma de zona o a la publicación de delegaciones nuevas. Sin eso, la única cifra de duración que hay es la del hilo, y es la de quien lo escribió, no la del registro.
