Resumo

  • O rascunho DNS Filtering Transparency permite que a resposta carregue o identificador de um operador de base de filtragem e o identificador de um incidente. O par aponta para um registro, mas não autentica a associação entre esse registro e a experiência do usuário, nem obriga o resolvedor a fornecer determinada referência.
  • O aplicativo toma outra decisão: mantém uma cópia local do registro proposto, seleciona os operadores que admite ou considera confiáveis e resolve se exibirá a referência. O registro fornece uma forma estável de montar a URI; não certifica o incidente nem a política que o produziu.
  • Buscar a página pode revelar o IP do usuário e seu interesse por um nome sensível. A ação explícita é, portanto, uma terceira decisão, e o recibo de governança deve manter separados envio, apresentação e acesso.

A promessa é atraente: em vez de um erro DNS opaco, a tela poderia informar que houve filtragem e oferecer uma página com o contexto do incidente. O usuário deixaria de tratar toda falha como defeito técnico e poderia encontrar um caminho para corrigir uma classificação errada.

Só que o texto na tela não é a reprodução automática de uma única decisão. O resolvedor seleciona referências. O navegador, o sistema operacional ou outro cliente escolhe quais referências reconhece e aceita mostrar. O usuário decide se inicia uma conexão adicional para ler a página. O aviso é o resultado dessas três escolhas encadeadas.

Guardar apenas a tela final destrói essa proveniência. Uma ausência pode ter surgido no resolvedor, na cópia local do registro, na política de confiança do cliente ou na arquitetura do sistema hospedeiro. Um link presente pode ser verdadeiro, equivocado ou simplesmente insuficiente. A governança começa ao impedir que a aparência simples esconda esses caminhos.

O mecanismo entrega coordenadas, não uma conclusão

Publicado em 1º de agosto de 2026, draft-ietf-dnsop-filtering-transparency-00 acrescenta uma lista fdbs aos dados estruturados do erro. Cada item combina db, identificador do operador de uma base de incidentes de filtragem, e id, identificador de uma entrada. Quando há vários itens, todos devem se relacionar ao mesmo incidente subjacente.

O resolvedor não injeta uma URL arbitrária no navegador. O aplicativo consulta sua cópia local do registro que o texto propõe à IANA, encontra um modelo de URI de nível 1 ou 2 e substitui a variável permitida pelo identificador. A camada reduz o risco de uma rede desconhecida usar a aparência confiável do aplicativo para promover qualquer texto ou destino.

Essa restrição protege a forma, não demonstra o vínculo. A própria seção de segurança afirma que o mecanismo não autentica a associação entre o incidente experimentado pelo aplicativo e a informação apresentada. Quem controla o resolvedor pode reaproveitar um par existente, que leva a uma página real, e relacioná-lo indevidamente a outra consulta.

Uma página recuperável só prova que há conteúdo naquele endereço. Não prova que o resolvedor escolheu o incidente correto, que a base é completa, que uma ordem existe e se aplica, que a regra foi executada no território descrito ou que o filtro atingiu apenas o alvo pretendido. O par db/id abre uma trilha de investigação; não encerra a investigação.

Também é preciso nomear corretamente a autoridade do documento. A versão 00 é um Internet-Draft ativo adotado pelo grupo DNSOP e substitui uma proposta individual. Ainda não é RFC e não apresenta, no Datatracker atual, um status RFC pretendido. A análise pode levar o trabalho a sério sem transformar uma proposta mutável em norma pronta.

O resolvedor decide a primeira versão do relato

O texto não exige que o resolvedor envie uma informação específica. Ele escolhe quais provedores de bases suporta e pode usar seus próprios critérios para definir se e quando fornece uma referência. A lista que sai do resolvedor é uma seleção deliberada, não um inventário completo por natureza.

Talvez existam duas bases e só uma seja suportada. Talvez uma regra interna ainda não tenha correspondência pública. Talvez a política de divulgação varie entre controle parental, segurança empresarial e ordem externa. Talvez o operador não possa publicar determinado detalhe. Nenhuma hipótese, isoladamente, demonstra abuso. Todas mostram por que o conjunto emitido precisa ser tratado como parcial.

Não receber fdbs significa apenas que aquela resposta, tal como observada, não trouxe uma referência utilizável. Não demonstra ausência de filtragem, ordem, registro ou correção. Há ainda uma perda adicional: algumas arquiteturas não entregam ao aplicativo os detalhes da resposta DNS, mesmo quando o resolvedor os enviou.

O recibo do resolvedor deve preservar o horário, o contexto autenticado do serviço DNS quando disponível, o código EDE, os pares transmitidos, a regra de seleção e eventuais alternativas conhecidas mas não incluídas. Nomes sensíveis e dados pessoais precisam de minimização e acesso restrito. A existência da decisão, porém, não pode ser descartada junto com os dados excessivos.

O aplicativo escolhe qual voz distribuir

Depois do resolvedor, o poder passa ao consumidor da resposta. O rascunho espera que aplicativos implementem conjuntos diferentes de operadores e exerçam julgamento sobre quais mensagens mostrar. A identidade do resolvedor, a identidade do operador da base e a configuração local podem influenciar essa avaliação.

