A segurança de registradores de domínio exige aprovação por chamada

Dar a um agente de IA uma credencial de API de registrador não lhe dá um poder único e coerente. Dá ao agente vários poderes sem relação entre si que, por acaso, ficam atrás do mesmo segredo: redirecionar o domínio, prepará-lo para transferência, alterar quem recebe avisos de recuperação e modificar a cadeia de confiança do DNSSEC. A segurança de registradores de domínio falha quando uma camada de aprovação trata todas essas chamadas como intercambiáveis.

Toda chamada ao registrador que muda estado merece uma decisão vinculada à ação exata, ao domínio, ao valor antigo e ao valor proposto. Uma pessoa pode aprovar a substituição de nameservers durante uma migração planejada e rejeitar a remoção de bloqueio, a alteração de e-mail do registrante ou a exclusão de DS feita na mesma execução. A aprovação de sessão por si só não consegue expressar essa diferença.

Uma credencial esconde várias fronteiras de segurança

Uma credencial de registrador é um fato de autenticação, não uma declaração de intenção humana. Mesmo quando um provedor oferece permissões granulares de API, as equipes costumam colocar várias ações de escrita necessárias em uma única função para que um trabalho de automação possa terminar. Outros provedores expõem um token amplo de registrador. Nos dois casos, a posse responde apenas quem pode pedir. Não responde se esta alteração específica deve acontecer agora.

Os protocolos subjacentes não fingem que essas operações são equivalentes. O RFC 5731, o mapeamento de domínio EPP usado entre registradores e registros, descreve associações de nameservers, associações de contatos, valores de status e informações de autorização como atributos separados do domínio. Seu comando de atualização pode adicionar ou remover nameservers e contatos, alterar o registrante, mudar informações de autorização e modificar valores de status do cliente. Uma API conveniente pode colocar essas operações sob uma credencial, mas o estado do registro mantém seus significados separados.

Um registrador público de nuvem torna a mesma distinção visível em sua lista de comandos. A API Route 53 Domains tem operações separadas para UpdateDomainNameservers, UpdateDomainContact, DisableDomainTransferLock, AssociateDelegationSignerToDomain e DisassociateDelegationSignerFromDomain. Essa lista é uma evidência útil porque nomeia as decisões que um sistema de aprovação deve preservar, em vez de reduzi-las a registrar.write.

Uso quatro perguntas antes de qualquer agente receber acesso ao registrador:

• Esta chamada pode redirecionar a resolução de todo o domínio?
• Ela pode facilitar um furto ou uma recuperação futura?
• Ela pode mudar quem recebe mensagens de controle ou verificação?
• Ela pode fazer resolvedores validadores rejeitarem respostas DNS corretas?

Se duas chamadas produzem respostas diferentes, são ações de aprovação diferentes. Compartilhar uma chave de API não as transforma em uma só.

Uma alteração de nameservers delega toda a zona

A substituição de nameservers entrega a autoridade DNS ao novo conjunto de servidores, por isso tem um raio de impacto muito maior do que editar um registro. O RFC 8499 define delegação como a adição, pelo pai, de um conjunto de registros NS para a origem filha. Quando os caches seguem essa delegação, os novos servidores autoritativos podem responder pelos endereços web da zona, servidores de e-mail, registros de descoberta de serviços e registros TXT de verificação.

A última categoria torna o risco fácil de subestimar. O RFC 8555 diz que um cliente ACME pode provar o controle de um domínio ao provisionar um valor TXT em _acme-challenge. Um operador que controla a zona delegada pode responder a esse desafio e solicitar certificados para nomes sob o domínio, sujeito às verificações da autoridade certificadora. Portanto, uma alteração de nameservers não é apenas uma configuração de hospedagem.

A aprovação deve mostrar os conjuntos completos de servidores antigos e novos, não uma frase como update DNS. Os conjuntos importam porque uma migração costuma adicionar servidores antes de remover os antigos, enquanto algumas APIs de registrador substituem todo o conjunto em uma chamada. O revisor precisa ver se a solicitação preserva todos os servidores desejados, se há endereços glue envolvidos e se os servidores de destino já respondem com autoridade pela zona.

