# Alterações de DNS por agentes de IA: torne as revisões mais seguras

As alterações de DNS feitas por agentes de codificação de IA precisam de uma estrutura mais rigorosa que as edições comuns de infraestrutura. Um agente nunca deve apresentar «atualizar o DNS» como uma única aprovação. Ele deve apresentar uma criação, uma edição ou uma exclusão como ações separadas, cada uma com evidências diferentes, perguntas diferentes para o revisor e um tratamento diferente para falhas.

Essa separação parece burocrática até que um agente substitua um registro de e-mail, adicione um CNAME ao lado de dados incompatíveis ou exclua o último registro de endereço durante uma migração. O DNS faz pequenas alterações de texto parecerem inofensivas. Seus efeitos se espalham por resolvedores, clientes, zonas delegadas, verificações de certificados, entrega de e-mails e descoberta de serviços. O revisor precisa ver o verbo exato antes de avaliar o alcance do impacto.

## Os verbos dos registros DNS carregam riscos diferentes

Criar um registro DNS introduz uma nova afirmação em uma zona. O revisor precisa perguntar quem é responsável pelo nome, se o destino está correto, se os novos dados entram em conflito com os dados existentes e se alguém poderia abusar do registro para validar o domínio ou capturar tráfego.

Editar um registro altera uma afirmação existente. Essa ação precisa mostrar o valor antigo e o novo lado a lado. Uma mudança de um endereço para outro pode transferir o tráfego da aplicação. Uma alteração em um registro TXT pode mudar a autenticação do remetente, a verificação de propriedade ou uma configuração consumida por um serviço externo. O estado antigo permite ao revisor distinguir uma substituição deliberada de uma ação baseada em informações obsoletas.

Excluir um registro afirma que a ausência agora é o estado correto. Essa ação tem o maior alcance de falhas, porque o resultado seguro muitas vezes depende de algo fora do DNS. Talvez o novo endpoint precise de tempo para receber tráfego. Talvez outra equipe ainda use um registro TXT de verificação. Talvez o registro faça parte de uma configuração de failover que o agente não consegue inferir a partir de um repositório.

Tratar essas operações como uma única gravação genérica causa cegueira na aprovação. O revisor percebe que todos os cartões dizem a mesma coisa, aprova sem atenção e só tarde demais nota que um deles removeu um RRset inteiro. O controle precisa tornar impossível ignorar essa diferença perigosa.

A terminologia de DNS também exige cuidado. Um nome de proprietário DNS pode conter um RRset, um conjunto de registros com o mesmo nome e tipo. Muitas APIs de provedores expõem um único objeto «registro», mas o comportamento de atualização pode substituir o RRset completo. Se o agente pretende remover um de dois valores A e o provedor substitui o conjunto, ambos podem ser removidos por acidente. Verifique o modelo real de objetos do provedor antes de decidir o significado de uma ação.

## Faça cada solicitação declarar um verbo irreversível

Uma ação de DNS deve conter um verbo: `create`, `edit` ou `delete`. Não aceite na etapa de aprovação um método vago chamado `apply`, `sync` ou `upsert`. Esses nomes são convenientes para um programador e caros para um operador.

A solicitação também precisa dizer se trata de um objeto de registro de um provedor ou de um RRset inteiro. Se a API não puder editar com segurança um membro individual, a ação deve declarar que substituirá o RRset completo e listar todos os valores mantidos. O silêncio sobre esse ponto é como uma alteração aparentemente pequena de endereço se transforma em uma interrupção.

Use um formato de solicitação que preserve a intenção e forneça ao executor estado suficiente para rejeitar divergências:

```json
{
  "action": "edit",
  "zone": "example.net",
  "owner": "api.example.net.",
  "type": "A",
  "expected_rrset": {
    "ttl": 300,
    "values": ["198.51.100.24"]
  },
  "proposed_rrset": {
    "ttl": 300,
    "values": ["198.51.100.81"]
  },
  "reason": "Move the API endpoint after the service owner confirmed health checks",
  "verification": [
    "authoritative lookup returns 198.51.100.81",
    "HTTPS health check succeeds at the new endpoint"
  ]
}
```

Para uma ação de criação, `expected_rrset` deve indicar que o RRset está ausente ou declarar um estado existente permitido quando o modelo do provedor exigir isso. Para uma exclusão, `proposed_rrset` deve indicar explicitamente que o RRset estará ausente. Não represente a ausência com uma string vazia nem omita o campo. Payloads ambíguos produzem logs ambíguos.

