La seguridad del registrador exige aprobación por llamada

Dar a un agente de IA una credencial de API del registrador no le concede un único poder coherente. Le concede varios poderes sin relación entre sí que comparten el mismo secreto: redirigir el dominio, prepararlo para una transferencia, cambiar quién recibe avisos de recuperación y modificar la cadena de confianza de DNSSEC. La seguridad del registrador falla cuando una capa de aprobación trata todas esas llamadas como si fueran equivalentes.

Cada llamada que cambia el estado del registrador merece una decisión vinculada a la acción, el dominio, el valor anterior y el valor propuesto. Una persona puede aprobar la sustitución de servidores de nombres durante una migración planificada y rechazar, en la misma ejecución, la retirada de un bloqueo, un cambio del correo del titular o la eliminación de un DS. Aprobar la sesión no basta para expresar esa diferencia.

Una credencial oculta varios límites de seguridad

Una credencial del registrador demuestra autenticación, no intención humana. Aunque un proveedor ofrezca permisos detallados para la API, los equipos suelen reunir varias operaciones de escritura en un mismo rol para que una automatización pueda terminar. Otros proveedores entregan un token amplio. En ambos casos, poseerlo solo responde a quién puede solicitar algo. No responde a si este cambio concreto debe ocurrir ahora.

Los protocolos subyacentes no fingen que esas operaciones sean iguales. RFC 5731, el mapeo de dominios EPP que usan registradores y registros, describe las asociaciones de servidores de nombres, contactos, valores de estado y datos de autorización como atributos separados. Su orden de actualización puede añadir o retirar servidores y contactos, cambiar al titular, cambiar datos de autorización y modificar estados del cliente. Una API cómoda puede reunir esas operaciones bajo una credencial, pero el estado del registro conserva significados distintos.

Un registrador de nube pública muestra la misma separación en su lista de órdenes. La API Route 53 Domains ofrece operaciones diferentes para UpdateDomainNameservers, UpdateDomainContact, DisableDomainTransferLock, AssociateDelegationSignerToDomain y DisassociateDelegationSignerFromDomain. La lista aporta una prueba útil porque nombra las decisiones que debe conservar un sistema de aprobación en vez de reducirlas a registrar.write.

Antes de dar acceso a un agente planteo cuatro preguntas:

• ¿Puede esta llamada redirigir la resolución de todo el dominio?
• ¿Puede facilitar un robo posterior o complicar la recuperación?
• ¿Puede cambiar quién recibe mensajes de control o verificación?
• ¿Puede hacer que los resolutores validadores rechacen respuestas DNS correctas?

Si dos llamadas producen respuestas distintas, son acciones de aprobación distintas. Compartir una clave de API no las convierte en una sola.

Cambiar servidores de nombres delega toda la zona

Sustituir servidores de nombres entrega la autoridad DNS al nuevo conjunto, por lo que su radio de efecto supera con mucho al de editar un registro. RFC 8499 define la delegación como la incorporación, por parte del padre, de un conjunto NS para el origen hijo. Cuando las cachés siguen esa delegación, los nuevos servidores autoritativos pueden responder por las direcciones web, intercambiadores de correo, registros de descubrimiento de servicios y TXT de verificación de la zona.

La última categoría permite ver un riesgo que suele infravalorarse. RFC 8555 dice que un cliente ACME puede demostrar control sobre un dominio publicando un valor TXT bajo _acme-challenge. Quien controle la zona delegada puede responder a ese desafío y solicitar certificados para nombres del dominio, sujeto a las comprobaciones de la autoridad certificadora. Cambiar servidores no es solo cambiar un ajuste de alojamiento.

La aprobación debe mostrar los conjuntos anterior y nuevo completos, no una frase como actualizar DNS. Los conjuntos importan porque una migración suele añadir servidores antes de retirar los antiguos, mientras que algunas API sustituyen todo el conjunto en una llamada. La persona revisora debe ver si la solicitud conserva todos los servidores previstos, si intervienen direcciones glue y si los servidores de destino ya responden de forma autoritativa.

Antes de aprobar, consulta directamente cada servidor propuesto sin confiar en una caché recursiva:

for ns in ns1.new-dns.example ns2.new-dns.example; do
  dig +norecurse +short @"$ns" example.com SOA
  dig +norecurse +short @"$ns" example.com MX
done

Una comprobación sana devuelve una línea SOA de cada servidor y los destinos MX esperados. Una salida vacía, números de serie distintos o respuestas sin autoridad exigen investigación. El plan de migración determina si los números ya deben coincidir, pero nadie debería aprobar un servidor que aún no haya respondido por la zona.

El registro de aprobación debe identificar la acción como nameserver.replace, incluir la solicitud ordenada y una diferencia normalizada de conjuntos, e indicar si la llamada cambia también el glue. No la escondas en una actualización genérica: un error verosímil del agente puede redirigir todos los servicios a la vez.

Retirar el bloqueo de transferencia abre una ventana

Desactivar el bloqueo no transfiere el dominio, pero retira un control que impide hacerlo. ICANN llama al bloqueo habitual clientTransferProhibited o un estado parecido. RFC 5731 indica que una solicitud de transferencia debe rechazarse mientras se aplique clientTransferProhibited o serverTransferProhibited.

La diferencia importa durante la revisión. Un agente puede necesitar retirar el bloqueo antes de una mudanza prevista, pero una retirada inesperada sigue siendo peligrosa porque crea una condición útil para otro actor. Trata transfer_lock.disable como acción propia y exige que la solicitud nombre el registrador de destino, el ticket de cambio y la hora prevista de reposición del bloqueo o de finalización. Esos campos no obligan al registrador a cumplir el plan, pero dan contexto suficiente para rechazar una retirada sin explicación.

El código de autorización es otro secreto y otra decisión. Su obtención nunca debe quedar incluida en la aprobación de retirar el bloqueo. Un buen plano de control pide permiso una vez para quitarlo y otra para obtener o usar el código. Si el flujo cambia también al titular, el orden importa: la Política de Transferencias de ICANN exige un bloqueo entre registradores de 60 días tras determinados cambios de titular, salvo que el registrador ofreciera excluirlo antes del cambio y el titular eligiera esa opción.

Una recomendación popular consiste en mantener el dominio bloqueado y considerar segura la automatización. El bloqueo ayuda, pero el consejo se queda corto. Una credencial capaz de retirarlo también puede borrar la protección. La aprobación por llamada hace visible la retirada cuando importa, mientras que una política permanente que solo comprueba el estado actual queda invalidada por la siguiente petición.

Activar el bloqueo suele ser una reparación de menor riesgo, pero sigue siendo una escritura con efectos operativos. Puede detener una transferencia legítima ya iniciada. Muestra el estado pendiente y pide confirmación humana salvo que un procedimiento de incidente autorice expresamente volver a bloquear.

Los cambios de contacto alteran la recuperación

Actualizar el contacto del titular o administrativo cambia quién recibe avisos importantes y puede modificar la posibilidad de transferir. No redirige el tráfico de inmediato, lo que lleva a clasificarlo por debajo de los servidores de nombres. Esa clasificación ignora cómo funciona la recuperación de un dominio.

ICANN pide mantener los datos de contacto al día porque los registradores envían por correo avisos de protección y gestión. Su Política de Transferencias también vincula determinados cambios de titular con un bloqueo de 60 días. Un agente que sustituye el correo del titular justo antes de una transferencia planificada puede retrasarla. Un atacante que cambia un contacto accesible puede interferir con avisos o con una recuperación futura, según los procesos del registrador y del registro.

La tarjeta de aprobación necesita una diferencia por campos. contact.update dice demasiado poco si la solicitud cambia correo, teléfono, organización, privacidad e identidad del titular a la vez. Muestra cada valor anterior y nuevo, marca los roles afectados y enseña si el registrador informa de una restricción posterior. El enmascarado protege datos personales en registros rutinarios, pero quien autoriza un cambio de identidad sensible debe ver lo suficiente para reconocer al destinatario.

