Resumo

  • A RFC 8914 transporta Extended DNS Error na opção EDNS 15: INFO-CODE de 16 bits e EXTRA-TEXT UTF-8 opcional. EDE complementa o RCODE básico, não o substitui; o receptor continua processando o RCODE e não é obrigado a agir sobre o diagnóstico.
  • Um EDE é a afirmação de um resolver ou forwarder sobre sua observação, não uma prova causal ponta a ponta. Intermediários podem descartar ou recriar a opção e, quando falta espaço no UDP, a explicação deve ser removida antes do resultado DNS básico.
  • A cadeia probatória deve ligar bytes, hop emissor, RCODE, estado do cache, tentativas upstream, trace DNSSEC, regra local, retry e confirmação independente. Nenhum código isolado deve desligar validação ou escolher um resolver menos seguro.

A precisão que esconde o ponto de vista

SERVFAIL sempre foi frustrante porque comprime causas distintas no mesmo resultado. Um validator pode encontrar uma assinatura vencida, um resolver pode perder contato com a autoridade e um filtro pode bloquear a resposta por policy. EDE oferece palavras para essas diferenças.

O problema começa quando a interface omite quem pronunciou as palavras. “DNSSEC Bogus” parece um veredicto sobre a zona. Na verdade, pode ser o resultado de um trust anchor específico, relógio incorreto, cache antigo, versão particular do software ou conclusão herdada de outro hop. O valor torna a observação pesquisável; não elimina explicações concorrentes.

Por isso, o diagnóstico pode abrir ticket, priorizar captura de pacote e indicar qual equipe deve investigar. Sozinho, não pode autorizar desativação de DNSSEC, aceitação de dados substitutos, migração permanente para outro resolver ou atribuição pública de culpa.

Um option pequeno com contratos separados

A RFC 8914 define EDE como EDNS option code 15. Os dois primeiros octetos contêm INFO-CODE; o restante pode conter EXTRA-TEXT em UTF-8 para leitura humana. Aplicações não devem interpretar o texto como comando. Uma resposta pode levar vários EDE e a opção pode acompanhar qualquer RCODE, inclusive NOERROR.

O desenho preserva o protocolo base. Mesmo ao reconhecer EDE, o cliente deve continuar o processamento normal do RCODE. Reconhecer, mostrar, registrar, alertar e alterar comportamento são decisões independentes. A RFC deliberadamente não dá ao emissor controle remoto sobre o receptor.

O registry da IANA cria vocabulário comum. A RFC 8914 registrou inicialmente códigos 0 a 24 para classes como DNSSEC, stale answer, forged, blocked, censored, filtered, prohibited, network error e autoridade inalcançável. O registro continua evoluindo e reserva faixas públicas e privadas. Registrar um número coordena semântica; não certifica a exatidão de uma ocorrência.

Forwarders mudam a autoria da explicação

Uma implantação pode encadear stub, forwarder empresarial, filtro, recursive resolver e authoritative server. A RFC 8914 permite que um forwarder descarte EDE recebido ou crie outro a partir de sua própria operação. Se repassar a informação de cima, deve identificar a fonte no texto.

Essa flexibilidade acomoda sistemas reais, mas exige provenance explícita. Salvar apenas o último code remove a diferença entre observação direta, herança e reconstrução. A evidência mínima precisa incluir processo emissor, endpoint, nó, versão, transport, upstream usado, rule que disparou e ordem completa das opções.

Proteção do canal resolve apenas parte do problema. DNS autenticado ou cifrado pode vincular o peer naquele hop; não prova que o peer atribuiu corretamente a falha distante. Em UDP ou TCP sem proteção, um ator on-path ainda pode modificar o option. Integridade do transporte e autoridade causal são propriedades diferentes.

A explicação pode ser o primeiro campo descartado

O EDNS da RFC 6891 cria espaço para opções, mas a resposta UDP mantém um orçamento. Se o pacote exceder o limite, a RFC 8914 orienta remover primeiro EXTRA-TEXT, depois o EDE inteiro e, persistindo o excesso, usar TC conforme DNS. Respostas grandes e caminhos restritos podem preservar SERVFAIL e perder a explicação.

Ausência de EDE, portanto, não prova ausência de diagnóstico. Presença não prova que todos os hops receberam a mesma mensagem. Canários precisam cobrir opção ausente, um ou vários códigos, ordem invertida, valores desconhecidos ou privados, texto vazio ou longo, UTF-8 inválido, remoção no UDP, retry em TCP e forwarder que preserva, descarta ou recria.

EXTRA-TEXT pertence ao domínio de dados não confiáveis

Uma frase livre ajuda o operador, mas pode expor número de conta, nome de cliente, blocklist interna, endereço de backend ou justificativa sigilosa. Também pode carregar controles e caracteres bidirecionais perigosos para log e interface. A própria RFC 8914 alerta para privacidade.

O armazenamento de evidência deve manter bytes originais com acesso restrito. A visão analítica apresenta uma decodificação segura. A superfície pública recebe apenas o mínimo saneado. Retenção precisa de prazo explícito, e nenhuma automação deve extrair ordens do EXTRA-TEXT.

Implementações ligam o código a policies diferentes

Unbound oferece EDE, indicação para serve-expired e DNS Error Reporting da RFC 9567. BIND pode anexar códigos como forged, blocked, censored, filtered e prohibited aos resultados de Response Policy Zone. PowerDNS Recursor envia extended resolution errors e pode explicar a aplicação de Negative Trust Anchor.

Isso confirma running code e também a autoridade local. O mesmo code pode nascer de triggers diferentes conforme produto, versão e configuração. A auditoria deve ir do valor on-wire até a rule efetivamente executada, sem supor que o nome no registry descreve toda a lógica.

A RFC 8767 mostra a mesma separação no stale data. EDE pode explicar por que a resposta está vencida; limites de idade, elegibilidade e encerramento continuam sendo policy do resolver. A explicação não concede permissão para servir dados indefinidamente.

RESINFO e Report-Channel tornam o diagnóstico observável

A RFC 9606 permite anunciar em RESINFO, pela propriedade exterr, os códigos EDE suportados. O anúncio ajuda descoberta, mas nodes anycast, versões ou configurações divergentes podem torná-lo inexato. A seleção permanece uma decisão local do cliente.

A RFC 9567 codifica QTYPE, QNAME e EDE em uma nova consulta de relatório para que o operador autoritativo veja falhas encontradas pelo validator. O mecanismo pode acelerar reparo, mas cria custo, recursão e privacidade; profundidade e volume precisam ser limitados. O canal não tem autenticação mútua. TCP ou DNS Cookies elevam confiança na origem, não comprovam o conteúdo.

Uma especificação inicial fina é a virtude aqui: opção, registry e regras básicas são comuns; exposição, retenção, alertas, reports e fallback ficam com o operador. A adoção voluntária só é segura quando testes de pacote mostram o comportamento real de cada versão e hop.

Fontes