Resumo

  • EDE 33 informa que uma âncora de confiança negativa aplicável estava ativa quando o resolvedor produziu a resposta; não informa que a exceção alterou o conteúdo nem que os dados são autênticos.
  • A governança precisa separar seis comprovantes: configuração, cobertura, divulgação, validação, transporte e resultado do aplicativo.

A exceção ganhou uma testemunha

Uma falha de validação DNSSEC cria uma escolha difícil. Manter a proteção pode bloquear usuários de um domínio cuja assinatura está apenas mal configurada. Suspender a validação pode restaurar o acesso, mas o resolvedor abandona deliberadamente uma verificação central. A RFC 7646 definiu a âncora de confiança negativa, ou NTA, para esse compromisso: uma exceção local, temporária e limitada a um nome em um resolvedor recursivo validador.

Até agora, quem recebia a resposta dificilmente via a exceção. O operador podia publicar uma lista na web, mas a mensagem DNS não dizia que nascera sob uma NTA ativa. O novo documento do grupo DNSOP, Disclosure of Negative Trust Anchors in DNS Responses, propõe o Extended DNS Error 33, “Negative Trust Anchor”. A revisão 00 é de 23 de setembro de 2026. Continua sendo trabalho em andamento, não RFC nem consenso final da IETF.

A afirmação é estreita: uma resposta com EDE 33 foi gerada enquanto uma NTA que a cobria estava em vigor. O código pertence ao resolvedor recursivo com a exceção configurada; um servidor apenas autoritativo, que não valida, não deveria emiti-lo. O operador deveria incluir EDE 33 nas respostas afetadas para avisar que talvez não tenham passado pela validação DNSSEC.

Isso melhora a observabilidade. Não resolve as perguntas sobre verdade e responsabilidade.

Divulgar não é autenticar

O texto do rascunho chama EDE 33 de diagnóstico. O cliente não deve mudar o processamento do protocolo apenas por sua presença, e o código não altera o tratamento do bit AD. É o desenho da RFC 8914: EDE acrescenta contexto, não substitui o RCODE nem cria um canal de comando.

O código tampouco prova causalidade. Um resolvedor pode incluí-lo enquanto a NTA estiver ativa, mesmo quando ela não tiver efeito material sobre aquela resposta. Saber se a consulta falharia sem a exceção exige logs do validador ou uma repetição controlada sem NTA.

EDE 33 também não autentica os dados. A NTA existe justamente para suspender a validação normal em certo escopo. A RFC 4035 descreve o trabalho e os estados do validador; o diagnóstico não reconstrói a cadeia de confiança que deixou de ser exigida.

Nem a própria divulgação tem assinatura inerente. Um agente no caminho pode adicionar, retirar ou alterar um EDE. TSIG, SIG(0), DNS over TLS ou DNS over HTTPS podem proteger uma mensagem ou trecho, mas um EDE intacto só prova o relato do resolvedor identificado. Não prova que a falha era inocente, que a investigação foi competente ou que o endereço leva ao serviço pretendido.

Seis comprovantes, não uma luz verde

O comprovante de configuração registra nome exato, operador, incidente, aprovador, início e expiração planejada. A RFC 7646 exige duração limitada; uma exceção ampla ou permanente derrota o mecanismo.

O comprovante de cobertura demonstra que o QNAME e a resposta estavam sob aquela NTA. Uma âncora em um ancestral pode alcançar consultas subordinadas e várias NTAs podem coincidir.

O comprovante de divulgação guarda resposta bruta, identidade do resolvedor, momento e todas as instâncias EDE 33. Havendo várias, cada uma precisa de EXTRA-TEXT. d pode indicar o domínio configurado e t um horizonte esperado; t não é recibo de remoção.

O comprovante de validação reúne bits AD/CD, logs e resultado sem a exceção. O EDE não fornece sozinho esse contrafactual.

O comprovante de transporte mostra se o caminho impedia remoção ou alteração. Integridade da mensagem não transforma julgamento operacional em fato criptográfico.

O comprovante do aplicativo mostra o que stub e aplicação receberam e usaram. Entrega DNS não garante conexão, conteúdo correto nem sucesso do serviço.

Misturar os seis gera um erro: “o resolvedor declarou NTA, então a resposta é segura”. Só se pode afirmar: “este resolvedor relatou que uma NTA cobria esta resposta neste momento”.

Transparência também pode vazar

EXTRA-TEXT pode explicar nome, motivo, referência ou duração esperada. Deve permanecer legível e excluir informação privada ou sensível. Ticket, cliente, hostname interno ou plano ainda sigiloso não se tornam seguros dentro de uma opção DNS.

Os campos d e t aumentam a visibilidade para máquinas sem aumentar a força da prova. d diz onde o operador afirma ter configurado a NTA, não quem possui o domínio. t é expectativa, não remoção garantida ou revisão certificada. Bons metadados revelam deriva; não a impedem.

Sinal mínimo, não licença central

A IETF pode padronizar o menor fato interoperável. O operador do resolvedor conserva decisão e responsabilidade, o operador do domínio repara o DNSSEC autoritativo e o cliente escolhe como mostrar o diagnóstico sem tratá-lo como ordem para confiar.

Essa divisão acompanha a proposta de Heng Lu de especificação inicial mínima, decisões futuras locais e adoção voluntária. O código comum não deve virar tribunal mundial das exceções. A diferença entre autoridade e crença lembra que uma etiqueta identifica falante e afirmação, mas não cria verdade. A primazia do código em execução exige pacotes, versões, caminhos, comportamento de clientes e prova de remoção antes de alegar implantação.

Estado e limites

Os exemplos da revisão 00 demonstram o mecanismo, não medem adoção. Forwarders podem retirar ou recriar EDE, pressão de tamanho UDP pode eliminar opções e muitos aplicativos podem escondê-las. O texto ainda pode mudar.

Mesmo assim, a proposta melhora a superfície de evidência. Uma redução antes oculta da validação ganha testemunha padronizada. A disciplina é não promover essa testemunha a veredito.

Fontes