Resumo

  • O DNSOP abriu em 2 de setembro a chamada de adoção de draft-farrokhi-dnsop-ede-nta-01, com encerramento em 16 de setembro. A revisão 01 continua sendo um Internet-Draft individual, não um RFC ou resultado concluído.
  • O EDE 33 afirma que havia uma NTA cobrindo o nome quando a resposta foi produzida. O rascunho permite o código mesmo quando a exceção não teve efeito material sobre o conteúdo.
  • Uma ficha separada e limitada pode ligar a origem do EDE e a proteção do trecho observado a uma validação contemporânea sem NTA, ou preservar honestamente o estado não medido.

O registro não encerrou a chamada

A mensagem dos copresidentes pede que os participantes digam se o DNSOP deve assumir o documento sobre divulgação de NTAs em respostas DNS. A consulta vai de 2 a 16 de setembro. O Datatracker ainda mostra Call For Adoption By WG Issued; a intenção editorial é Informational e o texto permanece individual.

Enquanto isso, o registro DNS da IANA já associa o código 33 a Negative Trust Anchor. O valor comum reduz colisões entre implementações. Não equivale a adoção pelo grupo, publicação como RFC nem comprovação de uso por um resolvedor.

São decisões distintas. IANA coordena o identificador. Os copresidentes registram a conclusão de consenso. Um processo posterior pode publicar o documento. Fornecedores e operadores decidem implementação e ativação. O pacote leva só o número, não toda essa história institucional.

A exceção pertence ao resolvedor

O RFC 7646 descreve uma NTA como comportamento local de um resolvedor recursivo validador. A partir do nome configurado, ele interrompe a cadeia comum de DNSSEC e trata as respostas cobertas como dados não assinados. Isso não corrige a zona, não muda a delegação e não concede autoridade ao resolvedor.

A restauração de acesso acontece pela suspensão de uma proteção, por isso há condições. A NTA não pode ser aplicada automaticamente. Pessoal treinado deve diferenciar provável erro de configuração e possível ataque, excluir domínios quebrados de propósito e tentar contato razoável com o operador da zona. O escopo deve ser estreito. A validação precisa ser testada de novo; a configuração deve expirar sozinha, de preferência em até uma semana, e ser removida rapidamente quando a validação voltar, com limpeza do cache correspondente.

Esse ciclo de autorização, duração e retirada já é objeto de cobertura anterior. Aqui a pergunta começa depois: o que um cliente consegue provar ao receber uma resposta com o novo código?

Contexto ativo não é causa demonstrada

A revisão 01 diz que uma ou mais ocorrências de EDE 33 indicam uma NTA aplicável no momento em que a resposta foi gerada. O EDE é diagnóstico, não muda o tratamento do bit AD e não deve ser usado por um servidor apenas autoritativo para sugerir uma validação que ele não executa.

O operador que aplicou a NTA deveria devolver o código nas respostas afetadas. O rascunho também permite incluí-lo em qualquer resposta enquanto a NTA estiver ativa, independentemente de ela ter influenciado materialmente o conteúdo.

Assim, duas consultas cobertas podem receber a mesma marca. Sem NTA, a primeira falharia e só obtém dados por causa da exceção. A segunda validaria do mesmo modo. No primeiro caso existe mudança de resultado; no segundo existe apenas coexistência. O EDE não carrega a execução alternativa.

Há uma boa razão operacional. Exigir duas validações por consulta para produzir uma mensagem de transparência aumentaria custo e complexidade. O desenho fornece uma declaração de presença e não se apresenta como teste causal. O erro aconteceria no sistema que consumisse o código como se fosse esse teste.

d localiza; t estima

O EXTRA-TEXT pode trazer o nome configurado, uma razão, uma referência ou a duração esperada. O formato estruturado usa d para o domínio onde a NTA foi instalada e t para um horário indicativo até o qual ela talvez continue.