O executor deve ler o estado atual da zona imediatamente antes da gravação. Deve comparar essa observação com `expected_rrset` e parar diante de qualquer divergência. Essa é uma disciplina de comparação e troca, mesmo que o provedor de DNS não ofereça um endpoint de comparação e troca.

A RFC 2136, Dynamic Updates in the Domain Name System, coloca essa ideia diretamente no protocolo. Sua seção de pré-requisitos permite que um cliente declare quais RRsets precisam existir ou não existir antes que o servidor aceite uma atualização. A maioria das APIs de DNS hospedado não expõe mensagens de rede RFC 2136, mas a lição operacional continua válida: uma gravação baseada em uma leitura anterior não verificada é insegura.

Um agente pode repetir uma leitura. Ele não deve repetir uma gravação malsucedida alterando o estado esperado para qualquer estado que encontre. Uma divergência significa que outro participante mudou o DNS, que o plano do agente está obsoleto ou que o provedor normalizou os dados de uma forma que o planejador não esperava. Essa condição deve ser encaminhada a um revisor humano.

## A criação precisa de evidências de propriedade e conflito

Um novo registro precisa mostrar que o nome pertence ao serviço pretendido antes de ser aprovado. Um caminho de repositório, uma referência de chamado ou uma solicitação em linguagem natural podem sugerir propriedade, mas nenhum deles prova que um novo nome público está livre para uso.

O agente deve examinar o nome exato do proprietário em todos os tipos de registro antes de propor uma criação. Isso é especialmente importante para registros CNAME. A RFC 1034 diz que, se um RR CNAME estiver presente em um nó, nenhum outro dado deve estar presente nele. Um planejador que verifica apenas a existência de um CNAME pode propor um CNAME em um nome que já contém dados de endereço, e-mail ou TXT. O provedor pode rejeitar a gravação ou, pior, substituir dados segundo uma regra específica do provedor.

A revisão da criação deve mostrar quatro coisas em linguagem simples:

- O nome completo do proprietário, a zona, o tipo de registro, o valor e o TTL.
- Os registros atuais no mesmo nome de proprietário, incluindo os tipos que o agente não modificará.
- Quem solicitou o nome e qual serviço o consumirá.
- A verificação de destino adequada ao tipo de registro.

As verificações de destino dependem dos dados. Para um registro A ou AAAA, o agente pode confirmar que o endereço pertence ao inventário de implantações esperado, se esse inventário existir. Para um CNAME, deve resolver o destino e garantir que o nome esteja completo. Para um registro MX, deve confirmar o nome do host de e-mail e a prioridade com o responsável pelo serviço de e-mail. Para um registro TXT usado por um verificador externo, deve preservar exatamente o valor fornecido, em vez de «limpar» espaços ou aspas com base em suposições.

Não permita que um agente conclua que um subdomínio recém-solicitado é inofensivo por estar abaixo de um domínio conhecido. `login`, `auth`, `mta`, `vpn` e `admin` têm consequências evidentes, mas nomes arbitrários também podem ser importantes. Um nome DNS público se torna uma interface assim que alguém passa a depender dele.

A criação também difere de uma implantação porque a reversão pode não significar exclusão. Se um novo registro apoiar um fluxo de verificação, excluí-lo depois que o fluxo terminar pode interromper a renovação ou uma validação futura. A proposta deve dizer se o registro é temporário, quem decidirá quando ele expirará e se o solicitante aceita sua remoção posterior. Se ninguém for responsável por essa decisão, não invente uma data de expiração.

## Uma edição deve indicar o estado que será substituído

Uma edição só é segura quando a proposta identifica o estado exato que substituirá. «Apontar a aplicação para o novo host» é uma intenção, não uma ação DNS executável.

Exija o RRset anterior em toda solicitação de edição, incluindo os valores que o agente planeja preservar. Considere um RRset A com dois endereços:

```text
Current:  app.example.net. 60 IN A 198.51.100.10
          app.example.net. 60 IN A 198.51.100.11
Proposed: app.example.net. 60 IN A 198.51.100.11
          app.example.net. 60 IN A 198.51.100.12
```

Essa é uma rotação controlada. O revisor consegue ver que a ação mantém um endereço em serviço enquanto substitui o outro. Se o provedor substituir RRsets como uma unidade, enviar apenas `198.51.100.12` seria uma exclusão e uma criação disfarçadas de edição.

Alterações de TTL pertencem ao mesmo cartão de revisão. As equipes costumam reduzir o TTL antes de uma migração e aumentá-lo depois. Ambas as alterações têm consequências. Um TTL menor aumenta a frequência das consultas dos resolvedores e pode expor erros de configuração mais rapidamente. Um TTL maior pode manter o tráfego no endpoint errado por mais tempo depois de uma edição incorreta. Nenhuma dessas alterações deve desaparecer dentro de uma atualização genérica de registro.

