BTECH Automations

DNS

Bloqueio de domínios por ofício judicial e da Anatel com RPZ

Como provedores aplicam bloqueios de domínios determinados pela Justiça e pela Anatel usando RPZ nos servidores DNS recursivos: funcionamento, zona RPZ, Unbound e BIND, limites e controle.

Por Rodrigo Borges, BTECH Automations · · 9 min de leitura

Ofícios judiciais e determinações da Anatel mandando bloquear domínios deixaram de ser raros: sites de apostas não autorizadas, pirataria de conteúdo e IPTV, golpes. Para o provedor, cada ordem tem prazo, precisa ser cumprida em todos os servidores e deixar registro de quando foi aplicada.

Neste tutorial você vai entender como o bloqueio é feito nos servidores DNS recursivos com RPZ (Response Policy Zones), como montar a zona, como aplicá-la no Unbound e no BIND, o que o bloqueio por DNS não alcança e o controle que um ofício exige.

Por que provedores bloqueiam domínios

O provedor de acesso não hospeda o conteúdo, mas controla o servidor DNS recursivo que os clientes usam (veja o tutorial de DNS recursivo, autoritativo e reverso). Por isso as ordens de bloqueio costumam chegar a ele de duas formas:

  • Ofícios judiciais endereçados ao provedor, com uma lista de domínios e um prazo;
  • Listas da Anatel, enviadas às prestadoras em cumprimento a decisões judiciais ou de outros órgãos, como no caso dos sites de apostas sem autorização.

Em ambos os casos, o provedor precisa aplicar o bloqueio, manter enquanto a ordem valer e conseguir demonstrar quando e como cumpriu.

O que é RPZ

Antes do RPZ, a forma comum de bloquear era criar uma zona falsa para cada domínio no recursivo. Funciona, mas cada domínio vira um bloco de configuração, e listas com milhares de entradas se tornam impossíveis de manter.

O RPZ inverte a lógica: existe uma única zona, com um registro por domínio, que diz ao recursivo como responder a ele. A zona pode ser carregada de um arquivo ou recebida por transferência de outro servidor, exatamente como uma zona comum. Isso permite manter a lista em um único lugar e distribuí-la para todos os recursivos.

A zona RPZ

Cada registro da zona diz o que fazer com um nome. As ações mais usadas:

RegistroEfeito
CNAME .Responde que o domínio não existe (NXDOMAIN)
CNAME *.Responde que o nome existe, mas sem nenhum registro (NODATA)
A ou CNAME para outro nomeRedireciona para uma página de aviso
CNAME rpz-passthru.Exceção: responde normalmente, mesmo que outra regra bloqueie

Um trecho de zona, para visualizar:

rpz.bloqueios.zone
$TTL 300
@   IN SOA localhost. hostmaster.exemplo.net.br. (
        2026101701 3600 600 86400 300 )
    IN NS  localhost.

; Ofício 1234/2026 - Vara X - recebido em 17/10/2026
apostas-exemplo.com      CNAME .
*.apostas-exemplo.com    CNAME .

Repare na linha com curinga: sem ela, www.apostas-exemplo.com continuaria acessível. E a cada alteração o serial precisa aumentar, ou os servidores que recebem a zona por transferência não percebem a mudança.

Aplicando no Unbound e no BIND

A zona é a mesma; muda a forma de declarar em cada software. No Unbound (a partir da versão 1.10):

unbound.conf
# unbound.conf (trecho)
server:
    module-config: "respip validator iterator"

rpz:
    name: rpz.bloqueios
    zonefile: /etc/unbound/rpz.bloqueios.zone
    rpz-log: yes

No BIND, a zona é declarada como qualquer outra e ativada com response-policy:

named.conf
// named.conf (trecho)
options {
    response-policy { zone "rpz.bloqueios"; };
};

zone "rpz.bloqueios" {
    type primary;
    file "/etc/bind/rpz.bloqueios.zone";
    allow-query { none; };
};

Para testar, consulte o domínio no próprio recursivo e confira se a resposta mudou:

bash
dig @127.0.0.1 apostas-exemplo.com
#   status: NXDOMAIN   → bloqueado

dig @127.0.0.1 www.apostas-exemplo.com
#   status: NXDOMAIN   → curinga funcionando