Antes da aprovação, consulte diretamente cada servidor proposto em vez de confiar em um cache recursivo:

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

Uma verificação saudável retorna uma linha SOA de cada servidor e os destinos MX esperados. Saída vazia, números de série inconsistentes ou respostas sem autoridade exigem investigação. O plano exato de migração determina se os números de série já devem coincidir, mas o revisor jamais deve aprovar o nome de um servidor que não respondeu pela zona.

O registro de aprovação deve identificar essa ação como nameserver.replace, incluir a solicitação ordenada e uma diferença de conjuntos normalizada, e informar se a chamada também altera glue. Não a esconda em uma atualização genérica de domínio, pois um erro aparentemente plausível do agente aqui pode redirecionar todos os serviços de uma vez.

Remover um bloqueio de transferência abre uma janela

Desativar um bloqueio de transferência não transfere um domínio, mas remove um controle que impede uma transferência. A ICANN chama o bloqueio familiar do registrador de clientTransferProhibited ou status semelhante. O RFC 5731 diz que uma solicitação de transferência deve ser rejeitada enquanto clientTransferProhibited ou serverTransferProhibited se aplica.

Essa distinção importa durante a revisão. Um agente pode precisar corretamente remover o bloqueio de um domínio antes de uma mudança planejada, mas uma remoção inesperada ainda é perigosa porque cria uma pré-condição útil para outro agente malicioso. Trate transfer_lock.disable como uma ação própria e exija que a solicitação informe o registrador de destino, o ticket de alteração e o momento esperado para novo bloqueio ou conclusão. Esses campos não fazem o registrador cumprir o plano, mas dão ao aprovador contexto suficiente para rejeitar uma remoção de bloqueio sem explicação.

O código de autorização é um segredo separado e uma decisão separada. Obtê-lo nunca deve ficar escondido dentro da aprovação para remover o bloqueio. Um plano de controle útil pede uma vez para remover o bloqueio e outra para obter ou usar o código de autorização de transferência. Se o fluxo também alterar o registrante, a ordem importa porque a Política de Transferência da ICANN exige um bloqueio de 60 dias entre registradores após uma Alteração de Registrante em casos cobertos, a menos que o registrador tenha oferecido a exclusão antes da alteração e o registrante a tenha escolhido.

Uma recomendação popular diz para deixar o domínio bloqueado e, por isso, considerar segura a automação do registrador. O bloqueio ajuda, mas esse conselho para um passo cedo demais. Uma credencial que pode remover o bloqueio também pode eliminar a proteção. A aprovação por chamada torna a remoção visível no momento em que importa, enquanto uma política permanente que apenas verifica o estado atual de bloqueio pode ser invalidada pela próxima solicitação de API.

Ativar o bloqueio costuma ser uma correção de menor risco, mas ainda é uma escrita com consequências operacionais. Pode bloquear uma transferência legítima já em andamento. Mostre o estado da transferência pendente e deixe uma pessoa confirmar, a menos que um procedimento de incidente autorize explicitamente o novo bloqueio de emergência.

Alterações de contato mudam o caminho de recuperação

Uma atualização de contato de registrante ou administrativo altera quem recebe avisos importantes e pode mudar a elegibilidade para transferência. Ela não redireciona o tráfego imediatamente, o que tenta as equipes a classificá-la abaixo do trabalho com nameservers. Essa classificação ignora como a recuperação de domínio acontece na prática.

A ICANN orienta registrantes a manter as informações de contato atualizadas porque os registradores enviam avisos de proteção e gestão por e-mail. Sua Política de Transferência também relaciona uma Alteração de Registrante a um bloqueio de transferência de 60 dias em certas circunstâncias. Um agente que troca o e-mail do registrante instantes antes de uma transferência planejada pode atrasar o trabalho. Um invasor que altera um contato acessível pode interferir em notificações ou na recuperação futura, conforme o processo do registrador e do registro.