O agente também deve distinguir alterações de dados de diferenças de formatação. Os provedores podem canonizar nomes de proprietário, acrescentar um ponto final, dividir strings TXT ou reordenar valores. Um planejador que compare o texto bruto da API produzirá cartões de aprovação desnecessários ou conflitos falsos. Normalize a representação antes da comparação, mas preserve os dados semânticos que o revisor precisa ler.

Não aprove uma edição apenas porque o agente encontrou uma string correspondente no controle de versão. O controle de versão pode conter um estado desejado que perdeu relevância depois de uma alteração emergencial de DNS. O estado atual autoritativo continua sendo a condição para a gravação. Os repositórios explicam a intenção; o DNS mostra o que os clientes podem receber.

## A exclusão precisa de um motivo para a ausência

Uma exclusão deve responder por que o registro pode desaparecer agora, e não apenas por que o agente o considerou indesejável. Registros antigos costumam parecer redundantes até que alguém descubra que eles sustentam um callback legado, um sistema de e-mail, um validador de certificados ou um serviço delegado.

O padrão seguro separa a transferência de tráfego da limpeza. Primeiro, adicione ou edite os dados de substituição. Depois, verifique a resposta autoritativa pretendida e o serviço dependente. Só depois que o responsável aceitar o novo comportamento o agente deve solicitar a exclusão dos dados antigos. Mantenha a solicitação de remoção separada, mesmo quando o provedor puder combiná-la com a edição.

Uma solicitação de exclusão deve incluir estes fatos:

- O RRset exato ou o objeto de registro do provedor a ser removido.
- O serviço ou a equipe que confirmou que não depende mais dos dados.
- A ação de substituição, se houver, e o resultado de sua verificação.
- A verificação planejada depois da remoção.
- Uma declaração sobre se a remoção altera um RRset inteiro.

Registros no apex merecem suspeita adicional. O comportamento do apex da zona varia conforme o provedor, especialmente quando ele oferece aliases ou registros sintéticos que imitam o comportamento de CNAME. Um agente nunca deve traduzir um CNAME desejado em um recurso específico do provedor para o apex sem um revisor que compreenda a semântica desse provedor. Uma palavra conhecida de DNS não garante um comportamento conhecido de DNS.

O cache negativo complica a restauração depois de uma remoção. A RFC 2308 descreve como os resolvedores podem armazenar respostas negativas em cache, incluindo NXDOMAIN e respostas sem dados. Se você excluir um registro e depois restaurá-lo, alguns clientes podem continuar vendo a ausência anterior até que o cache negativo expire. Isso não significa que a exclusão seja proibida. Significa que o plano de reversão precisa incluir o período em que o DNS autoritativo já foi corrigido, mas os usuários ainda recebem uma falha armazenada em cache.

Uma ação de exclusão não deve ampliar silenciosamente seu escopo quando o provedor rejeitar a remoção de um valor individual. O executor deve informar que o provedor exige a substituição de um RRset inteiro e solicitar uma nova ação explícita. Essa aprovação adicional custa menos que explicar por que um registro de endereço supostamente não utilizado desapareceu.

## Os cartões de revisão precisam de contexto além da comparação da zona

Uma comparação bruta fornece dados aos revisores, mas muitas vezes esconde a consequência. Os cartões de revisão devem começar com uma frase curta que indique a operação e o comportamento esperado: «Excluir o registro TXT de verificação obsoleto de `verify.example.net`; o solicitante confirmou que a verificação externa foi concluída.» Em seguida, mostre os registros exatos.

O cartão deve deixar visíveis, sem abrir outra tela, estes campos: verbo da ação, zona, nome do proprietário, tipo, estado antigo, estado proposto, TTL, solicitante, identidade do processo do agente, motivo e plano de verificação. Se a gravação puder afetar um RRset inteiro, diga isso na primeira linha.

Use uma linguagem direta. «Substituir os dois valores A» é melhor que «reconciliar o conjunto de registros». «Remover este registro MX» é melhor que «aplicar a configuração desejada». Os revisores decidem mais rapidamente quando o sistema usa verbos operacionais em vez de abstrações.

Um bom cartão também dá ao revisor um motivo para rejeitar a ação. Para uma criação de CNAME, mostre os dados conflitantes nesse nome de proprietário. Para uma edição, mostre se o estado atual difere do esperado. Para uma exclusão, mostre quando o agente não tiver confirmação do responsável pelo serviço. A interface de aprovação deve expor a incerteza, não escondê-la em um log de execução.

