Resumo

  • A RFC 8914 permite anexar códigos registrados e texto opcional a várias respostas DNS, mantendo intacto o processamento normal do RCODE.
  • EDE é diagnóstico por salto e pode não estar autenticado; orienta investigação, mas não autoriza bypass, mudança de política ou aceitação de uma resposta falha.

A falha correta ainda pode esconder a causa

SERVFAIL cobre condições diferentes: DNSSEC rejeitado, autoridade inalcançável, servidor não pronto ou bloqueio por política. O destinatário sabe que houve falha, mas não qual controle a produziu.

A RFC 8914 usa a opção EDNS 15 para levar um código de 16 bits e texto UTF-8 opcional. Ela pode acompanhar SERVFAIL, NXDOMAIN, REFUSED, NOERROR e outras respostas quando a consulta contém OPT. O registro diferencia resposta obsoleta, DNSSEC Bogus, assinatura expirada, bloqueio, autoridade inalcançável, erro de rede e dados inválidos.

EDE permanece complementar. Não muda o processamento do RCODE. Um SERVFAIL explicado continua sendo falha. O respondente pode descrever o resultado, não substituí-lo.

Explicar não é autorizar

Código de dado obsoleto não autoriza ampliar cache. DNSSEC Bogus não autoriza desligar validação ou criar uma âncora negativa. Autoridade inalcançável não autoriza tentativas ilimitadas nem troca para resolvedor não aprovado. Cada ação precisa de dono, evidência e limite próprios.

O texto é para consumo humano, não análise automática. Ajuda na leitura inicial, mas não é interface estável: a redação e a localização variam e o campo pode faltar. Automação deve usar fatos estruturados e política local, não extrair autorização de prosa livre.

Mesmo o código registrado relata a visão do emissor. Não prova causa, identidade ou adequação da remediação. Enriquece a evidência sem encerrar o julgamento.

A confiança vem da transação

EDE não possui autenticação própria. Um atacante no caminho ou resolvedor malicioso pode inserir uma explicação em tráfego desprotegido. RCODEs também podem ser manipulados, mas texto detalhado tende a parecer mais definitivo.

Antes de agir, preserve salto emissor, proteção do transporte, RCODE, código e texto separadamente. Não apresente texto não autenticado como conclusão de segurança. Guarde a resposta original para confirmação por outras evidências.

Há custo de privacidade: texto pode vazar identificadores e um código pode revelar bloqueio. Mais observabilidade significa exportar mais contexto; a governança define o que cruza cada salto.

Pela RFC 6891, EDNS é salto a salto. OPT leva controle de uma transação e não é armazenado em cache ou zona. Opções desconhecidas podem ser ignoradas. Autoridade, recursivo, stub e aplicação podem ver partes diferentes do evento.

Benefícios e custos são distribuídos

Operadores separam falhas de validação, política, rede e autoridade; suporte reduz hipóteses. O usuário só ganha quando o contexto chega ao destino e leva a uma resposta segura.

O custo inclui escolher códigos corretos, limitar texto sensível, preservar procedência, controlar cardinalidade, testar spoofing e definir apresentação. O responsável pelo incidente separa causa informada de causa confirmada.

As fontes não provam adoção por operadores nomeados, comportamento de clientes ou redução de tempo de recuperação. Também não provam a veracidade de uma explicação em caminho desprotegido.

O contrafactual mantém o resultado e perde contexto

Sem EDE, DNS continua funcionando e o RCODE permanece. O que some é a explicação adicional. EDE reduz incerteza; não cria disponibilidade nem nova autoridade.

O teste de liderança é manter a cadeia entre resultado e explicação, explicação e evidência corroborada, e evidência e ação autorizada de forma independente. O protocolo oferece apenas o primeiro elo.

Evidência e limites

Os fatos vêm das RFCs 8914 e 6891 e do registro IANA. As conclusões de operação são inferências editoriais. Não há alegações sobre operadores ou produtos.

Fontes