No dejes que el agente resuelva un rechazo cambiando campos repetidamente hasta que la API los acepte. Los registros aplican reglas distintas, y algunos dominios territoriales añaden requisitos. Un flujo más seguro valida la carga, pide aprobación para la diferencia final, la envía una vez y guarda el identificador de operación. Si el proveedor procesa el cambio en segundo plano, la acción sigue pendiente hasta que una lectura confirme el estado previsto.

La privacidad del contacto también es otra acción. Cambiar la exposición pública no equivale a cambiar al titular subyacente. Una persona puede aceptar el ajuste de privacidad y rechazar un cambio de propiedad, así que no deben combinarse solo porque un proveedor use el mismo endpoint.

Los cambios DNSSEC pueden invalidar respuestas correctas

Cambiar la delegación DNSSEC modifica la cadena con la que los resolutores validadores autentican la zona hija. RFC 4034 es preciso: el registro DS señala una DNSKEY mediante etiqueta de clave, algoritmo y resumen, y vive en el lado padre de la delegación. La DNSKEY correspondiente vive en la zona hija. Las API de registrador suelen llevar el material DS al registro porque el titular no puede editar directamente la zona padre.

Un servidor de nombres incorrecto puede redirigir respuestas. Un DS incorrecto puede hacer que los resolutores marquen como falsas respuestas genuinas. Es otro modo de fallo y requiere otra revisión. Borrar DS puede convertir una zona segura en delegación insegura cuando caduquen las cachés. Añadir uno que no coincida con una DNSKEY publicada puede romper la validación. Retirar demasiado pronto el DS antiguo durante una rotación puede dejar fuera a validadores que aún usan datos en caché.

La aprobación de dnssec.ds.add, dnssec.ds.replace y dnssec.ds.remove debe mostrar etiqueta, algoritmo, tipo de resumen, huella y las pruebas DNSKEY recogidas de cada servidor autoritativo. También debe quedar claro si la petición añade solapamiento durante una rotación o sustituye el único DS de una vez.

Estas órdenes muestran ambos lados de la cadena:

dig +short example.com DS
dig +short example.com DNSKEY
dig +dnssec example.com A

La primera consulta solicita el DS del lado padre por la ruta normal. La segunda obtiene el conjunto DNSKEY hijo. La tercera muestra la respuesta y los registros DNSSEC usados; en una ruta validadora, las banderas pueden incluir ad si el resolutor autenticó los datos. No reduzcas la revisión a comparar la etiqueta numérica. El resumen y el algoritmo deben corresponder a la DNSKEY prevista y la secuencia debe tener en cuenta las cachés.

El botón activar DNSSEC de un proveedor puede coordinar estos detalles para una persona. Un agente que usa por separado las API del registrador y DNS no hereda esa seguridad. Exige una secuencia propuesta, pruebas de que la nueva clave está publicada y aprobación expresa para cada mutación del lado padre.

La aprobación debe vincular una acción normalizada

El objeto de aprobación debe describir el significado, no mostrar solo una petición HTTP sin procesar. Las URL, nombres de operación y formas JSON cambian. Un nombre interno estable permite reconocer el mismo hecho de seguridad en varios registradores sin fingir que se comportan igual.

Este sobre de acción resulta práctico en el límite de herramientas del agente:

{
  "action": "nameserver.replace",
  "domain": "example.com",
  "before": {
    "nameservers": ["ns1.old-dns.example", "ns2.old-dns.example"]
  },
  "after": {
    "nameservers": ["ns1.new-dns.example", "ns2.new-dns.example"]
  },
  "reason": "CHG-1842 registrar migration",
  "evidence": {
    "authoritative_checks": "passed",
    "checked_at": "2026-07-24T14:25:00Z"
  },
  "request_hash": "sha256:..."
}

La puerta debe derivar la acción del método, endpoint y cuerpo validado. El agente no debe elegir una etiqueta amable y enviar otra petición. Vincula la aprobación a un hash canónico para impedir que obtenga permiso para un conjunto y envíe otro. Si un proveedor asíncrono exige una segunda llamada de confirmación, clasifícala según lo que confirme.

La normalización también expone mutaciones mezcladas. RFC 5731 permite que una actualización toque servidores, contactos, estados y datos de autorización. Si un endpoint admite varias categorías en una carga, separa el flujo cuando la API lo permita. Si no, muestra todas las acciones y aplica la decisión más estricta. domain.update apenas informa.

