Resumen

  • clientUpdateProhibited y serverUpdateProhibited no son un candado universal: RFC 5731 asigna cada estado a un lado distinto de la relación EPP.
  • RFC 10026 mantiene abierta la conservación DS autenticada cuando una rotación de clave o algoritmo lo exige, pero no elimina las pruebas de intención, coherencia, validación y aceptación del padre.
  • El distintivo «bloqueado» solo describe una parte del sistema. Para explicar un cambio hacen falta actor, canal, comprobaciones, publicación, aviso y recuperación.

Hay incidentes que empiezan con una captura de pantalla: «El dominio estaba bloqueado». La frase parece concluyente. Sin embargo, no dice quién había fijado el estado, si se leyó del servidor o solo de la interfaz, qué orden concreta impedía ni quién conservaba capacidad para actuar.

Esa omisión importa especialmente en DNSSEC. El DS de la zona padre no es una preferencia estática: enlaza la delegación con las claves de la zona hija. Si una clave cambia y el padre no puede acompañarla, la inmovilidad puede causar el fallo que el bloqueo pretendía evitar.

RFC 10026, publicada en julio de 2026 como Best Current Practice del IETF y firmada por Steve Sheng y Peter Thomassen, no propone una excepción retórica. Construye una frontera operativa: el nombre del estado no puede sustituir el análisis de quién manda sobre cada ruta.

El prefijo identifica al dueño del estado

En RFC 5731, los estados EPP con prefijo client pertenecen al cliente patrocinador, normalmente el registrador. Los que empiezan por server pertenecen al servidor, normalmente el registro. El registrador no puede alterar un estado del servidor; el servidor sí puede modificar o reemplazar uno del cliente conforme a su política local.

Tanto clientUpdateProhibited como serverUpdateProhibited obligan a rechazar solicitudes de actualización, salvo la que retira el propio estado. La misma descripción no produce el mismo mapa de autoridad.

El bloqueo de cliente frena la orden EPP enviada por el registrador mientras está activo. También puede servir para reducir cambios accidentales desde la cuenta del titular. Pero el registrador puede retirarlo y el registro no pierde su capacidad por un estado colocado por el cliente.

El bloqueo de servidor impide que el registrador actualice el objeto. Es una barrera real contra ese actor. No afirma que el operador del servidor haya quedado técnicamente incapaz de aplicar una acción propia autorizada por su política.

Por eso el registro mínimo de un control debe contener cuatro campos: estado exacto, quién lo fijó, qué clase de orden rechaza y qué actores siguen teniendo un camino de ejecución.

Mantener DNSSEC puede exigir movimiento bajo bloqueo

Una delegación firmada necesita renovarse. La clave de punto de entrada seguro puede rotar. La política criptográfica puede dejar de admitir un algoritmo. El operador DNS puede migrar. Cada transición puede requerir que el padre publique otro conjunto DS.

RFC 7344 permite que la hija anuncie la intención mediante CDS o CDNSKEY. RFC 9615 cubre el arranque autenticado cuando todavía no existe un DS previo que valide la señal. Son rutas técnicas separadas del formulario habitual del registrador.

RFC 10026 ordena no suspender el mantenimiento DS automático solo porque existe un bloqueo de actualización del registrador. Si la automatización la ejecuta el registro, tampoco debe suspenderse solo por un bloqueo de actualización del registro. La regla se aplica tanto a la inicialización como a posteriores rotaciones.

La razón es continuidad. Un DS viejo puede seguir siendo sintácticamente perfecto después de que la clave referenciada haya dejado de firmar. Congelarlo no conserva la seguridad; conserva una referencia rota.

Eso no significa que todo producto llamado «registry lock» tenga igual alcance. Una solución propietaria puede exigir una llamada fuera de banda, firmas múltiples o una espera. Esos requisitos deben demostrarse con su contrato y su código, incluido el mecanismo de emergencia. No nacen del parecido entre nombres.

El camino no se abre sin controles

La señal de la hija no gobierna al padre por sí sola. RFC 10026 exige comprobar una intención inequívoca: CDS y CDNSKEY deben referirse al mismo juego de claves y los servidores autoritativos de la delegación deben mostrar un estado plausiblemente coherente.

Después, el agente parental proyecta el DS resultante y verifica que al menos una ruta de validación seguiría funcionando. Si no puede probar ambas cosas, cancela la operación.

Así aparecen recibos que no se compensan entre sí. La presencia del bloqueo prueba un estado limitado. La señal prueba una petición. La autenticación prueba su origen técnico. La consistencia prueba que no se observó solo una réplica. La validación proyectada prueba continuidad. La lectura del padre prueba publicación.

El artículo anterior sobre todos los servidores autoritativos se ocupaba de la coherencia de la petición hija. Aquí el problema es anterior y distinto: qué actor administrativo alcanza un estado de registro. Un servidor unánime no amplía el bloqueo y un bloqueo visible no vuelve unánimes a los servidores.