Os dois são opcionais. O domínio de cobertura não mostra se essa resposta foi alterada. A hora prevista não é o evento de remoção. A justificativa escrita não prova quem aprovou ou com qual mandato. Várias NTAs podem gerar várias instâncias e, nesse caso, cada uma recebe texto; ainda assim, a lista de exceções não escolhe a causa.

O RFC 8914 define EDE como informação suplementar que não pode mudar o processamento DNS. Ela não possui autenticação inerente sem proteção adequada de transação ou transporte. Um encaminhador pode apagar, repassar ou criar um novo EDE. A origem deve ser atribuída porque o último salto pode parecer o autor para o cliente.

Logo, a leitura defensável é: “o sistema que respondeu declara que uma NTA cobria a resposta naquele instante”. Não é prova de zona defeituosa, decisão correta, alteração causada ou permanência atual. A falta de 33 tampouco certifica ausência de NTA, pois a emissão é recomendada, não obrigatória, e pode ser filtrada no caminho.

O exemplo foi consertado pela própria automação

O debate de adoção registrou uma situação que torna a distinção concreta. A revisão 01 usa uma delegação filha deliberadamente inválida para ilustrar o EDE. Numa resposta de 2 de setembro, o coautor Joe Abley avisou que a automação padrão da Cloudflare continuava reparando a delegação ou removendo o corte de zona. O estado vivo já não representava bem o caso naquele momento; os autores disseram que iriam corrigi-lo.

Isso não relata indisponibilidade nem falha de controle em produção. Mostra apenas que o texto e o ambiente de teste têm relógios próprios. A revisão fica estável enquanto o DNS muda. Se a reparação elimina a quebra, a presença da NTA não reconstrói por si só o resultado que existia antes.

Uma conversa anterior de implementação apresentou uma resposta real com EDE 33 e explicou o que faltava: não era possível saber se a NTA estava no nome ou num ancestral, se havia mais de uma, nem se a resposta validaria sem a exceção. A mensagem é útil porque limita sua própria alegação.

Uma ficha de efeito fora do protocolo

Não é prudente colocar endereço do cliente, histórico de consultas, chamado interno ou detalhes sensíveis no EXTRA-TEXT. O que falta pode ficar numa ficha de efeito da NTA controlada pelo operador. Trata-se de uma recomendação editorial, não de requisito do IETF ou da IANA.

Para uma amostra ou incidente, a ficha ligaria horário e impressão digital da resposta; papel do resolvedor ou encaminhador; origem do EDE; proteção do trecho; código e valores d/t; estado AD; validação contemporânea sem NTA em ambiente isolado, ou justificativa não medido; diferença de dados ou resultado; e referência ao registro independente de aprovação e expiração.

Não se pede duplicação de toda consulta de usuário. Amostragem e reprodução segura bastam, e a ausência de contrafactual deve continuar visível. Um relatório público pode agregar classes de efeito sem revelar nomes e usuários. A meta é impedir que presença seja contabilizada como resgate automático.

O Policy Mirror de Heng Lu ajuda a separar o ator que decide, a regra e a evidência. IANA mantém o índice; o processo IETF define a situação do texto; o operador ativa a NTA; um caminho particular entrega o aviso. Running Code Primary exige que a comparação final venha do resolvedor observado, não da expectativa documental.

O EDE 33 ilumina uma exceção antes invisível. Essa transparência permanece confiável quando o código diz “estava presente” e o leitor não completa a frase com uma causa que não foi medida.

Fontes

  1. Chamada de adoção do DNSOP
  2. Registro atual no Datatracker
  3. Divulgação de NTAs em respostas DNS, revisão 01
  4. Histórico do documento
  5. Aviso de Joe Abley sobre o estado do exemplo
  6. Discussão sobre o limite da implementação
  7. RFC 7646 — Negative Trust Anchors de DNSSEC
  8. RFC 8914 — Extended DNS Errors
  9. Parâmetros DNS da IANA
  10. Registro do grupo DNSOP
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Running Code Primary