Resumo

  • A revisão 06 de DNS Update with JSON usa uma estrutura mínima e não extensível para transportar ações add e delete por cópia e colagem, sem comentários capazes de pressionar o usuário dentro do pacote.
  • Tirar a persuasão da estrutura não autentica quem a produziu. A operadora DNS ainda precisa provar autoridade sobre a zona, aplicar política local, confirmar o commit atômico e observar o estado efetivamente publicado.

Um campo que o atacante não pode acrescentar

Um serviço quer que o cliente instale um registro. Em uma estrutura extensível, ele poderia enviar o dado e mais um campo: “urgente”, “necessário para manter a conta”, “aprovado pela segurança”. A frase não mudaria os bytes do RRset, mas mudaria a disposição da pessoa que clica.

draft-hoffman-duj-06 escolhe arrays em vez de objetos justamente para reduzir esse risco. Um DUJ tem dois elementos externos: o identificador DUJS ou DUJ64 e um array não vazio de atualizações. Cada ação contém apenas add ou delete e uma cadeia em formato de arquivo de zona. Não há espaço semântico para comentários convincentes. O desenho também não é extensível; uma futura versão deve mudar o primeiro identificador.

É uma boa restrição. Ela impede que o envelope técnico carregue uma justificativa que pareça parte do protocolo. Mas não impede que a página ao redor use a mesma urgência, que um e-mail falsificado entregue a cadeia, ou que uma relação de fornecedor transforme recomendação em pressão.

O formato pode separar instrução de narrativa. Não pode decidir em qual narrativa confiar.

Menos tradução humana, menos erros ambíguos

Hoje, a pessoa recebe frases como “adicione este TXT”. Ela precisa mapear nome, tipo, TTL e valor para campos que variam entre operadoras. Pode substituir um RRset quando deveria acrescentar uma entrada, omitir um ponto final ou deixar o editor converter aspas.

DUJ entrega uma lista ordenada. DUJS mantém os dados relativamente legíveis, mas proíbe comentários, diretivas e quebras de linha embutidas. DUJ64 codifica os dados em Base64 para transportar formas difíceis com menos risco de transcrição; em troca, o conteúdo deixa de ser legível para a maioria das pessoas, embora a ação continue visível.

Base64 não é criptografia. I-JSON não é assinatura. A forma genérica de RFC 3597 para um tipo ainda não registrado não é autorização. São propriedades de representação.

O nome proprietário também tem limite. Curingas são proibidos. Um nome novo pode estar abaixo de um corte de zona, e a operadora precisa determinar se a conta realmente pode criá-lo. A semelhança textual entre pai e filho não transfere controle.

A pessoa transporta bytes entre duas relações

O primeiro vínculo é entre serviço e usuário. O segundo é entre usuário e operadora DNS. A seção de segurança diz que a autenticidade da origem e a integridade do DUJ são tão fortes quanto a conexão de cada trecho.

O login na operadora identifica a sessão atual; não demonstra qual serviço gerou a cadeia. A sessão autêntica no serviço não concede, por si, poder corporativo ao usuário para mudar qualquer zona. Um clipboard, chamado de suporte ou mensageria pode ainda intervir entre os dois pontos.

Por isso, a trilha precisa preservar separadamente a origem apresentada, o hash exato, a conta autenticada, o vínculo da conta com a zona e a decisão humana ou política. Chamar tudo de “pedido verificado” apaga a parte em que o poder foi realmente concedido.

O pacote inteiro ou nada

A operadora deve verificar antes da execução que todo o array pode ser aplicado atomicamente. Se uma ação impedir o conjunto, nenhuma pode ser processada. A regra evita remover uma configuração antiga e falhar antes de instalar a nova.

Essa atomicidade é operacionalmente importante, mas não julga o objetivo. Uma sequência maliciosa também pode ser coerente. Uma instrução antiga pode completar sem erro. Um conjunto preparado para outro cliente pode fazer exatamente o que descreve.

O texto, portanto, mantém a decisão local. A operadora deve verificar que o usuário está autorizado para a zona de cada FQDN. Pode bloquear tipos desconhecidos por política própria. Pode rejeitar qualquer DUJ, inclusive um que adicione e depois apague o mesmo registro, e deve explicar a rejeição na interface.

O padrão compartilhado é pequeno. O direito de decidir não viaja dentro da cadeia.

Repetição, estado anterior e recibo

Uma nova tentativa pode encontrar o registro de add já presente ou o alvo de delete já ausente. O rascunho permite pular essas ações e também exige verificação exata de presença ou ausência. Recomenda informar ao usuário cada mudança feita.

Um recibo operacional deveria ir além. Ele pode ligar o hash do DUJ à conta, zona, base de autorização, política aplicada, RRsets antes e depois, ações puladas, transação atômica e horário. Essa proposta é julgamento editorial deste Artigo, não um requisito normativo já existente.

O recibo de commit ainda não é recibo de publicação. Autoritativos podem carregar depois; secundários podem atrasar; caches recursivos podem conservar dados antigos; o serviço solicitante pode observar outra visão. Quando o efeito comercial depende de uma consulta externa, a organização precisa registrar a observação autoritativa e o veredito separado do serviço.

O que a revisão 06 realmente é

A revisão foi enviada em 26 de setembro de 2026 e expira em 30 de março de 2027. O Datatracker a descreve como Internet-Draft individual ativo, sem stream RFC e sem posição formal no processo de padronização. A intenção Standards Track no texto não equivale a adoção por grupo de trabalho, consenso, aprovação ou RFC.

O diff congelado entre 05 e 06 altera apenas número e datas. Não há evidência de implementação, interoperabilidade, adoção, incidente, desempenho ou resultado comercial. O assunto é um contrato proposto, não um fato de implantação.

Fontes