Rechaza solicitudes que omitan el estado actual. Sin una lectura reciente, la diferencia puede partir de supuestos caducados y sobrescribir el cambio de otra persona. Usa la versión o petición condicional del proveedor cuando exista. Si no existe, lee justo antes de enviar, compara con el before aprobado y detente ante cualquier diferencia.

Lecturas y escrituras necesitan fricción distinta

La aprobación por llamada debe cubrir usos sensibles de la credencial, no enseñar a aceptar sin leer cada inventario inocuo. Si toda lista interrumpe, el mecanismo estorba y la gente deja de revisar. El límite correcto sigue el efecto y la divulgación.

Las consultas DNS públicas no necesitan credencial. Las lecturas autenticadas de inventario, contactos privados, códigos de transferencia, facturación u operaciones pendientes requieren tratamientos distintos. Leer detalles puede revelar datos personales. Obtener un código crea capacidad inmediata de transferencia aunque el catálogo lo llame lectura.

Basta una clasificación pequeña. Listar dominios y leer estado enmascarado puede usar aprobación de sesión porque revela inventario sin cambiarlo. Obtener el código exige aprobación por llamada porque produce un secreto.

Sustituir servidores, retirar bloqueos, cambiar contactos y añadir, reemplazar o quitar DS exige aprobación por llamada porque cambia control o validación. La renovación depende de la política: cuesta dinero pero suele preservar control, por lo que puede preautorizarse dentro de un límite.

Esa última acción no debe recibir una respuesta forzada. Su riesgo difiere del de redirigir o transferir. Un equipo puede preautorizar renovaciones y exigir una persona para toda delegación. Nombrar bien las acciones permite esa diferencia.

No clasifiques solo por método HTTP. Algunas API usan POST para leer y escribir. Tampoco basta una categoría Write. La referencia de Route 53 Domains separa permisos, pero la aprobación necesita además el dominio y la diferencia real.

Quien revisa necesita pruebas, no prosa del agente

La explicación generada por el agente aporta contexto, no prueba. La aprobación debe empezar por hechos recogidos de forma independiente: proceso autenticado, dominio, acción, valores anterior y nuevo y resultados. La razón del agente va después.

Para servidores, recoge SOA y registros esenciales desde cada destino. Para DS, recoge DS padre y DNSKEY hijas. Para retirar un bloqueo, estado y transferencias pendientes. Para contactos, roles y consecuencia informada. El código que reúne pruebas debe estar en el lado de confianza porque el agente puede resumir datos viejos u omitir una diferencia.

La aprobación debe caducar. Una diferencia de hace cinco horas quizá ya no describa el estado. El plazo debe limitar deriva y permitir revisión. No copies una cifra universal: elígela según concurrencia y tiempo de respuesta, y rechaza si cambia before.

Aprobar lotes solo es seguro si todos los elementos son visibles y homogéneos. La misma migración para veinte dominios aparcados puede ser razonable si se enumeran y pasan pruebas. Mezclar servidores, bloqueo y contacto en aprobar migración destruye la información necesaria.

Una denegación debe detener la llamada, no invitar al agente a reformularla hasta conseguir un sí. Registra la denegación con el hash. Una petición distinta puede volver a preguntar, pero debe mostrar claramente la diferencia.

La verificación forma parte de la acción

Una respuesta HTTP correcta suele significar que el registrador aceptó un trabajo, no que registro y DNS ya muestren el estado. Varias API devuelven un identificador para consultar después. Trata envío, finalización y verificación pública como estados distintos.

Una secuencia breve detecta la mayoría de sorpresas:

1. Guarda el identificador y consulta el estado documentado hasta que termine.
2. Lee de nuevo el registrador y compara con el after aprobado.
3. Consulta NS y DS del padre por más de una ruta y luego los servidores directos.
4. Prueba servicios dependientes, incluidos correo y registros de validación cuando existan.
5. Cierra solo cuando coincida o ejecuta la recuperación preparada.

