Resumen

  • La observación del 13 de septiembre encontró que el glue IPv6 de .ps en la raíz coincide con la dirección actual del nombre de servidor de RIPE NCC; las discrepancias de .ne, .sd y .tj persisten.
  • RIPE NCC explicó que IANA no podía tramitar sus solicitudes sin la aprobación de los contactos de cada ccTLD. No había un lote único, sino cuatro trayectorias de autorización.
  • No se ha demostrado una caída del servicio. Las delegaciones conservaban rutas glue alternativas. La carencia pública es un recibo que explique, caso por caso, autorización, comprobaciones y desenlace.

Una dirección dejó de estar en la lista sin arrastrar a las otras tres. Esa es la noticia y también la explicación del sistema.

El 15 de agosto, Patrik Wallstrom comunicó al grupo de trabajo DNS de RIPE que la zona raíz seguía ofreciendo direcciones IPv6 antiguas para ne.cctld.authdns.ripe.net, ps.cctld.authdns.ripe.net, sd.cctld.authdns.ripe.net y tj.cctld.authdns.ripe.net. En enero, RIPE NCC había declarado terminado el renumerado IPv6 de AuthDNS: el /48 anterior estaba completamente retirado y la mayor parte de la limpieza, concluida.

La respuesta de RIPE NCC del 20 de agosto dejó claro por qué la última parte no dependía únicamente de su equipo. Había contactado por correo, teléfono y canales regionales, y había presentado solicitudes a IANA. Sin la aprobación de los contactos de los ccTLD, IANA no podía procesarlas. El mantenimiento de los datos de delegación en la raíz corresponde al gestor de cada TLD.

Ese requisito no es un obstáculo accidental. Impide que el operador de un servidor —incluso el que conoce de primera mano su nueva dirección— cambie por sí solo una delegación bajo la responsabilidad de otro actor.

Una comparación con dos lados

La captura se realizó a las 17:14 UTC del 12 de septiembre, ya día 13 en Shanghái. Se tomaron las referencias de a.root-servers.net y b.root-servers.net y se compararon con las respuestas para los nombres obtenidas de 1.1.1.1 y 8.8.8.8.

En .ps, ambos servidores raíz devolvieron 2a13:27c0:30::105; ambos resolvedores devolvieron la misma dirección AAAA para ps.cctld.authdns.ripe.net. La página de delegación de IANA también muestra esa dirección y lleva una fecha general de actualización del 8 de septiembre.

En .ne, la raíz aún entregó 2001:67c:e0::101, mientras la respuesta actual del nombre fue 2a13:27c0:30::101. En .sd, el par fue 2001:67c:e0::109 frente a 2a13:27c0:30::109; en .tj, 2001:67c:e0::117 frente a 2a13:27c0:30::117. Las direcciones IPv4 sí coincidieron: 193.0.9.101, .109 y .117.

Así, la cifra de agosto pasó de cuatro a tres. Nada en esta observación identifica quién inició o aprobó el cambio de .ps, ni el instante exacto en que comenzó a servirse desde la raíz. Tampoco puede atribuirse un campo concreto a la fecha global de una página. Lo demostrable es la divergencia de resultados.

Redundancia sin complacencia

RIPE NCC señaló que cada delegación contaba al menos con otro glue IPv6 operativo y varios glue IPv4, de modo que los resolvedores podían seguir la delegación y resolver los nombres. Por eso, «dirección antigua» no equivale a «dominio caído».

Esta investigación no envió tráfico a las antiguas direcciones IPv6. No midió su alcance, reintentos ni experiencia de usuario. No hay base para afirmar una delegación coja, un fallo de DNSSEC, una avería de los resolvedores o la pérdida del servicio autoritativo. Que existan rutas alternativas tampoco prueba que todos los resolvedores las utilicen sin retraso.

La redundancia evita exagerar el daño, pero no vuelve correcto el dato. Una referencia al prefijo retirado debe converger. El reto es hacerlo sin desactivar la barrera de autorización que protege las delegaciones.

El archivo histórico no describe la cola actual

La auditoría de operaciones de la raíz de IANA de julio de 2025 muestra solicitudes relativas a los cuatro nombres, todas marcadas Administratively Closed el 18 de julio de 2025. La tabla pública no da el motivo particular de cada cierre. Son resultados históricos, no estados pendientes de 2026, y no explican la posterior alineación de .ps.

Hoy la evidencia aparece separada: una auditoría dice que una solicitud terminó; una ficha de delegación muestra el dato publicado; una consulta DNS registra una respuesta. Ninguna pieza enlaza de forma pública la autoridad solicitante, la aprobación del gestor, la revisión técnica, el motivo terminal y el dato finalmente observado.

Un recibo para cada relación de autoridad

El remedio no exige publicar correos privados. Un recibo por delegación puede identificar el TLD, el nombre de servidor, la dirección antigua y la solicitada, el papel del solicitante y una referencia pública segura. Puede consignar el estado y momento de la autorización, el resultado de las comprobaciones técnicas, el desenlace —aplicado, retirado, cerrado o sustituido— y una categoría de motivo.

Debe cerrar el circuito con el número de serie de la zona raíz o una hora de observación, el glue que se sirve, la siguiente acción y cualquier solicitud sucesora. Así se distingue «a la espera del gestor» de «no superó las pruebas» sin debilitar el consentimiento.

Las actas del grupo DNS en RIPE 91 describieron el renumerado como una mejora operativa y recogieron el plan de observar consultas a las direcciones antiguas después de apagarlas. Esas consultas pueden revelar uso residual. El recibo revela la decisión que falta. Contarlas juntas ya no sería un falso lote, sino la vista resumida de cuatro expedientes verificables.

Fuentes