El bloqueo del registrador no defiende frente al registrador

La parte más útil de RFC 10026 es su negativa a exagerar el modelo de amenaza. Si el registrador puede retirar clientUpdateProhibited, el estado no lo protege frente a una actuación ilícita del propio registrador. Tampoco ata al registro. Una intrusión con esos privilegios no queda derrotada por la etiqueta.

El control sigue teniendo valor. Puede detener una orden normal y limitar errores o abuso de una cuenta. Lo que no puede hacer es certificar que las organizaciones superiores eran incapaces de actuar.

Una captura de pantalla, por tanto, no reconstruye un incidente. Faltan la lectura EPP del servidor, el historial del estado, la identidad del actor, el método de autorización, las comprobaciones de aceptación y el cambio exacto en la zona padre.

Al auditor le conviene preguntar «¿contra quién protege este bloqueo?» antes de preguntar «¿estaba bloqueado?». La primera pregunta produce un mapa verificable; la segunda invita a una respuesta binaria que el sistema no ofrece.

El registro puede actuar sin que el registrador envíe una orden

En el modelo registrante–registrador–registro, el registro puede leer directamente la señal del operador DNS hijo y mantener el DS. El registrador no participa con una orden EPP. El resultado puede ser correcto y, aun así, sorprenderle.

RFC 10026 trata esa sorpresa como un problema de transparencia. El registro debería notificar cambios al registrador con la extensión Change Poll de RFC 8590 o un canal equivalente. El titular o su representante debería consultar el DS activo. Los avisos humanos relevantes deben evitar ruido repetitivo y conservar destinatario y momento.

El agente parental necesita además una bitácora estructurada: fecha, CDS/CDNSKEY que disparó el proceso, canal de aviso, servidores consultados, resultado de cada verificación, decisión y DS aplicado o causa de cancelación.

Con esa secuencia, «cambió aunque estaba bloqueado» deja de ser una paradoja. El estado siguió frenando las órdenes a las que se dirigía; otra ruta autenticada pasó sus controles; el actor competente publicó; los demás participantes recibieron un aviso.

Si falta el aviso, se prueba un defecto de rendición de cuentas. No se demuestra automáticamente que la petición era falsa. La investigación debe conservar las fronteras entre evidencia técnica, autorización institucional y comunicación.

La recuperación necesita una puerta diferente

La clave que autentica CDS/CDNSKEY puede perderse. Un proveedor puede dejar de colaborar en una configuración con varios operadores. Algunos servicios no implementan la automatización. En esos casos, repetir la ruta automática no recupera autoridad.

RFC 10026 exige que registros y registradores mantengan otro canal para el mantenimiento DS. Puede ser manual, pero debe permitir la reparación cuando la prueba en banda ya no es posible.

Una intervención manual también necesita trazabilidad: quién ejerció la autoridad, qué validación fuera de banda realizó, qué DS solicitó, si suspendió temporalmente la automatización y qué señal permite reanudarla. Sin esos datos, «override» es otra palabra que aparenta más precisión de la que ofrece.

Sheng aporta al estándar; no opera sus despliegues

El RFC Editor nombra a Steve Sheng y Peter Thomassen como autores de RFC 10026. La ficha pública de Sheng en el IETF también recoge RFC 7485 y RFC 7710. El archivo de ICANN lo identificaba en 2022 como director sénior de apoyo al desarrollo de políticas; su biografía actual señala que concluyó quince años en ICANN en 2024 y que posee un doctorado de Carnegie Mellon en Ingeniería y Política Pública.

Esos hechos documentan experiencia en la frontera entre protocolo e institución. No prueban que Sheng controle un registro, un registrador, un dominio o una implementación. Tampoco convierten el consenso del IETF en autoridad personal.

El paralelismo es instructivo: el nombre de un autor atribuye una contribución; el nombre de un estado atribuye una prohibición. Ninguno recibe autoridad adicional sin una transferencia o una ejecución demostrable.

La prueba final es un recibo centrado en actores

Una decisión reproducible empieza con el estado público y el del servidor, su autor y su hora. Añade actor y canal de la petición, material CDS/CDNSKEY, autenticación, comparación de servidores, prueba de validación, política local y resultado.

Después registra la publicación, el nuevo DS, TTL, avisos al registrador y al titular, observación desde resolutores y canal de recuperación. No hacen falta secretos; sí hacen falta las piezas que permiten explicar quién podía actuar y qué sucedió.

La primacía del código en funcionamiento obliga a reducir la afirmación a lo que el mecanismo prueba. El mínimo común no es una inmovilidad ceremonial. Es conservar una transición DNSSEC autenticada sin borrar la recuperación. Cada operador puede añadir controles locales y bloqueos más fuertes, siempre que publique qué camino y qué actor restringen.

Un bloqueo es evidencia dentro de su frontera. Fuera de ella, comienza otra investigación.

Fuentes