Resumen

  • draft-skoglund-epp-registry-lock-00 propone dejar pendiente una modificación de un dominio protegido hasta que uno o varios contactos la autoricen dentro del plazo configurado.
  • La política puede fijar cuántas aprobaciones se requieren y el mensaje final puede listar los contactos que aprobaron, pero no normaliza identidad, desafío ni independencia de canales y recuperación.
  • Hace falta un registro de la ceremonia que vincule estados anterior y solicitado, dominios de control, retos, excepciones, tiempos y resultado. Es una recomendación de gobernanza, no una regla del borrador.

El atractivo del cuórum es inmediato: dos parece más seguro que uno. Sin embargo, dos direcciones del mismo entorno de correo, dos teléfonos administrados por la misma persona o dos cuentas recuperables mediante el mismo proveedor constituyen un solo punto de fallo con dos identificadores.

Registry Lock pretende añadir control en el registro, más allá de las credenciales ordinarias del registrador. Para un dominio crítico, una alteración de servidores de nombres, titular o proveedor puede mover tráfico y autoridad. Automatizar la participación del registro tiene sentido; reducirla a una suma puede borrar la separación que justificó el servicio.

La revisión 00 apareció el 30 de junio de 2026. El documento mostrado lleva encabezado de Standards Track, pero Datatracker lo clasifica como Internet-Draft individual, sin corriente ni estado RFC previsto y sin posición formal en IETF. No es un RFC ni un consenso adoptado de REGEXT.

La respuesta 1001 abre una decisión pendiente

El borrador describe procedimientos existentes diversos y a menudo manuales. Su extensión permite que el cliente patrocinador configure y gestione el bloqueo a través de EPP. Una vez aplicado, el dominio debe tener serverDeleteProhibited; durante una transformación pendiente debe aparecer serverPendingUpdate.

Al establecer el bloqueo o actualizar un dominio bloqueado, el servidor devuelve el código 1001: la orden ha sido aceptada, pero todavía requiere una acción. La autorización dentro del plazo produce un mensaje poll de éxito; la falta de aprobación a tiempo produce uno de fallo.

El cambio, por tanto, es un episodio y no un intercambio único. Los datos de sondeo pueden incluir dominio, operación, identificador previo del servidor y contactos aprobadores. La cola de RFC 5730 añade fecha e identificadores de la entrega. Es suficiente para enlazar inicio y desenlace a nivel de protocolo, no para probar qué ceremonia ocurrió entre ambos.

Contar filas no separa el poder

La política admite un tiempo de espera y un entero positivo para el número de aprobaciones, escrito quorom en esta primera revisión. El servidor puede limitar valores y número de contactos.

La cifra resuelve cuántas respuestas debe contar el sistema. No dice si pertenecen a personas, organizaciones, dispositivos o vías de recuperación distintas. Varias fichas pueden terminar en un buzón común; varias empresas pueden usar el mismo proveedor de identidad; un tercero puede gestionar todos los móviles.

Multiplicidad significa que hay varias entradas. Independencia significa que una sola intrusión, orden o recuperación no puede producir todas las respuestas. Si esa regla queda fuera de EPP, el operador debe declararla y conservar prueba de su aplicación antes de vender un quorom=2 como control de dos personas.

Una etiqueta de canal no mide su resistencia

El contacto tiene identificador y método opcional. La lista conocida incluye email, text, letter, phone y token; el servidor puede admitir otras cadenas.

Ninguna etiqueta define la comprobación. «Email» puede ser un enlace firmado o una respuesta al soporte. «Text» no habla de reasignación del número. «Token» puede ser hardware o un código reenviable. «Phone» no identifica a quien responde. La carta tampoco vale sin dirección, destinatario y reto registrados.

El borrador no fija contenido del desafío, unión con la modificación exacta, protección contra repetición, alta del canal, prueba de identidad o recuperación. Puede ser una decisión razonable para una versión inicial, pero limita el significado de approvedBy: el registro afirma que su proceso aceptó al contacto, no que exista una garantía universal.

Proteger la ficha no protege toda la constitución

Actualizar o borrar un contacto asociado a un dominio bloqueado debe ser rechazado. Así no se puede sustituir simplemente el correo y aprobar por la ruta nueva.

No obstante, una actualización de Registry Lock puede añadir y retirar contactos o cambiar plazo y número requerido. Surge una pregunta constitucional: ¿qué autoridades antiguas autorizan el cambio de autoridades?

Eliminar al único aprobador externo, rebajar el cuórum o acortar el tiempo puede debilitar el control antes de la siguiente operación. La solicitud debe juzgarse con la política y el conjunto que existían al inicio, y la evidencia debe guardar antes y después. La regla nueva no puede validar retroactivamente su propia adopción.

Las excepciones son parte del producto

El bloqueo no impide todo. La renovación continúa. El registro puede dejar que la automatización DNSSEC, por ejemplo un escáner CDSS o CSYNC, evite la autorización. Quitar el bloqueo sigue siendo un procedimiento manual fuera de la especificación.

Son límites defendibles: bloquear renovaciones elevaría el riesgo de caducidad y automatizar DNSSEC puede proteger continuidad. Pero «bloqueado» pasa a significar un perímetro con aperturas.

La excepción automática necesita identidad del escáner, observación, política y estados de delegación. La retirada manual necesita un identificador correlacionable con EPP. De lo contrario, la vía más poderosa es precisamente la que deja menos evidencia estructurada.

Dos operadores, dos ceremonias

IANA ya enumera una extensión sueca de Registry Lock activa como especificación Other para .se y .nu. No es la aprobación del nuevo borrador individual.

Internetstiftelsen informa de que cada registrador decide cómo verificar al titular, desbloquea, realiza el servicio y vuelve a bloquear de inmediato o tras el plazo elegido. DENIC describe para .de un contacto que recibe un token en el móvil registrado y un correo; sin confirmación en siete días naturales la solicitud se rechaza, además de la revisión separada de DENIC.

No son pruebas de adopción de la revisión 00. Muestran que el mismo término comercial cubre altas, tiempos, verificaciones y recuperaciones diferentes. Una sintaxis común no sustituye esa declaración.

Registrar la ceremonia, no solo el resultado

Propongo un registro de ceremonia de aprobación para cada transformación pendiente. Es una propuesta editorial.

Primero fija dominio, cliente autenticado, sesión, clTRID, svTRID, hora, operación y representaciones canónicas del estado anterior y solicitado. Conserva versión de política, plazo, número exigido y conjunto previo de contactos.

Para cada aprobador identifica autoridad representada, fecha de alta, método y dominios de control usados al medir independencia: empleador, identidad, correo, dispositivo, cuenta telefónica, emisor del token y recuperación. Referencias controladas pueden evitar exponer datos sensibles.

Cada desafío se liga mediante un resumen a la modificación exacta, destino, emisión, caducidad, respuesta, validación y anti-repetición. La decisión explica qué regla de independencia se evaluó, qué respuestas contaron y si hubo excepción. El cierre enlaza comando pendiente, mensaje de cola y estado aplicado.

El número contesta cuántos. El registro de ceremonia permite saber si esos votos representaban autoridades que podían fallar de forma independiente.

Fuentes