O cartão de aprovação precisa de uma diferença campo a campo. contact.update é vago demais quando a solicitação altera de uma só vez endereço de e-mail, telefone, organização, configuração de privacidade e identidade do registrante. Mostre cada valor antigo e novo, marque quais funções de contato mudam e exiba se o registrador informa uma restrição de transferência resultante. A ocultação pode proteger dados pessoais em logs rotineiros, mas a pessoa que autoriza uma alteração sensível de identidade precisa ver o suficiente para reconhecer o destinatário pretendido.

Não deixe um agente resolver uma atualização de contato que falhou alterando campos repetidamente até a API aceitá-los. Os registros têm regras de validação diferentes, e alguns domínios de código de país aplicam requisitos adicionais. Um fluxo mais seguro valida a carga, pede aprovação para a diferença final, envia-a uma vez e registra o identificador de operação do provedor. Se o provedor processar a alteração de forma assíncrona, a ação permanece pendente até uma leitura confirmar o estado pretendido.

A privacidade de contato é outra ação distinta. Alterar a exposição da privacidade não é o mesmo que alterar o registrante subjacente. Um revisor pode aceitar uma mudança de privacidade e rejeitar uma mudança de propriedade, portanto um sistema de aprovação não deve combiná-las apenas porque um fornecedor usa um endpoint.

Alterações de DNSSEC podem fazer respostas corretas falharem

Uma alteração de delegação DNSSEC modifica a cadeia pela qual resolvedores validadores autenticam a zona filha. O RFC 4034 é preciso: o registro DS se refere a uma DNSKEY usando uma tag de chave, algoritmo e resumo, e o registro DS fica no lado pai da delegação. A DNSKEY correspondente fica na zona filha. APIs de registrador frequentemente levam o material DS ao registro porque o registrante não pode editar diretamente a zona pai.

Um nameserver errado pode redirecionar respostas. Um registro DS errado pode fazer resolvedores marcarem respostas genuínas como inválidas. É um modo de falha diferente e exige uma revisão diferente. Excluir DS pode transformar uma zona delegada com segurança em uma delegação insegura depois que os caches forem atualizados. Adicionar um DS que não corresponde a uma DNSKEY publicada pode interromper a validação. Remover o DS antigo cedo demais durante a rotação de chave pode deixar validadores dependentes de dados em cache sem saída.

A aprovação para dnssec.ds.add, dnssec.ds.replace e dnssec.ds.remove deve mostrar a tag de chave, algoritmo, tipo de resumo, impressão digital do resumo e a evidência DNSKEY coletada de todos os servidores autoritativos. O revisor também deve ver se a solicitação adiciona sobreposição durante uma rotação ou substitui o único DS de uma vez.

Estes comandos mostram os dois lados da cadeia:

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

A primeira consulta pergunta pelo caminho de resolução normal pelos dados DS do lado pai. A segunda obtém o conjunto DNSKEY filho. A terceira mostra a resposta e os registros DNSSEC usados na validação. Em um caminho validador, os indicadores de resposta podem incluir ad quando o resolvedor autenticou os dados. Não reduza a revisão a conferir apenas a tag numérica da chave. O resumo e o algoritmo devem corresponder à DNSKEY pretendida, e a sequência de implantação deve levar os caches em conta.

O fluxo de um clique para enable DNSSEC de um host DNS pode coordenar esses detalhes para uma pessoa. Um agente que usa separadamente APIs de registrador e DNS não herda essa proteção automaticamente. Exija uma sequência proposta, evidência de que a nova chave está publicada e aprovação explícita para cada modificação do lado pai.

A aprovação deve se vincular a uma ação normalizada

O objeto de aprovação deve descrever o significado, em vez de expor apenas uma solicitação HTTP bruta. URLs, nomes de operações do provedor e formatos JSON variam. Um nome interno estável de ação permite ao revisor reconhecer o mesmo evento de segurança entre registradores sem fingir que os provedores se comportam de forma idêntica.

Este é um envelope de ação prático para a fronteira de ferramentas de um 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:..."
}

O gateway deve derivar a ação do método, do endpoint e do corpo validado. O agente não deve escolher um rótulo amigável de ação enquanto envia uma solicitação diferente. Vincule a aprovação a um hash canônico da solicitação para que o agente não consiga obter consentimento para um conjunto de nameservers e enviar outro. Se um provedor assíncrono exigir uma segunda chamada para confirmar uma operação, classifique e aprove essa chamada conforme o que ela efetivamente confirma.

