Uma linha do dnsmasq pode responder a um nome com NXDOMAIN, e esse é todo o mecanismo. Nunca lê HTML, nunca inspeciona um caminho de pedido e nunca vê o que uma aplicação faz com uma ligação que já abriu. Compará-la com uma extensão de navegador é, por isso, comparar dois trabalhos diferentes. Um decide se um nome resolve; o outro decide o que acontece depois.

O que um filtro de nomes controla de facto

A opção address=/metrics.example/, sem nada após a última barra, faz o resolver devolver NXDOMAIN para esse nome e os seus subdomínios. Deixar o endereço vazio é a parte importante: evita enviar clientes para um servidor de substituição não relacionado ou fingir que um endereço loopback é o destino real. O manual do dnsmasq documenta essa forma como resposta negativa e não como redirecionamento.

Tudo o que a regra pode fazer decorre dessa única decisão. Um cliente que pergunte a este resolver recebe uma resposta negativa; um cliente que pergunte a outro resolver recebe o que esse resolver disser. O filtro não sabe que caminho, que string de consulta ou que conta a aplicação teria usado.

Essa granularidade importa porque um nome de anfitrião serve muitas vezes vários propósitos. Pontos de entrada de sessão, imagens e rastreamento podem partilhar um domínio, e uma regra que remova o nome inteiro pode remover um fluxo de trabalho com ele. Uma política ao nível do nome tem de aceitar esse compromisso ou escolher nomes mais estreitos.

Onde um bloqueador do lado do cliente difere

Uma extensão de navegador vê o pedido antes de ele sair, pelo que pode corresponder a um caminho do URL, cancelar um pedido específico e ocultar o elemento que teria mostrado o resultado. Pode permitir example.com/article e recusar example.com/ads/, o que nenhuma resposta DNS consegue exprimir. Essa vista ao nível do caminho é a capacidade que um resolver simplesmente não tem. É também por isso que uma lista de filtros criada para uma ferramenta raramente se comporta da mesma forma na outra.

O custo é o alcance. Essa proteção vive dentro de um navegador, num perfil, num dispositivo, e desaparece quando o utilizador passa para outra aplicação. Um filtro DNS configurado no gateway cobre todos os dispositivos que usem o resolver do gateway, incluindo dispositivos onde nenhuma extensão pode ser instalada.

Nenhuma das disposições é completa por si só. Um filtro DNS não consegue remover um identificador que uma página já enviou, e uma extensão de navegador não consegue proteger uma aplicação que nunca a carrega.

O caminho do resolver decide se algo disto se aplica

Uma VPN pode anunciar um servidor DNS e ainda assim não receber todas as consultas. Um navegador com DNS cifrado configurado, uma aplicação com o seu próprio resolver ou um dispositivo num caminho de rede que exclua o gateway vão todos procurar noutro sítio. As plataformas móveis oferecem cada vez mais uma definição de DNS privado que anula silenciosamente o que o túnel sugere.

Por isso, teste o caminho e não a política. Consulte o resolver pretendido diretamente a partir do gateway, consulte-o depois a partir de um cliente e compare, e observe em seguida se um nome que devia estar bloqueado falha mesmo na aplicação que o utilizador executa.

Respostas em cache e sockets abertos tornam isto ruidoso. Uma página que já carregou os seus recursos continua a funcionar depois de a regra mudar, pelo que uma ligação nova é um teste melhor do que recarregar um separador antigo.

Teste os dois sentidos antes de reivindicar um resultado

Use um nome de documentação deliberadamente bloqueado, um nome público permitido e um nome privado de que o serviço precisa:

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

Uma resposta vazia para o nome bloqueado, um endereço normal para o público e um endereço privado para o interno mostram, em conjunto, que a filtragem, a resolução a montante e os registos locais funcionam. Se os três falharem, está a olhar para um problema a montante ou de listener e não para um filtro.

Mantenha a afirmação estreita em tudo o que publicar internamente. Isto é filtragem de domínios num resolver, não inspeção de conteúdo, não filtragem de caminhos e não uma promessa de que ninguém é rastreado. Indique o dono da política, o caminho de exceção e o período de retenção de consultas ao lado das regras, porque um filtro que registe todas as pesquisas tem o seu próprio custo de privacidade.

Artigos relacionados