Dois dispositivos que recebem os mesmos bytes podem, portanto, contar histórias distintas. Um reconhece db e exibe a referência; o outro ainda não tem a entrada. Um aceita o operador apenas quando a mensagem vem de um resolvedor configurado; outro também exige uma lista local de confiança. Um sistema expõe os campos ao navegador, enquanto outro os retém.

A tela final não revela onde aconteceu a diferença. Se não há link, não se sabe se o resolvedor omitiu, o registro local estava velho, o cliente rejeitou ou o host escondeu os dados. Se há link, sabe-se que o aplicativo o distribuiu, mas não que verificou a ordem, a política ou o relato que está por trás dele.

O tempo torna o registro mais delicado. O contato de uma entrada pode alterar o modelo de URI, e o próprio rascunho alerta para atrasos potencialmente longos na atualização das cópias mantidas pelos aplicativos. Reconstruir o destino disponível no dia do incidente exige a fotografia daquele registro local. Consultar o valor atual não consegue provar a rota antiga.

A política cadastral também tem limite claro. A proposta usa o primeiro a chegar, primeiro a ser atendido, embora permita à IANA recusar pedidos enganosos ou espúrios. O RFC 8126 explica que esse regime normalmente não faz análise substantiva: verifica forma, unicidade e informações administrativas mínimas. Estar cadastrado resolve uma referência; não aprova o conteúdo referenciado.

Por isso, o recibo do aplicativo deve fixar data ou hash da cópia do registro, modelo efetivamente expandido, versão dos operadores suportados e da política de confiança, entradas aceitas ou suprimidas, classe do motivo e forma da mensagem mostrada. Sem isso, um erro de cache pode parecer silêncio do resolvedor e uma recusa local pode parecer inexistência do incidente.

Ler a explicação cria uma exposição nova

Os detalhes não viajam dentro da mensagem DNS. Para lê-los, o cliente se conecta ao operador da base. Essa conexão pode revelar o endereço IP e que alguém nele tentou resolver determinado nome filtrado. Dependendo do tema e do local, a busca da justificativa pode ser tão sensível quanto a busca original.

O rascunho, por isso, impede a recuperação automática sem ação explícita quando não há um mecanismo de preservação de privacidade, como um proxy. Também alerta que resolvedor e operador de base podem colaborar — ou serem a mesma entidade — e empregar identificadores únicos para correlacionar atividades.

O aplicativo pode informar que existe contexto adicional sem pré-carregar a página. Pode identificar o destino, diferenciar rota direta de rota protegida e só iniciar a rede depois da escolha. O registro de conformidade não precisa guardar uma lista de pessoas, nomes e horários; basta demonstrar que não houve busca automática, que a ação veio primeiro, qual classe de rota foi usada e se a recuperação terminou.

Esse cuidado evita um paradoxo. Um mecanismo criado para explicar uma intervenção não deve formar uma base ainda mais detalhada sobre quem quis entendê-la. A auditoria precisa guardar causalidade, não reproduzir a exposição que pretendia limitar.

Estrutura e confiança continuam separadas

A proposta depende de Structured Error Data for Filtered DNS. Esse trabalho permite processar campos antes tratados como texto humano, mas ordena que os dados não sejam automaticamente confiados, exibidos ou usados em decisões de segurança sem validação adequada. Também exige transporte DNS criptografado para o intercâmbio estruturado.

Cada propriedade responde a uma pergunta diferente. A estrutura facilita o processamento, mas não garante verdade. A criptografia protege o trajeto contra observação passiva, mas não certifica o que a extremidade declarou. Um nome JSON ou um identificador registrado estabiliza sintaxe e resolução, não transfere autoridade institucional.

O RFC 7754 amplia a cadeia ao distinguir quem define a política de bloqueio de quem a executa. Leis, regras administrativas, políticas do operador, arquitetura e implementação podem transformar a intenção em cada passagem. Informar rapidamente ajuda a reparar erros e danos colaterais, mas o protocolo não decide se uma medida concreta é legal, ética ou adequada.

O recibo da cadeia de divulgação

Daniel Kade propõe um recibo com três módulos ligados. O primeiro guarda a observação do resolvedor, sua autenticação ou a falta dela, o EDE, os pares enviados, a regra de seleção e as omissões conhecidas. O segundo fixa a fotografia do registro, o modelo usado, as versões das listas de suporte e confiança, a decisão de apresentação e a categoria da mensagem. O terceiro registra se a consulta foi oferecida, se houve ação explícita anterior, se o caminho foi protegido e qual foi o resultado.

O recibo não preenche lacunas. Identidade não autenticada continua assim. Motivo desconhecido não ganha explicação inventada. Cópia antiga não é substituída pelo registro de hoje. Página alterada depois não é tratada como conteúdo histórico. Uma ordem ou norma encontrada por outra via entra como fonte independente, com procedência própria, e nunca como dedução automática do identificador.

Esse documento não legitima a filtragem. Ele torna auditável a formação do aviso. Permite localizar onde a explicação desapareceu, mudou ou passou a exigir uma exposição adicional. E impede que uma mensagem limpa pareça um consenso entre três participantes que, na verdade, tomaram decisões separadas.

Fontes