Esses trechos mostram só o mecanismo. Em um provedor com vários recursivos, editar o arquivo em cada servidor é exatamente o que gera bloqueios aplicados em um servidor e esquecidos em outro.

Os limites do bloqueio por DNS

O RPZ age apenas sobre as consultas que chegam ao seu recursivo. Ele não alcança:

  • clientes que configuraram outro servidor DNS no roteador ou no computador;
  • navegadores e aplicativos com DNS sobre HTTPS (DoH) ativado, que consultam servidores externos por HTTPS;
  • acesso direto pelo IP do site.

Por isso algumas ordens determinam também o bloqueio por IP, aplicado nos roteadores ou firewalls da rede. Esse tipo de bloqueio tem outro risco: IPs de CDNs e serviços de hospedagem são compartilhados por milhares de sites, e bloquear um deles pode derrubar serviços legítimos. Bloqueio por IP exige análise de cada endereço antes de aplicar.

O controle que um ofício exige

Aplicar o bloqueio é a parte técnica. Cumprir o ofício envolve também:

  • Prazo. Registrar quando o ofício chegou e quando o bloqueio entrou em vigor em todos os servidores.
  • Origem de cada entrada. Saber, para cada domínio bloqueado, qual documento determinou o bloqueio. Sem isso, ninguém consegue responder se um domínio pode ser liberado.
  • Listas grandes e mal formatadas. Ofícios chegam em PDF ou planilha, com domínios repetidos, com http://, barras e caminhos. A lista precisa ser normalizada antes de virar zona.
  • Revogações. Ordens são revogadas ou alteradas, e manter um bloqueio que já não vale também é um problema.
  • Consistência. Conferir periodicamente que todos os recursivos estão com a mesma versão da zona.
  • Página de aviso. Redirecionar para uma página explicando que o bloqueio é determinação legal reduz chamados no suporte.

Do tutorial à produção

O mecanismo do RPZ cabe em poucas linhas de configuração. O que dá trabalho, e risco, é a operação em torno dele, que fica fora deste tutorial:

  • Entrada dos ofícios. Importação de listas em PDF e planilha, normalização dos domínios e registro do documento de origem de cada entrada.
  • Distribuição. Zona mantida em um único lugar e distribuída por transferência para todos os recursivos, com conferência de que todos estão atualizados.
  • Histórico e comprovação. Quem incluiu, quando, por qual documento e quando saiu, pronto para responder a qualquer questionamento.
  • Bloqueio por IP com análise. Quando a ordem exige, aplicado nos roteadores sem derrubar serviços que compartilham o mesmo IP.
  • Página de aviso e suporte. Redirecionamento para uma página informativa e orientação para o atendimento.

Perguntas frequentes

O bloqueio por DNS impede totalmente o acesso ao site?

Não. Ele impede que os clientes que usam o DNS recursivo do provedor resolvam o domínio. Quem configura outro servidor DNS ou usa DNS sobre HTTPS no navegador continua acessando. Por isso algumas ordens também determinam bloqueio por IP, que é aplicado na rede e não no DNS.

Qual servidor DNS suporta RPZ?

Os principais recursivos usados por provedores: BIND, Unbound, PowerDNS Recursor e Knot Resolver. A sintaxe da zona RPZ é a mesma em todos; muda só a forma de declarar a zona na configuração de cada um.

Bloquear o domínio bloqueia os subdomínios?

Não automaticamente. Na zona RPZ, o registro do domínio vale só para ele. Para incluir os subdomínios, é preciso um segundo registro com curinga, como *.exemplo.com.

O que fazer quando o bloqueio é revogado?

Remover o domínio da zona RPZ, incrementar o serial e confirmar que todos os recursivos receberam a nova versão. O mesmo controle usado para registrar a entrada do bloqueio deve registrar a saída, com o documento que a determinou.

CONSULTORIA BTECH

Prefere que alguém faça isso por você?

A BTECH Automations é uma consultoria em automação, redes e cloud para provedores, operadoras e empresas de hospedagem. Implementamos DNS e bloqueios por ofício para provedores de ponta a ponta, documentamos e mantemos funcionando, com um pacote mensal de horas e relatório de cada atividade.

  • ✓ Filtros BGP, IRR, RPKI e DNS automatizados
  • ✓ Zabbix, Grafana, logs e alertas sob medida
  • ✓ Cloud, virtualização, backups e portais do cliente

Outros tutoriais