Resumo

  • O DNSOP abriu em 24 de agosto de 2026 o Last Call de Grupo de Trabalho para draft-ietf-dnsop-integration-04, com término programado para 7 de setembro. O Datatracker capturado ainda mostra In WG Last Call; não se trata de RFC aprovado.
  • O texto pede que aplicações considerem expiração, mudança no estado do DNSSEC, remoção do registro esperado e meios de ressincronização, além da prova inicial de controle.
  • Uma verificação completa pode ser organizada em quatro transições: cadastrar, atualizar, excluir e transferir ou registrar novamente. Cada uma precisa indicar gatilho, verificador, estado final e limite de desatualização.
  • Os handles do AT Protocol combinam validação bidirecional com nova resolução periódica. No exemplo de ENS, a ausência de provas negativas NSEC nesse caminho faz com que apagar o registro não remova, por si só, uma alegação positiva anterior na blockchain.
  • A matriz de quatro transições é uma proposta analítica de Daniel Kade, não um requisito aprovado pelo IETF. Ela mede resultados sem impor uma solução única.

O calendário não aprovou o documento

A mensagem dos coordenadores do DNSOP abriu o Last Call em 24 de agosto e fixou 7 de setembro como data final. O lembrete enviado em 6 de setembro ainda pedia manifestações. O evento verificável é a chegada do prazo, não uma aprovação automática.

No Datatracker do IETF, a revisão 04 aparece como Internet-Draft de finalidade Informational. O estado do grupo continua In WG Last Call, enquanto o IESG registra apenas I-D Exists. Esses campos não demonstram consenso, publicação ou resultado futuro.

Preservar essa diferença é especialmente importante em uma pauta sobre sincronização. Uma informação pode ter sido correta em um instante e já não representar o estado atual.

A aplicação importa também a volatilidade do nome

A revisão 04 cita três mudanças concretas: expiração do domínio, alteração do estado do DNSSEC e remoção de um registro necessário à integração. Se o software não reagir, uma pessoa que controlava o domínio no passado pode conservar posição dentro da aplicação.

O texto também pede uma validação que limite o cadastro ao registrante ou a uma parte autorizada; rejeita listas arbitrárias de TLDs quando nomes tecnicamente válidos poderiam funcionar; e exige documentação para recolocar a aplicação em sincronia com o DNS global.

Não basta escolher “verificar sempre”. Consultas têm custo, caches existem, falhas transitórias podem produzir decisões erradas e uma frequência excessiva pode encontrar limites. Cada aplicação escolhe um orçamento de atualização. O dever de governança é declarar o efeito dessa escolha.

Este artigo propõe uma ficha de quatro linhas:

Transição Pergunta de evidência Resultado observável
Cadastro O que comprova o controle atual ou a delegação válida? O vínculo nasce ou é recusado.
Atualização Qual afirmação nova substitui a anterior? Destino ou identificador muda.
Exclusão Como a ausência vira sinal, e em quanto tempo? O vínculo fica inválido, vazio ou marcado como antigo.
Transferência ou novo registro Como o novo titular elimina a autoridade anterior? O estado antigo termina e a nova prova começa sem herança.

Para cada linha, devem constar gatilho, agente verificador, política de cache, janela máxima e recuperação manual. Essa tabela não está no rascunho. É uma forma de testar, na prática, suas seções sobre ciclo de vida, controle, completude e sincronização.

No AT Protocol, falhar a resolução gera um estado

O AT Protocol separa um DID persistente de um handle legível e mutável. A especificação de handle requer confirmação nos dois sentidos: o handle aponta para o DID, e o documento do DID precisa apontar de volta para o mesmo handle. Uma referência criada unilateralmente não basta para se apropriar do nome de uma conta alheia.

Quando um handle conhecido deixa de resolver, ele deve ser marcado como inválido. Serviços podem guardar o resultado em cache, mas são orientados a resolver novamente de tempos em tempos. Como uma mudança no DNS não precisa gerar evento dentro da aplicação, é a consulta futura que transforma desaparecimento em estado inválido.