A normalização também revela mutações combinadas. O RFC 5731 permite que um único comando de atualização de domínio toque nameservers, contatos, valores de status e informações de autorização. Se um endpoint de registrador aceitar várias categorias em uma carga, separe o fluxo antes da aprovação quando a API permitir. Quando não permitir, mostre todas as ações na aprovação e aplique a decisão mais rigorosa. Um rótulo como domain.update diz quase nada ao revisor.

Rejeite solicitações que omitem o estado atual. Sem uma leitura recente, a diferença pode ser criada com premissas desatualizadas e sobrescrever a alteração de outra pessoa. Use o token de versão ou recurso de solicitação condicional do provedor quando disponível. Se ele não oferecer nenhum dos dois, leia imediatamente antes do envio, compare o estado normalizado com o valor before aprovado e pare diante de qualquer divergência.

Leituras e escritas precisam de níveis diferentes de atrito

A aprovação por chamada deve cobrir usos sensíveis da credencial do registrador, sem treinar pessoas a clicar em leituras de inventário inofensivas. Se toda operação de listagem interromper um desenvolvedor, o mecanismo de aprovação vira um obstáculo e os revisores deixam de ler. A fronteira correta segue o efeito e a exposição.

Consultas DNS públicas sem autenticação não precisam de credencial do registrador. Leituras autenticadas de inventário de domínios, dados privados de contato, códigos de transferência, dados de cobrança ou operações pendentes merecem tratamento diferente. Uma leitura de detalhes de domínio pode expor informações pessoais de contato. A obtenção de um código de autorização cria capacidade imediata de transferência, embora um catálogo de API possa chamá-la de leitura.

Use uma pequena tabela de classificação e mantenha-a fácil de entender:

Listar domínios gerenciados e ler status mascarado geralmente pode usar aprovação de sessão, pois revela inventário sem alterá-lo. Obter um código de autorização de transferência precisa de aprovação por chamada porque produz um segredo que pode viabilizar uma transferência.

Substituição de nameservers, remoção de bloqueio de transferência, alterações de contato administrativo ou de registrante, e toda adição, substituição ou remoção de dados DS precisam de aprovação por chamada porque cada uma muda o controle ou a validação. A renovação depende da política: custa dinheiro, mas normalmente preserva o controle, então uma equipe pode pré-autorizá-la dentro de um limite de gastos definido.

A última linha não é forçada à mesma resposta. A renovação tem efeitos financeiros e no ciclo de vida, mas seu risco difere de redirecionar ou transferir um domínio. Equipes podem pré-autorizar renovação dentro de um limite de gastos e ainda exigir uma pessoa para cada alteração de delegação. Esse é o objetivo de nomear ações com clareza.

Não use somente o método HTTP como classificador. Algumas APIs usam um POST genérico para leituras e escritas. Também não use uma categoria ampla do provedor como Write. A referência de autorização do Route 53 Domains lista corretamente a substituição de nameservers, a atualização de contatos e a remoção de bloqueio de transferência como permissões separadas, mas uma camada de aprovação ainda precisa do domínio real e da diferença de valores.

O revisor precisa de evidências, não de texto do agente

Uma explicação gerada pelo agente é contexto, não prova. A aprovação deve começar por fatos obtidos de forma independente: o processo autenticado, o domínio exato, a ação normalizada, os valores antes e depois e os resultados das verificações. Coloque o motivo do agente depois desses campos.

Para uma solicitação de nameserver, colete verificações autoritativas de SOA e de registros essenciais de cada servidor proposto. Para uma solicitação DS, colete os conjuntos atuais de DS pai e DNSKEY filho. Para remoção de bloqueio, colete o status atual e qualquer transferência pendente. Para uma alteração de contato, mostre as funções alteradas e a consequência de bloqueio declarada pelo registrador. O código que coleta essas evidências deve ficar no lado confiável da fronteira, pois um agente pode resumir acidentalmente uma saída desatualizada ou omitir uma diferença inconveniente.

