Resumo

  • Os RCODEs históricos preservam um resultado interoperável, mas comprimem causas distintas. RFC 8914 usou a opção EDNS 15 para levar um INFO-CODE registrado e um EXTRA-TEXT opcional voltado a leitores humanos.
  • Uma EDE pode acompanhar SERVFAIL, NXDOMAIN, REFUSED ou NOERROR, e várias opções podem coexistir. O aplicativo continua obrigado a processar o RCODE original; o diagnóstico não é um segundo resultado.
  • A explicação também pode perder procedência: encaminhadores a omitem ou recriam, o limite UDP a remove antes dos dados principais, texto livre vaza política e uma transação sem proteção admite falsificação.

Dois chamados chegam à mesma equipe. No primeiro, nenhum servidor autoritativo responde. No segundo, os servidores respondem, mas o validador não consegue formar a cadeia de confiança exigida. Ambos exibem SERVFAIL.

O primeiro incidente pede testes de rota, disponibilidade e repetição. O segundo pede inspeção de DS, DNSKEY, RRSIG, relógio e integridade. Usar um resolvedor que não valida pode produzir um endereço no segundo caso, mas não prova conserto: apenas remove a condição que revelou o defeito.

O problema histórico era, portanto, de separação. O resultado precisava continuar pequeno e estável. A causa precisava viajar sem ganhar poder sobre ele.

RCODE era conclusão compartilhada, não relatório interno

RFC 1035 definiu respostas amplas: sucesso, formato inválido, falha do servidor, nome inexistente, operação não suportada e recusa. O cliente consegue agir sem conhecer a arquitetura de cada servidor.

Mas SERVFAIL não revela se a zona ainda carrega, se a autoridade está inalcançável, se uma falha veio do cache, se houve problema DNSSEC ou se os dados locais são inválidos. REFUSED não separa falta de autoridade, cliente não autorizado e política de bloqueio.

Esse silêncio causal protege a interoperabilidade. Tentar elevar todo defeito interno a novo RCODE faria a base do protocolo acompanhar uma lista infinita. A saída foi criar uma camada subordinada e extensível.

EDNS ofereceu espaço fora dos dados da zona

RFC 6891 criou o pseudo-RR OPT e o espaço de opções EDNS. OPT está na mensagem, mas não é um registro comum publicado pela zona. Assim, capacidade e contexto podem viajar sem parecer afirmações sobre um nome.

Em 2020, RFC 8914 atribuiu a opção 15 ao Extended DNS Error. A carga começa por um INFO-CODE de 16 bits. O restante pode guardar EXTRA-TEXT em UTF-8.

O número consulta um registro IANA e serve à classificação. O texto serve a pessoas, não à análise automática. Pode estar vazio, não precisa terminar em zero e tem seu tamanho definido pelo comprimento da opção.

EDE pode acompanhar qualquer RCODE se a consulta incluiu OPT. O remetente pode incluir mais de uma; o receptor deve aceitá-las, mas não precisa agir sobre todas. Uma sequência de causas não vira um comando único.

A regra mais importante conserva a hierarquia: EDE não altera o processamento do RCODE. SERVFAIL com DNSSEC Bogus segue sendo falha. NOERROR com Stale Answer entrega uma resposta com idade declarada. Contexto melhora a investigação, não reescreve o desfecho.

Bogus descrevia estado de validação, não intenção

RFC 4035 chama de Bogus um RRset cuja cadeia deveria poder ser formada, mas não valida ou carece de dados esperados. Pode haver ataque, erro de configuração ou corrupção.

Indeterminate significa outra coisa: faltam dados para decidir se a assinatura deveria existir. Um caso quebra uma prova esperada; o outro não determina qual prova seria exigível.

RFC 8914 separa esses estados e ainda identifica algoritmo DNSKEY não suportado, digest DS desconhecido, assinatura vencida ou prematura, DNSKEY ou RRSIG ausente, bit de chave de zona desligado e NSEC faltante.