O intervalo envolve escolha. Cache longo economiza tráfego e prolonga o erro; nova resolução frequente reduz a defasagem e aumenta carga e sensibilidade a indisponibilidades. A arquitetura é auditável porque reconhece um resultado negativo e explica como chegar a ele.

O mesmo documento afirma que DNSSEC não é obrigatório para esse método. Portanto, o rascunho do DNSOP não deve ser interpretado como ordem universal de adoção do DNSSEC. A necessidade comum é acompanhar a autoridade com um mecanismo definido.

O exemplo de ENS precisa de um novo positivo

No caminho descrito para ENS, uma prova positiva de DNSSEC pode ser levada à blockchain. Uma prova positiva mais recente toma o lugar da anterior; depois de uma troca de controle, o novo registrante pode enviar seu próprio registro e restabelecer a integração.

O caso de exclusão é diferente. Segundo o rascunho, o ENS não aceita atualmente provas negativas NSEC nesse fluxo. A inexistência ou retirada do registro não pode ser demonstrada on-chain. A alegação positiva antiga permanece até ser substituída por outra positiva, em vez de ser revogada apenas porque o TXT sumiu ou o nome deixou de valer.

Essa passagem já estava na revisão 03. A comparação com a revisão 04 impede atribuir o problema à última edição. O histórico da revisão 04 menciona atualização do texto de completude.

A orientação do próprio ENS diz que um novo dono pode alterar _ens e usar a função de atualização para refletir o registro. Isso envia um estado positivo mais novo; não prova que a simples remoção apaga automaticamente o anterior.

O limite é específico desse mecanismo. Não descreve todo o ENS, nem todos os consumidores de DNSSEC. Sua utilidade é mostrar a pergunta que qualquer integração deve responder: se o sistema aceita uma afirmação, por qual canal aceita a notícia de que ela acabou?

O custo da saída fica escondido

O cadastro traz usuário e gera uma demonstração bem-sucedida. A exclusão exige consultas, verificação, alteração de estado, suporte e, em certos desenhos, uma transação. Essa assimetria cria incentivo para investir na entrada e deixar a saída indefinida, mesmo sem conduta imprópria.

O dano varia conforme o uso. Um nome antigo confunde; um destino antigo desvia; um vínculo empregado para pagamento, acesso ou administração pode conservar poder. A auditoria precisa observar a consequência na aplicação, não apenas confirmar que o DNS responde.

Expiração também não é um instante universal. O ciclo de vida de gTLDs da ICANN passa por etapas. Em vez de inventar um relógio único, cada sistema deve indicar qual evento altera seu estado e qual é o prazo.

A ideia de Heng Lu de especificação inicial mínima, decisões futuras locais e adoção voluntária cabe aqui: quatro transições comuns, com resolução, prova, cache e recuperação escolhidos localmente.

Se o código em execução é a evidência principal, o selo “verificado por DNS” vale menos que um teste que adiciona, troca, apaga e registra novamente o nome. É esse exercício que mostra onde a autoridade continua.

Fontes

  1. Abertura do Last Call do DNSOP
  2. Lembrete do Last Call do DNSOP
  3. Registro no Datatracker do IETF
  4. Histórico do documento no IETF
  5. Rascunho de integração DNS, revisão 04
  6. Rascunho de integração DNS, revisão 03
  7. Comparação oficial das revisões 03 e 04
  8. Modificações do protocolo DNSSEC, RFC 4035
  9. Especificação de handles do AT Protocol
  10. Sincronização de repositórios do AT Protocol
  11. Orientação do ENS para importar DNS on-chain
  12. Ciclo de vida de gTLDs da ICANN
  13. Heng Lu — Especificação inicial mínima e decisões futuras locais
  14. Heng Lu — Código em execução como evidência principal