A aprovação precisa expirar. Uma diferença de nameservers de cinco horas atrás pode não descrever mais o estado atual. A expiração deve ser curta o suficiente para limitar desvios e longa o bastante para uma pessoa inspecionar as evidências. Evite um número universal copiado para todo fluxo. Defina-o segundo o modelo de concorrência do registrador e o tempo de resposta da equipe, e rejeite se o estado before mudar.

A aprovação em lote só é segura quando todos os integrantes estão visíveis e são homogêneos. Aprovar a mesma migração de nameservers para vinte domínios estacionados pode ser razoável se o cartão listar todos os domínios e as evidências forem aprovadas para cada um. Combinar uma alteração de nameservers, remoção de bloqueio e atualização de contato em um botão de «aprovar migração» destrói as distinções de que o revisor precisa.

Uma recusa de aprovação deve interromper a chamada, não convidar o agente a reformular e tentar novamente até alguém clicar em sim. Registre a recusa com o hash da solicitação. Uma solicitação materialmente alterada pode pedir novamente, mas o sistema deve tornar a diferença evidente.

A verificação faz parte da ação

Uma resposta HTTP bem-sucedida muitas vezes significa que o registrador aceitou um trabalho, não que o registro e o DNS agora exibem o estado pretendido. Várias APIs de domínio retornam um identificador de operação para consulta posterior. Trate o envio, a conclusão pelo provedor e a verificação pública como estados separados no diário.

Uma sequência compacta de verificação detecta a maior parte das surpresas após uma alteração sensível:

1. Salve o identificador de operação do provedor e consulte seu status documentado até ele chegar a um estado terminal.
2. Leia novamente o estado do registrador e compare-o com o objeto after aprovado.
3. Consulte os dados NS e DS do lado pai por mais de um caminho recursivo, depois consulte diretamente os servidores autoritativos.
4. Teste um pequeno conjunto de serviços que dependem da zona, incluindo roteamento de e-mail e registros de validação de certificado quando esses serviços existirem.
5. Encerre a alteração apenas depois que as evidências coincidirem ou execute o caminho de recuperação preparado.

Este é um dos poucos casos em que as tentativas precisam de limites diretos. Tentar novamente uma leitura que expirou é normal. Tentar de novo uma solicitação que muda estado após uma resposta desconhecida pode criar trabalhos sobrepostos ou alternar um valor duas vezes. Antes de tentar de novo, consulte pelo token de idempotência ou leia a operação atual e o estado do domínio. Se o provedor não oferecer mecanismo de idempotência, encaminhe o resultado ambíguo em vez de adivinhar.

A reversão também varia conforme a ação. Restaurar nameservers antigos pode recuperar a delegação, mas os caches atrasam a convergência. Ativar novamente um bloqueio de transferência pode encerrar uma exposição se nenhuma transferência tiver avançado. Restaurar um contato pode acionar outra confirmação ou bloqueio. Restaurar um DS antigo pode falhar se a chave privada de assinatura correspondente não estiver mais ativa. O registro de recuperação deve nomear a reversão específica da ação e seus pré-requisitos antes da aprovação.

Uma janela de manutenção não substitui a verificação. Alterações DNS se propagam pelos caches conforme os TTLs existentes, e operações de registrador podem ser assíncronas. Mantenha o monitoramento até que os estados antigo e novo se comportem como prevê o plano de migração.

Credenciais separadas não substituem consentimento por chamada

O princípio do menor privilégio continua importante. Dê a um agente acesso apenas à conta de registrador, aos domínios e às operações de que ele precisa, e mantenha acesso à cobrança ou a portfólios não relacionados fora do escopo quando o provedor permitir. Credenciais de curta duração e isolamento de processos reduzem ainda mais a exposição.

Mas dividir um token amplo em quatro credenciais não prova intenção. O agente ainda pode usar indevidamente a credencial de nameserver dentro do escopo permitido, e um processo comprometido pode esperar o token certo aparecer. Credenciais separadas reduzem o raio máximo de impacto. O consentimento por chamada decide se um impacto específico deve ocorrer.

