Resumen

  • La solicitud RSEP 2026013 de Verisign, presentada el 15 de abril de 2026, propone cerrar las nuevas altas de nombres de tercer nivel en .NAME y terminar y borrar los existentes. ICANN la aprobó el 7 de mayo y envió una autorización para desplegarla el 28 de julio. Su carta recoge la estimación del operador de unos 22.000 registros, en su mayoría supuestamente inactivos.
  • ICANN no encontró problemas significativos para la seguridad o estabilidad global del DNS ni para la competencia bajo los criterios RSEP. Su personal dijo que conocía el impacto en los titulares, pero que ese impacto no era un criterio de aceptación. La recomendación de agosto sobre un recurso no resolvió las seis solicitudes reunidas en octubre. Los documentos examinados tampoco fijan la fecha final de cierre ni prueban que ya se haya borrado algún nombre.

La contradicción cabe en un formulario

La solicitud original explica el negocio: cae el uso del servicio, pocos registradores lo apoyan y mantenerlo consume trabajo. Son razones para que un operador quiera salir. Luego describe una salida que alcanza a los clientes anteriores: no habrá nuevas altas de tercer nivel y los registros vigentes se terminarán y eliminarán. No se trata sólo de quitar un producto del escaparate.

En la respuesta sobre el ciclo de vida de los nombres, sin embargo, Verisign escribió que no habría efecto. Quizá usó «ciclo de vida» en un sentido técnico de estados registrales. El formulario no proporciona una definición que permita reconciliar esa respuesta con la extinción anunciada de una clase entera de nombres. Para el titular que aún renueva, la distinción burocrática no mantiene el nombre vivo. Un sistema que recibe ambas frases y continúa el trámite ha decidido dónde pondrá su atención.

La propia solicitud ofrece un calendario relativo, no una fecha de cierre. Verisign promete avisar a los registradores al menos 90 días antes y repetir el aviso al menos 30 días antes. Dice que mantendrá asistencia para esos intermediarios y que consultó verbalmente a un grupo escogido de registradores que representaban a la mayoría de usuarios del servicio. Ninguno habría planteado una preocupación de seguridad, estabilidad o competencia. La voz de los registradores está documentada; la de cada titular antiguo no aparece como un paso formal de ese procedimiento.

Un nombre de tercer nivel puede haber empezado como una elección personal y terminar incrustado en correo, recuperación de cuentas, certificados, contactos o archivos. La documentación pública no ofrece un inventario verificado de esas dependencias. Es precisamente la razón para no tratar «la mayoría no se usa» como si significara «nadie perderá una función». Un registro inactivo y uno que todavía sirve de llave no producen el mismo coste cuando desaparecen.

El examen que dejó a la persona fuera del marco

La carta de ICANN del 28 de julio dice que la petición se aprobó el 7 de mayo y se publicó al día siguiente. El examen RSEP no identificó problemas significativos de seguridad o estabilidad del DNS ni de competencia. Con la renovación del contrato de .NAME en curso, ICANN prefirió autorizar el despliegue por carta antes que hacer inmediatamente una enmienda contractual. La autorización permite ejecutar la retirada descrita por Verisign.

La carta atribuye al operador la cifra aproximada de 22.000 registros y su afirmación de que la mayoría no se utiliza. La cifra es una estimación presentada en el expediente, no un recuento independiente de usos activos. ICANN conocía el orden de magnitud. La recomendación de su Comité de Mecanismos de Responsabilidad, BAMC, indica que el personal había tratado esos registros con Verisign antes de aprobar. Este caso no gira alrededor de un número oculto. Gira alrededor de un número visible que no alteró el criterio de decisión.

Las actas del BAMC del 24 de agosto hacen explícita esa frontera. El personal explicó que el análisis de seguridad y estabilidad mira el DNS como conjunto, no los registros individuales. El efecto en los titulares se entendía, pero no era uno de los criterios de aceptación RSEP. También explicó que RSEP carece de un mecanismo formal para recibir aportaciones de terceros. ICANN podía contestar correctamente a su propia pregunta técnica mientras dejaba sin respuesta la pregunta práctica de quienes pierden su nombre.

Otra línea de la carta coloca la relación con los titulares en manos de los registradores. Verisign se dirige a ellos; ellos mantienen el vínculo contractual con los clientes; ICANN evalúa el cambio bajo una política de alcance limitado. Esa división puede funcionar para distribuir avisos. Para demostrar que la salida protege nombres aún utilizados, hace falta unir las tres partes en un registro de fechas, destinatarios y opciones reales.

Seis impugnaciones, una autorización vigente

La solicitud de reconsideración 26-2 atacó decisiones sobre el tercer nivel y sobre un servicio diferente de reenvío de correo. Este último pertenece a RSEP 2026014: ambos cambios pueden afectar a un usuario, pero no deben mezclarse como si fueran el mismo producto. En agosto, el BAMC recomendó rechazar 26-2. Consideró que no se habían demostrado los errores de proceso o de información necesarios para la vía de reconsideración; medidas solicitadas como una consulta pública o conservar nombres hasta el fin del periodo pagado quedaban, según su análisis, fuera de ese cauce o en contratos entre registrador y titular.

La petición de Patrik Fältström aporta otro ángulo: un nombre usado durante más de veinticinco años no equivale a una nueva alta que el operador decide dejar de vender. Plantea asimismo un riesgo hipotético: si otra persona obtuviera más adelante el segundo nivel, podría volver a crear el tercer nivel bajo un control distinto. El expediente no demuestra que ese abuso haya ocurrido. Sí describe una pregunta concreta que debería acompañar a cualquier plan de cierre: quién podrá controlar una cadena idéntica después de borrar la anterior.

El aviso del 14 de octubre reunió 26-2, 26-5, 26-6, 26-7, 26-9 y 26-10 para que BAMC y el Consejo las consideren juntas. La recomendación de agosto sobre una de ellas no es la resolución final del conjunto. Mientras tanto, la lista pública RSEP marca 2026013 como aprobada. «Aprobada» describe la decisión administrativa; no es una bitácora de bajas ya ejecutadas.

La parte del sistema que debe avisar

Un registrador puede saber cuántos nombres mantiene y a qué dirección contractual enviar un mensaje. No puede conocer por sí solo todas las aplicaciones y hábitos que un titular construyó alrededor de un nombre hace décadas. El titular puede desconocer sus propias dependencias antiguas. Por eso el aviso necesita más que una fórmula de 90 días: una fecha cierta, el alcance de la baja, el tratamiento del tiempo pagado y una ruta para comprobar qué uso quedará sin servicio.

Verisign dijo que las disposiciones contractuales para el tercer nivel seguirían vigentes hasta terminar todos los registros y que la retirada se reflejaría después en el contrato renovado. Entre la carta que permite actuar y esa futura redacción hay espacio para fijar pruebas de aviso y un estado final verificable. Si el contrato sólo toma nota después de la desaparición, registra el resultado sin gobernar la transición.