Essa precisão não escolhe culpado. Zona filha, pai, registrador, relógio, implementação e caminho podem participar. O código é evidência sobre a conclusão do resolvedor, não sentença contra uma instituição.

Uma resposta válida podia admitir que estava velha

Quando atualizar o cache falha, o resolvedor pode preferir uma cópia recém-expirada à indisponibilidade. RFC 8767 limita esse uso. EDE 3 marca resposta positiva antiga; EDE 19 marca NXDOMAIN antigo.

NOERROR e Stale Answer podem conviver porque respondem perguntas diferentes. O RCODE classifica a entrega. EDE registra sua condição temporal. Servir a cópia não renova o TTL nem demonstra confirmação recente da autoridade.

EDE 4, Forged Answer, descreve uma resposta alterada por política que ainda é enviada. Quando a política impede a resposta, Blocked, Censored e Filtered distinguem política interna do operador, exigência externa e filtragem pedida pelo cliente. Prohibited pode acompanhar recusa a cliente sem permissão.

Os rótulos mostram o controle alegado, mas não autenticam decisão judicial, lista de segurança ou escolha do cliente. A procedência continua essencial.

O cache podia repetir um fracasso sem refazê-lo

Resolver tudo de novo para cada solicitante amplia trabalho durante panes. RFC 9520 explicita o cache temporário de falhas de resolução.

EDE 13, Cached Error, informa que o SERVFAIL atual veio dessa memória. Não o transforma em dado autoritativo e não prova que a causa persiste neste instante. Apenas distingue leitura local de nova tentativa.

Sem esse sinal, mil clientes parecem produzir mil observações independentes, quando podem ter recebido a mesma entrada. Evidência nova exige esperar expiração, usar outro resolvedor controlado ou testar diretamente a autoridade.

Encaminhar a causa mudava quem parecia falar

O stub conversa com o resolvedor local, que pode encaminhar a outro serviço. A EDE vista no fim parece afirmação do último salto, mesmo quando nasceu acima.

RFC 8914 deixa o encaminhamento à implementação. O resolvedor pode omitir a informação, preservá-la ou criar outra opção. Ao repassar uma causa, deveria atribuir sua fonte no EXTRA-TEXT; caso contrário, apropria-se involuntariamente do diagnóstico.

Várias EDE permitem registrar validação quebrada acima, falha armazenada localmente e política aplicada na saída. Porém números sem autores não formam cadeia de custódia. Texto restaura contexto, mas segue humano e normalmente não autenticado.

Quando faltava espaço, a explicação saía primeiro

Texto longo pode exceder a carga UDP anunciada. RFC 8914 orienta remover EDE antes de outros dados e marcar truncamento quando isso ocorrer.

Essa prioridade diz que o diagnóstico é suplementar. Sua ausência não prova que ninguém conhecia a causa; tamanho, política de encaminhamento ou suporte incompleto podem apagá-lo. Logs precisam separar geração, repasse, substituição, descarte e truncamento.

Mais prosa não significa mais transparência. Uma explicação extensa pode forçar TCP ou ser eliminada antes de chegar ao operador.

Especificidade não substituía autenticação

“Assinatura vencida” parece mais confiável que SERVFAIL, mas detalhes não criam prova criptográfica.

RFC 8914 alerta que EDE permanece não autenticada sem transação DNS autenticada ou transporte seguro. Quem injeta diagnóstico talvez também altere RCODE ou registros de endereço. A informação deve continuar diagnóstica e nunca mudar o processamento do protocolo.

O texto livre ainda pode revelar conta, upstream, bloqueio ou política interna. A explicação responsável fornece apenas o necessário para selecionar o próximo teste e a superfície responsável.

O registro IANA de parâmetros DNS lista a opção 15 e INFO-CODEs posteriores. Prova coordenação de números e referências, não implantação, emissão correta, encaminhamento fiel, proteção ou uso em interfaces.

EDE tornou a causa transportável sem lhe dar a autoridade do resultado. RCODE permaneceu comando comum; EDE tornou-se pista. A distinção reduz tempo de reparo sem transformar disponibilidade aparente em desculpa para enfraquecer validação.