Resumo
- A revisão 27 de Structured Error Data for Filtered DNS está na fila do RFC Editor. Ela propõe I-JSON em
EXTRA-TEXTpara explicar Extended DNS Errors, mas ainda não é um RFC numerado e mantém valores finais pendentes. - DoT, DoH ou DoQ autenticados protegem o salto entre cliente e resolvedor. Eles não comprovam autor da política a montante, base legal ou contratual, acerto da classificação nem a decisão que o aplicativo deve tomar.
Um formato confiável pode carregar uma decisão não comprovada
A abertura é um cenário analítico construído, não um incidente divulgado. A estrutura melhora uma situação real: em vez de um NXDOMAIN sem contexto, o usuário pode receber uma razão controlada e um caminho para contestar um falso positivo. O risco aparece quando a qualidade da apresentação é confundida com autoridade institucional.
O Datatracker mostra draft-ietf-dnsop-structured-dns-error-27, de 30 de julho de 2026 e atualizado em 19 de agosto, no estado RFC Ed Queue. O destino pretendido é Proposed Standard e o RFC Editor aguarda designação de editor. O texto não tem número de RFC e ainda contém marcadores para valores da IANA. Não há base para tratar códigos finais, suporte universal ou adoção operacional como fatos consumados.
O RFC 8914 já define Extended DNS Errors que podem indicar bloqueio, filtragem, censura ou resposta forjada. Seu texto adicional foi pensado para diagnóstico humano. A nova proposta permite que o cliente envie uma opção SDE EDNS de comprimento zero, avisando que entende um objeto I-JSON no campo EXTRA-TEXT.
O objeto separa contato, justificativa, suberro registrado, organização e idioma. Isso favorece localização, registro e atendimento. Não assina a autoridade de quem fala. Um nome de organização continua sendo texto; uma justificativa continua sendo alegação; um inteiro registrado continua sendo a categoria escolhida pelo emissor.
Pedir estrutura não é concordar com o filtro
A opção SDE não contém política. Ela anuncia capacidade do cliente, e a política local pode determinar que nem seja enviada. Sua presença não consente com filtragem, não confia em um fornecedor e não autoriza contato ou desvio automático.
O servidor ainda pode devolver resposta vazia, NXDOMAIN ou um endereço forjado. Quando SDE foi oferecido e surge um EDE de filtragem, o servidor normalmente deve incluir detalhes estruturados. O rascunho diferencia política do operador da rede e política do operador DNS, além de propor um código ainda não atribuído para bloqueio imposto por servidor DNS a montante.
Essa distinção melhora a atribuição técnica, mas não cria mandato. “Política do operador da rede” não revela qual entidade aprovou a regra, se ela alcança aquele dispositivo, se decorre de contrato, ordem pública, decisão familiar ou lista de segurança. A categoria padroniza o relato; não julga sua legitimidade.
O suberro s também tem alcance estreito. Um registro da IANA garante significado interoperável, não verdade do caso. Um valor referente a malware não prova conteúdo malicioso presente, atualização da fonte ou necessidade de bloqueio permanente. São necessários versão, data, evidência observada e critério local.
A autenticação termina no ponto onde termina a conexão
O rascunho proíbe agir sobre texto estruturado recebido sem transporte criptografado, pois um atacante no caminho pode alterá-lo. Mesmo com criptografia, se a identidade do resolvedor não for verificada, contato, justificativa e organização devem ser ignorados. O suberro enumerado pode receber tratamento mais restrito.
Uma sessão DoT, DoH ou DoQ autenticada oferece prova importante: o cliente falou com o resolvedor selecionado e os bytes não foram modificados naquele salto. Ela não prova que um resolvedor a montante produziu o mesmo conteúdo, que um encaminhador o preservou ou que a organização citada é o principal responsável pela regra.
EDE é informação salto a salto. Um encaminhador pode retransmitir, retirar campos ou criar um novo objeto. O projeto deixa essa escolha para implementação e política operacional. Assim, o último canal pode ser impecável enquanto o trecho anterior ficou sem proteção, ou enquanto o resolvedor final redigiu a explicação a partir de um código recebido.
Essa é uma fronteira de proveniência, não uma falha do TLS. Quem precisa reconstruir responsabilidade deve guardar fora do pacote a escolha de resolvedor, o upstream configurado, o modo de encaminhamento, a versão da política, a fonte de classificação, o horário e a trilha de correções.
Encaminhadores antigos ampliam o risco. Um proxy que desconhece EDE pode transportar EXTRA-TEXT controlado por atacante. O texto recomenda processar EDE apenas de servidores DNS explicitamente configurados ou usar informações de resolvedor do RFC 9606. A confiança vem da relação verificada, não das chaves e colchetes do JSON.
O canal de ajuda pode virar canal de engenharia social
O contato foi concebido para corrigir falsos positivos. Um resolvedor malicioso pode apontá-lo para um atacante, inventar uma organização e induzir o usuário a entregar dados ou instalar uma falsa solução. Justificativa livre e linguagem institucional tornam a indução mais convincente.
Por isso a política de segurança do cliente decide o que mostrar. O contato depende de reputação suficiente do resolvedor em configuração administrativa ou lista confiável. A justificativa humana não pode alimentar automação que altere aplicação de política ou comportamento DNS. A organização deve aparecer como texto não clicável e apenas após correspondência confiável ou verificações adequadas.
O rascunho deixa fora de escopo a construção e atualização da lista de confiança. A separação é correta. Um registro global não pode decidir se empresa, escola, família, ISP ou autoridade pública tem poder sobre um usuário específico. A parte que assume prejuízo por erro precisa manter essa relação e seu procedimento de revogação.
O cliente também não deve abrir conexões automaticamente a partir de URIs recebidas. Restringir esquemas reduz comunicação silenciosa, reflexão e armadilhas, mas não garante honestidade humana. Uma interface prudente pode mostrar o resolvedor autenticado, o código controlado e um suporte pré-configurado, sem transformar texto livre em botão.
TTL curto acelera a nova consulta, não a reparação completa
Classificações mudam. O projeto admite TTL de dez segundos para acelerar atualização e sugere valores maiores quando a mudança é menos frequente. Expirar o cache não demonstra que a lista upstream, todos os encaminhadores e todos os clientes convergiram.
Há vários relógios: cache DNS, atualização da fonte, aprovação ou retirada da política, tratamento da reclamação e primeira observação recuperada. Dez segundos não corrigem uma fonte renovada de hora em hora nem um recurso decidido em dias.
Uma prova de correção precisa ligar nome e tipo consultados, identidade do resolvedor, EDE e suberro, upstream visível, TTL positivo e negativo, versão do classificador, recebimento da contestação, responsável e primeiro resultado normal. Uma resposta diferente isolada não prova recuperação da frota.
Privacidade também exige dono. A explicação pode revelar a organização, sua política e o domínio procurado pelo usuário. O cliente não deve registrar ou transmitir o conteúdo a terceiros sem conhecimento do usuário. Exportar cada erro para análise remota pode desfazer, após o resolvedor, a confidencialidade que o DNS criptografado obteve no caminho.
A explicação informa; a consequência permanece local
Depois de autenticar o resolvedor e validar os campos, o aplicativo ainda pode exibir mensagem limitada, registrar localmente, indicar suporte configurado, esperar o TTL, usar alternativa permitida, interromper uma ação ou escalar a revisão. Casa, empresa, rede pública e equipamento crítico têm custos diferentes para falso positivo e desvio.
A camada comum deve ser mínima: sinal de capacidade, formato, registros, ordem de processamento, transporte e limites de segurança. Ela não deve converter declaração do resolvedor em sentença jurídica nem em ação irreversível.
O ganho institucional aparece quando é possível responder: quem escolheu o resolvedor, quem adotou a política, quem forneceu a classificação, quem pode corrigi-la e quem decide o resultado local. SDE pode tornar essa cadeia visível. Sem ela, apenas oferece aparência organizada a uma alegação não verificada.
Sources
- https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/
- https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/history/
- https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/shepherdwriteup/
- https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-structured-dns-error-27
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://queue.rfc-editor.org/
- https://www.iana.org/assignments/dns-parameters
- https://www.rfc-editor.org/rfc/rfc5625.html
- https://www.rfc-editor.org/rfc/rfc7493.html
- https://www.rfc-editor.org/rfc/rfc7754.html
- https://www.rfc-editor.org/rfc/rfc8310.html
- https://www.rfc-editor.org/rfc/rfc8484.html
- https://www.rfc-editor.org/rfc/rfc8914.html
- https://www.rfc-editor.org/rfc/rfc9250.html
- https://www.rfc-editor.org/rfc/rfc9462.html
- https://www.rfc-editor.org/rfc/rfc9606.html
- https://www.rfc-editor.org/rfc/rfc9715.html
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