Não transforme os revisores em um mecanismo manual de políticas oferecendo uma grande caixa de exceção em texto livre. Se o agente solicitar uma ação fora do formato normal, exija que prepare uma nova ação com as evidências ausentes. Um revisor que precise reconstruir a semântica do DNS a partir de uma conversa acabará aprovando um erro.

### Um exemplo completo de revisão

Suponha que um agente precise transferir `api.example.net` para um endereço de substituição. Um cartão ruim diz: «Atualizar o DNS da API.» Ele não dá ao revisor nenhuma forma de perceber que o provedor substituirá um RRset com dois membros.

Uma edição revisável diz: «Substituir `198.51.100.24` por `198.51.100.81` no RRset A de `api.example.net`; manter `198.51.100.25`; conservar o TTL 300.» Em seguida, exibe os RRsets completos atual e proposto, identifica o responsável pelo serviço e informa que o agente consultará o servidor de nomes autoritativo e executará a verificação de integridade aprovada depois da gravação.

Se o revisor preferir uma transferência sem sobreposição, deverá rejeitar esse cartão e solicitar explicitamente essa intenção. O agente não deve decidir que a sobreposição é desnecessária só porque os arquivos de implantação contêm um endereço novo.

## Os caches de DNS tornam o momento parte da aprovação

O DNS autoritativo e o DNS recursivo respondem a perguntas operacionais diferentes. O servidor autoritativo informa os dados publicados atualmente na zona. Um resolvedor recursivo pode retornar uma resposta anterior até que expire o TTL que recebeu. Um navegador, sistema operacional, runtime da aplicação, balanceador de carga ou resolvedor interno pode adicionar outro cache.

Por isso, a aprovação deve indicar o ponto de verificação desejado. «Os servidores autoritativos retornam a nova resposta» verifica a gravação. «Um resolvedor público retorna a nova resposta» verifica parte da propagação. «A aplicação atende tráfego no novo destino» verifica o resultado de que os usuários precisam. São verificações distintas.

Use comandos que tornem visível a origem de uma resposta. Substitua os nomes e o endereço pelo servidor autoritativo real da zona:

```sh
dig @ns1.example.net api.example.net A +noall +answer

; expected answer shape
api.example.net. 300 IN A 198.51.100.81

dig @1.1.1.1 api.example.net A +noall +answer

; resolver answer can retain an older value with a lower remaining TTL
api.example.net. 117 IN A 198.51.100.24
```

A primeira consulta verifica o estado publicado em um servidor autoritativo. A segunda verifica o que um resolvedor recursivo retorna naquele momento. Nenhuma das duas prova que todos os clientes mudaram. Registre ambos os resultados no log da ação para que quem responder a um incidente consiga distinguir uma gravação malsucedida no provedor de um comportamento esperado do cache.

Não presuma que um TTL seja uma contagem regressiva para a consistência global. Um resolvedor recebe um TTL quando armazena uma resposta em cache, portanto diferentes resolvedores começam a contagem em momentos diferentes. Alguns clientes também podem manter conexões ou armazenar a configuração da aplicação de forma independente do DNS. Um plano de migração precisa de verificação no serviço, não de uma promessa baseada na passagem de alguns segundos.

Alterações de delegação DNS exigem ainda mais cuidado. Editar registros NS, registros glue, registros DS ou outros dados relacionados à delegação pode afetar a resolução além da zona filha. O agente deve categorizar essas alterações como uma classe separada e exigir um revisor responsável pela relação entre a zona pai e a filha. Não as inclua em um fluxo comum de registros de host.

## Credenciais amplas de DNS são o atalho errado

Dar a um agente uma credencial do provedor capaz de editar todas as zonas parece eficiente, porque ele consegue concluir a tarefa sem esperar uma alteração de integração. Ainda assim, esse é o limite errado. Uma injeção de prompt, uma instrução equivocada no repositório ou um plano confuso passa a ter autoridade muito maior que a necessária para o serviço solicitado.

Limite cada caminho de execução às zonas e operações necessárias. Separe o acesso de leitura do acesso de gravação quando o provedor permitir. Mantenha um vínculo entre a identidade de um repositório ou serviço e as zonas que ele pode solicitar. Rejeite uma solicitação que indique uma zona fora desse vínculo antes que ela alcance as credenciais do provedor.

O limite deve restringir as ações, não apenas esconder um token. Um agente que possa pedir a um intermediário para enviar solicitações arbitrárias à API do provedor ainda terá controle amplo se o intermediário aceitar caminhos, métodos, cabeçalhos e corpos de solicitação arbitrários. A camada de ações deve controlar o formato da chamada do provedor para as operações de DNS e rejeitar campos fora do esquema.

