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:
| Registro | Efeito |
|---|---|
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 nome | Redireciona para uma página de aviso |
CNAME rpz-passthru. | Exceção: responde normalmente, mesmo que outra regra bloqueie |
Um trecho de zona, para visualizar:
$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 (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 (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:
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