Resumo

  • O rascunho reduz a mensagem do resolvedor a db e id; a aplicação usa uma cópia local do registro para expandir o endereço e decide por conta própria quais operadores aceita.
  • A política first come, first served evita colisões de nomes, mas não avalia evidência, correção, jurisdição ou retenção. Registro é coordenação, não selo de confiança.

Uma base foi a primeira a pedir um identificador. Seu nome passou a constar no registro e aplicações começaram a reconhecer o modelo de URL. Logo, material comercial passou a chamá-la de “base oficial”.

Nenhuma auditoria havia ocorrido. A ordem de chegada tinha sido convertida em reputação.

Essa confusão é precisamente o que uma leitura disciplinada de draft-ietf-dnsop-filtering-transparency-00 deve evitar. A proposta tenta oferecer contexto quando uma intervenção de política no DNS parece falha técnica. Ela não cria um tribunal de incidentes.

A revisão 00, de 1º de agosto de 2026, expira em 2 de fevereiro de 2027. É um Internet-Draft ativo do DNSOP destinado ao Standards Track, não uma RFC, registro IANA já criado, política de navegador ou prova de implantação. O campo fdbs depende do rascunho de erro DNS estruturado, também em evolução.

O registro resolve nomes, não disputas

Uma entrada de banco contém db, identificador do operador, e id, identificador de um incidente. Uma lista fdbs pode trazer várias entradas sobre o mesmo evento alegado.

A aplicação guarda uma cópia local do DNS Filtering Database Registry. A linha do operador fornece nome, contato e um URI Template de nível 1 ou 2. Inserir o ID produz um endereço que pode ser oferecido ao usuário.

O registro proposto usaria first come, first served, permitindo à IANA recusar pedidos enganosos ou espúrios. Essa regra é adequada para coordenar um espaço de nomes. Ela não examina metodologia editorial, independência, mecanismo de recurso, qualidade jurídica, cobertura ou prazo de conservação.

Uma aplicação precisa de política própria. Pode aceitar poucos operadores, permitir escolha do usuário ou considerar também a identidade do resolvedor. Estar registrado não obriga exibição.

O resolvedor não injeta qualquer destino

Resolvedores são frequentemente configurados pela rede. Uma rede desconhecida não deve poder escrever uma URL arbitrária ou texto livre dentro do erro de um navegador. Isso criaria uma superfície de phishing.

Os identificadores e o modelo local limitam a escolha do resolvedor. Ele indica referências; a aplicação reconstrói o destino a partir do seu estado e decide se confia no operador.

A limitação melhora segurança, mas não autentica a associação. Um resolvedor malicioso pode reutilizar uma combinação válida que leva a uma página existente e alegar um bloqueio inexistente.

Página disponível prova disponibilidade. Registro reconhecido prova mapeamento. Nenhum dos dois prova que aquela página causou ou descreveu a consulta do usuário.

Uma cópia local também envelhece

A aplicação não deve consultar a IANA a cada uso. Isso reduz dependência e evita criar uma consulta central por incidente. Também separa o estado atual do registro da versão realmente usada.

O contato pode atualizar o modelo, mas clientes podem demorar. Um ID correto pode ser expandido por um aplicativo antigo para endereço obsoleto. Investigações posteriores precisam do hash da cópia local, não apenas do registro de hoje.

Registro alterado, pacote liberado, atualização instalada e política ativa são quatro momentos. Relatórios que dizem apenas “template atualizado” escondem os usuários ainda no caminho anterior.

A afirmação do incidente não é autenticada

O próprio texto reconhece que não prova que o evento vivido pela aplicação está associado às informações apresentadas. Um atacante que controla o resolvedor pode dizer que houve filtragem quando não houve.

Reutilizar um par que abre uma página real exige algum trabalho. Não é assinatura causal. Um caso verdadeiro pode ser citado para outro domínio, data ou usuário.

O resolvedor afirma relevância. O registro oferece rota. A base publica conteúdo. Para provar o incidente seria necessário vincular consulta, política aplicada, ator e registro por evidência que essa arquitetura não fornece.

Interfaces devem usar rótulos estreitos: relatado pelo resolvedor, operador aceito, página recuperada. “Bloqueio verificado” excede a evidência.

Consultar pode repetir a exposição

Abrir a página pode revelar ao operador o IP do usuário e o domínio filtrado que ele tentou resolver. Em algumas jurisdições, a combinação traz risco significativo.

Observadores de rede ainda podem inferir o incidente por destino, tempo ou token. Um proxy de privacidade reduz exposição direta, mas vira novo custodiante.

Sem proxy, o rascunho proíbe busca automática antes de ação explícita do usuário. Prévia, scanner, reputação, prefetch e expansão de metadados precisam obedecer ao mesmo limite.

Construção, exibição, clique, proxy, requisição, redirecionamento e resposta devem ter eventos distintos. Um log “informação mostrada” não prova que a saída ocorreu depois do consentimento.

Um ID pode ser um marcador de correlação

O incidente pode ter ID compartilhado ou específico da requisição. Se resolvedor e banco colaborarem, um token único permite saber qual referência distribuída no DNS reapareceu na Web.

A mesma organização pode operar os dois lados. A explicação vira elo entre intenção DNS e navegação. Confiar no operador não revela automaticamente sua política de granularidade ou retenção.

Aplicações devem observar se IDs são por caso, domínio, rede, cliente ou consulta. Proxy não remove o token; pode apenas trocar quem vê o IP.

O detalhe pode morrer antes da aplicação

Alguns sistemas não entregam opções DNS detalhadas às aplicações. O resolvedor envia fdbs, o host entrega um erro genérico e o navegador nada apresenta.

Emissão, chegada, exposição pelo host, análise, reconhecimento, aceitação, apresentação, clique e busca são etapas separadas. Falta de visita não prova falta de emissão. Emissão não prova que o usuário foi informado.

Cada transição requer denominador próprio. Uma taxa final sem perdas intermediárias transforma limitações de arquitetura em conclusões sobre comportamento humano.

Várias bases continuam sendo várias alegações

Uma lista pode aumentar a chance de compatibilidade, mas bancos podem divergir sobre data, fundamento ou responsável. O resolvedor declara que tratam do mesmo incidente; a lista não reconcilia versões.

A aplicação pode mostrar a divergência, priorizar conforme política ou recusar síntese. Não deve contar páginas como votos nem apagar a autoria de cada alegação.

O objetivo da transparência é tornar a procedência visível, não produzir certeza por agregação.

Confiança precisa de proprietário

O desenho separa poderes: resolvedor cita, registro encaminha, aplicação escolhe e usuário decide buscar. Essa separação desaparece quando todos os registrados entram automaticamente numa allowlist.

Uma organização precisa definir quem avalia operadores, como mudanças de controle acionam revisão e como o usuário recusa. O registro não toma essas decisões.

Explicar filtragem é importante. Fazer isso sem transformar coordenação em autoridade e sem criar rastreamento automático é a tarefa de governança que começa depois da especificação.

Fontes