Los reintentos necesitan límites firmes. Repetir una lectura agotada es normal. Repetir una escritura tras respuesta desconocida puede crear trabajos solapados o cambiar dos veces. Antes, consulta por token de idempotencia o lee operación y estado. Sin mecanismo fiable, eleva la ambigüedad.

La reversión también depende de la acción. Recuperar servidores antiguos puede restaurar delegación, pero las cachés retrasan. Reponer el bloqueo cierra exposición si la transferencia no avanzó. Restaurar contacto puede exigir confirmación o nuevo bloqueo. Restaurar un DS antiguo falla si su clave privada ya no está activa. El plan debe nombrar la reversión y requisitos antes de aprobar.

Una ventana de mantenimiento no sustituye la verificación. Las cachés siguen TTL existentes y las operaciones pueden ser asíncronas. Vigila hasta que los estados se comporten como prevé el plan.

Separar credenciales no sustituye el consentimiento

El mínimo privilegio sigue importando. Da al agente solo cuenta, dominios y operaciones necesarios, y excluye facturación o cartera ajena cuando sea posible. Credenciales breves y aislamiento reducen exposición.

Pero dividir un token en cuatro no demuestra intención. El agente aún puede usar mal la credencial de servidores y un proceso comprometido puede esperar. Separar reduce el máximo impacto. El consentimiento decide si este impacto concreto debe ocurrir.

Sesión y llamada resuelven problemas distintos. La sesión decide si este proceso puede actuar durante su ejecución. La llamada interrumpe las pocas operaciones donde alguien debe comparar intención y efecto. Lecturas y llamadas rutinarias siguen en sesión; una clave sensible se pausa en cada uso.

Sallyport separa esas decisiones con puerta de bóveda, autorización para cada proceso nuevo y una opción por clave que pide aprobación en cada uso sin entregar el secreto al agente. Para una credencial amplia, márcala por llamada y haz que la descripción lleve acción y diferencia normalizadas.

No enseñes al agente a guardar temporalmente el token para terminar un lote. Cuando entra en el proceso del modelo, la aprobación es orientativa porque otras llamadas pueden evitarla. El componente que guarda la credencial debe ejecutar la petición y devolver solo el resultado.

El registro debe reconstruir la decisión

Una entrada el agente llamó al registrador no resuelve un incidente. Debe mostrar qué vio la persona, qué aprobó, qué bytes se enviaron, qué devolvió el proveedor y qué observó la verificación. De otro modo demuestra actividad, no autorización.

Conserva identidad de proceso, sesión, aprobador, hora, acción, dominio, objetos anterior y nuevo, hash, identificador, respuesta y verificación. Protege los contactos según las reglas de datos, pero guarda un resumen estable o copia cifrada controlada para distinguir cambios.

Guarda también denegaciones y revocaciones. Si alguien revoca una sesión tras ver una retirada inesperada, la secuencia explica por qué pararon las llamadas. Un registro solo de escritura y encadenado por hash hace visibles las ediciones, y la verificación independiente evita confiar en la misma interfaz.

Sallyport registra sesiones y llamadas desde un registro cifrado encadenado por hash; sp audit verify comprueba la cadena sin conexión sobre el texto cifrado y sin clave de bóveda. Esa verificación prueba que la cadena no cambió, mientras el sobre aporta significado del dominio.

El registro debe sobrevivir a la abstracción del proveedor. Guarda la operación del proveedor junto a la acción normalizada. Así se puede rastrear dnssec.ds.remove hasta la llamada exacta. Conserva bytes canónicos o su resumen y la versión del normalizador para reproducir lo que vio la persona.

Pruébalo antes de confiar. Ejecuta un cambio inocuo en un dominio de prueba, deniega una petición modificada, revoca la sesión y verifica los tres eventos en orden. Simula después un timeout ambiguo y confirma que el flujo lee estado en vez de reenviar. Un registro que solo explica éxitos fallará durante el incidente.

El primer cambio útil consiste en dejar de llamar actualizar dominio a la herramienta. Da nombres propios a servidores, bloqueo, contactos, código y DS. Coloca el consentimiento en la llamada que lleva cada efecto. La credencial puede seguir siendo amplia porque así la diseñó el proveedor, pero la decisión ya no tiene que serlo.