É nesse ponto que endpoints genéricos de «upsert» causam problemas. Eles permitem que um agente reúna criação, edição e exclusão em um único corpo de solicitação, muitas vezes com padrões do provedor que o revisor não consegue ver. Defina métodos de execução separados e faça cada método validar as evidências exigidas pela ação. Um método de exclusão deve recusar um payload que contenha um estado de substituição. Um método de edição deve recusar a ausência do estado esperado.

Mantenha as credenciais de DNS fora do processo do agente. Para equipes que usam Sallyport, o aplicativo pode executar a chamada HTTP enquanto as credenciais permanecem no cofre criptografado, de modo que o agente receba o resultado, não a credencial. Isso resolve a exposição da credencial, mas não decide se uma ação DNS proposta é sensata; essa função continua pertencendo ao esquema da ação e às evidências de aprovação.

## Um plano obsoleto pode excluir o registro ativo errado

Uma falha comum começa quando um agente lê o DNS no início de uma tarefa longa de programação. Ele vê `cdn.example.net` com um destino CNAME e planeja substituí-lo depois de uma implantação. Enquanto o agente trabalha, um engenheiro de plantão atualiza o destino para redirecionar o tráfego durante um incidente.

Mais tarde, o agente termina e envia a solicitação de substituição antiga. Se a chamada ao provedor usar uma atualização genérica ou uma sequência incondicional de excluir e criar, ela substituirá a alteração feita pelo engenheiro de plantão. A solicitação pode parecer correta em relação ao estado observado horas antes. Ela está errada em relação à zona ativa.

Leituras recentes antes das gravações evitam essa falha específica. O executor lê o RRset, compara-o com o `expected_rrset` da ação e recusa a gravação quando o destino do plantão é diferente. A recusa deve manter ambos os valores no log e informar ao revisor que outro participante alterou o registro. Ela não deve tentar fazer uma mesclagem.

Mesclar dados DNS exige conhecimento do serviço. Dois valores de endereço podem representar capacidade deliberada, uma sobreposição temporária, uma divisão geográfica ou uma rota de emergência. Um agente não consegue inferir isso com segurança apenas porque reconhece um único endereço em um arquivo de implantação.

A mesma regra vale depois de uma falha parcial. Se um provedor informar um timeout, o executor deve ler o estado autoritativo do provedor antes de tentar novamente. A gravação pode ter sido bem-sucedida mesmo quando o cliente nunca recebeu a resposta. Novas tentativas cegas criam valores duplicados em algumas APIs e comportamentos de substituição indesejados em outras.

## Os logs devem preservar o que o revisor realmente aprovou

Um registro de auditoria de DNS precisa conter mais que um evento de atividade do provedor informando que um registro mudou. Armazene a ação proposta, o estado observado antes da execução, a decisão de aprovação, o processo que a solicitou, a resposta do provedor e os resultados da verificação. Preserve dados suficientes para reconstruir se o executor seguiu a solicitação aprovada.

Um log à prova de adulteração acrescenta uma propriedade útil: quem investigar um incidente pode verificar se o histórico foi alterado posteriormente. Isso importa quando as respostas DNS já saíram dos caches e as pessoas começam a depender da memória ou de capturas de tela. As evidências devem continuar compreensíveis sem a conversa original do agente.

Separe o registro da execução do registro da chamada. O registro da execução responde qual processo de agente recebeu autoridade e quando essa autoridade terminou. O registro da chamada responde qual ação DNS exata foi solicitada, se alguém a aprovou e o que aconteceu. A revogação imediata de uma execução deve interromper chamadas posteriores, mas não pode desfazer uma gravação DNS já aceita pelo provedor. O histórico de auditoria precisa deixar esse limite claro.

Use IDs de ação tanto no cartão de aprovação quanto no registro de execução. Se um operador perceber um resultado incorreto, deve conseguir localizar a exclusão ou edição aprovada exata sem pesquisar um fluxo indistinto de saída do agente. O ID deve conectar a solicitação, a comparação de estado, a resposta do provedor e os comandos de verificação.

A primeira mudança prática é pequena: proíba gravações DNS genéricas na etapa de aprovação. Force cada solicitação a ser uma criação, edição ou exclusão, exija o RRset esperado completo para edições e exclusões e rejeite divergências antes da execução. Essa única restrição torna o trabalho DNS proposto pelo agente legível o bastante para que uma pessoa detecte os erros que realmente importam.