A autorização de sessão e a aprovação por chamada resolvem problemas diferentes. A autorização de sessão responde se este processo de agente pode agir pelo gateway durante sua execução. A aprovação por chamada interrompe as poucas operações em que uma pessoa precisa comparar a intenção com os efeitos exatos. Leituras e chamadas rotineiras de baixo impacto podem seguir na sessão, enquanto uma chave de registrador marcada para aprovação pausa a cada uso.

O Sallyport implementa essa separação com uma barreira de cofre, autorização para cada novo processo de agente e uma opção por chave que exige aprovação em todo uso, mantendo o segredo do registrador fora do agente. Para uma credencial ampla de registrador, marque a chave por chamada e faça a descrição da solicitação trazer a ação normalizada e a diferença descritas acima.

Não ensine o agente a manter o token de API temporariamente para poder concluir um lote. Quando o token entra no processo do modelo, a aprovação vira consultiva porque chamadas posteriores podem contornar a barreira. O componente que armazena a credencial deve executar ele mesmo a solicitação aprovada e retornar apenas o resultado.

O registro de auditoria precisa reconstruir a decisão

Uma entrada de auditoria dizendo agent called registrar não resolve um incidente. O registro precisa mostrar o que a pessoa viu, o que aprovou, quais bytes foram enviados, o que o provedor retornou e o que a verificação observou depois. Caso contrário, a equipe pode provar atividade sem provar autorização.

Para cada chamada sensível, preserve a identidade do processo, o identificador da sessão, o aprovador, o horário da decisão, a ação normalizada, o domínio, os objetos antes e depois, o hash da solicitação, o identificador de operação do provedor, o status da resposta e o resultado da verificação. Proteja valores pessoais de contato conforme as regras de tratamento de dados, mas mantenha um resumo estável ou uma cópia criptografada controlada para que investigadores possam distinguir duas alterações.

Guarde também eventos de recusa e revogação. Se um operador revoga uma sessão de agente após ver uma solicitação inesperada de remoção de bloqueio, essa sequência explica por que chamadas posteriores pararam. Um log somente de gravação, encadeado por hash, torna alterações silenciosas detectáveis, enquanto exportação ou verificação independente evita depender da mesma interface que realizou a ação.

O Sallyport registra sessões de agentes e chamadas individuais em um único log de auditoria criptografado e encadeado por hash. sp audit verify verifica a cadeia offline sobre texto cifrado, sem a chave do cofre. A verificação prova que a cadeia registrada não foi alterada, enquanto o envelope de ação fornece o significado específico do domínio de que investigadores precisam.

O registro de aprovação também precisa sobreviver à abstração do provedor. Armazene o nome da operação do provedor ao lado da ação normalizada, não no lugar dela. Isso permite que um investigador rastreie um rótulo portátil como dnssec.ds.remove até a chamada exata da API, sem obrigar todos os revisores a aprender o vocabulário de cada fornecedor. Preserve os bytes canônicos da solicitação ou seu resumo criptográfico e registre qual versão de normalização produziu a ação. Se o classificador mudar mais tarde, investigadores poderão reproduzir a decisão que o operador realmente viu, em vez de aplicar lógica nova a eventos antigos.

Teste esse registro antes de confiar nele. Execute uma alteração inofensiva em um domínio de teste pela aprovação, recuse uma solicitação modificada com o mesmo motivo declarado, revogue a sessão do agente e verifique se o diário preserva os três eventos na ordem correta. Depois, simule uma expiração ambígua do provedor e confirme que o fluxo lê o estado em vez de reenviar às cegas. Um projeto de auditoria que funciona apenas para chamadas bem-sucedidas falhará no incidente que deveria explicar.

A primeira alteração útil é deixar de chamar a ferramenta do registrador de update domain. Dê nomes próprios à substituição de nameservers, remoção de bloqueio de transferência, mutação de contato, obtenção de código de autorização e mutação de DS. Depois, coloque o consentimento humano na chamada que produz cada efeito. A credencial pode continuar ampla porque o provedor a projetou assim, mas a decisão não precisa ser.