Quando vejo propostas de “bloqueio na infraestrutura” (DNS, IP e VPN) para combater pirataria, eu já sei onde isso vai dar: não resolve a origem do problema e ainda quebra o ecossistema da web. Segundo o Sapo.pt, a Google alertou a Europa que essas táticas são desadequadas, ineficazes e arriscam causar danos colaterais sérios — e eu concordo com o diagnóstico técnico por um motivo simples: filtrar na borda não impede que o conteúdo continue aparecendo em outros lugares.
Na prática, esse tipo de bloqueio costuma virar uma série de regras “cegas”, difíceis de manter, com contorno fácil e efeitos colaterais inevitáveis. E se você programa, isso não é “política pública distante”: é o mesmo padrão que você vê em produção quando alguém tenta resolver um problema complexo com uma blacklist mal pensada.
O que a Google está dizendo (e por que isso faz sentido tecnicamente)
Segundo o Sapo.pt, a Google enviou uma comunicação à Comissão Europeia argumentando que bloquear DNS, IP ou VPNs não elimina o conteúdo ilegal “na origem”. O ponto central é que o bloqueio é sempre uma resposta reativa e fragmentada: o infrator muda endpoint, CDN, rota, domínio, ou até o método de entrega (por exemplo, fluxos alternativos).
Além de ineficaz, a Google aponta riscos sérios para o funcionamento geral da web. Isso inclui problemas de reputação, interrupções acidentais e efeitos sobre serviços que nada têm a ver com a pirataria — algo que, tecnicamente, sempre acontece quando você bloqueia por infraestrutura em vez de por identificação de conteúdo.
Por que bloquear DNS/IP/VPN não ataca a causa
Na minha experiência, a falha de abordagem está em tratar “pirataria” como sinônimo de “um endereço” ou “um provedor”. Mas o ecossistema moderno é distribuído. Conteúdo ilícito pode residir em:
- Domínios diferentes (ou subdomínios que trocam rapidamente)
- IP compartilhado em hospedagem multi-tenant
- CDNs com rotação de endpoints
- Tecnologias de evasão (ex.: proxies, mirror sites, relays)
- Protocolos e rotas alternativos (não depende de um único “canal”)
Se a regra é “bloqueie DNS daquele domínio” ou “bloqueie IP X”, a reação do atacante é quase imediata. E quando o atacante reage com velocidade maior do que a atualização das listas, o bloqueio vira um jogo de gato e rato com custo alto — para todo mundo.
O problema do IP compartilhado: um bug de “blast radius”
O Sapo.pt cita um caso em Portugal (2019) em que um operador bloqueou um endereço IP compartilhado e isso afetou clientes de cloud que não tinham relação com o domínio infrator. Isso tem um paralelo direto com engenharia:
se você bloqueia um recurso compartilhado, você inevitavelmente cria “blast radius”.
Em infra real, é comum múltiplos serviços coexistirem no mesmo IP (especialmente em setups com NAT, balanceadores, CDNs ou políticas de hospedagem). O bloqueio por IP não “entende” serviço. Ele apenas corta tráfego.
DNS bloqueado: onde a ideia parece funcionar (e por que quebra no mundo real)
Bloquear via DNS parece elegante porque você impede o “resolve”. Só que o DNS não é um ponto único de verdade. Ele é mais um componente dentro de um caminho maior.
Contornos típicos (e por que são fáceis)
- DNS over HTTPS (DoH) e DNS over TLS (DoT): você foge da resolução controlada pelo ISP.
- Resolvers públicos: mudar para Cloudflare/Google/quadros corporativos pode contornar filtros.
- Cache: dependendo do TTL e da política do operador, você prolonga acesso por um tempo.
- Substituições rápidas: troca de domínios/subdomínios reduz o impacto do bloqueio.
O resultado prático é que você ganha um bloqueio “temporário” e “incompleto”, enquanto aumenta a superfície de problemas para usuários comuns e serviços legítimos.
VPN bloqueada: não é só “pirata”, é quebra de ferramenta
VPN é um termo genérico. Eu uso VPN para coisas legítimas: acesso remoto seguro, trabalho em rede de laboratório, integração entre ambientes, e também testes de conectividade.
Quando alguém tenta bloquear VPNs, geralmente faz isso de maneira aproximada: por faixas de IP, características de tráfego, ou provedores. Só que:
- muitos usuários dependem de VPNs para segurança
- projetos legítimos (incluindo ONGs, pesquisa e governo) usam
- bloqueios “por categoria” batem em falsos positivos
Segundo o Sapo.pt, há relatos de bloqueios que limitaram acesso de organizações não governamentais de direitos humanos, agências internacionais e instituições governamentais. Isso é o tipo de consequência que um dev enxerga como “regra genérica aplicada num universo heterogêneo”.
Comparação com alternativas reais (o que funciona melhor na engenharia)
Sem entrar em juridiquês, do ponto de vista de engenharia eu separo “estratégias” em duas categorias: bloqueio cego vs. mitigação mais dirigida.
1) Bloqueio cego por infraestrutura (DNS/IP/VPN)
Prós: pode ter resposta rápida no curto prazo. Contras: é facilmente contornável e gera blast radius alto.
2) Mitigação por identificação mais específica
Em geral, o que reduz efeitos colaterais é aumentar o “alvo” do filtro: em vez de bloquear infraestrutura compartilhada, mirar em características mais específicas do recurso ou fluxo (com coordenação adequada). Isso pode envolver mecanismos técnicos e processos (notificação, remoção, compliance), não apenas listas.
O motivo do “porquê” aqui é direto: quanto mais genérica a chave de bloqueio, maior o risco de atingir legítimos. E o atacante, em contrapartida, consegue reapontar o recurso com menos esforço.
Na prática: como a ideia quebra num fluxo de produção (passo a passo)
Vou descrever um cenário que eu já vi se repetir em incidentes (mesmo quando a intenção era “corrigir”). Imagine que um operador decide bloquear IPs/DNS para impedir streaming/iptv ilícito.
- Um domínio infrator resolve para um IP de hospedagem compartilhada (ou um balanceador/CDN).
- O operador cria uma regra: “bloquear IP X”.
- Outros serviços legais compartilham IP X (cloud multi-tenant, APIs, dashboards, etc.).
- Usuários começam a falhar em rotas que dependem daquele IP (timeouts, erros de conexão, páginas que não carregam).
- Como o bloqueio é infra-level, não existe “granularidade”: não dá para desligar só a parte ilícita.
- O infrator troca para um endpoint alternativo (outro IP/domínio/CDN) e o bloqueio perde relevância.
O resultado é o que o Sapo.pt menciona: impactos colaterais em produtividade e cloud, além de um bloqueio que não acompanha a dinâmica de evasão.
Um paralelo técnico com “blacklist” no seu código
Se você já implementou alguma regra de acesso por lista estática (mesmo que dentro de um app), sabe a armadilha: lista desatualiza, gera falso positivo e quebra fluxo legítimo. O trecho abaixo é um exemplo didático do padrão “genérico demais” que dá ruim.
const blockedIPs = new Set(["203.0.113.10"]); // exemplo estático
function canAccess(request) {
const ip = request.ip; // IP observado na borda
if (blockedIPs.has(ip)) return false; // bloqueia tudo daquele IP
return true;
}
// Problema: IP pode ser compartilhado e conter tráfego de serviços legítimos também.
O “porquê” desse exemplo: quando sua chave de decisão é compartilhada, você transforma uma mitigação direcionada em um bloqueio indiscriminado. No mundo de DNS/IP em ISPs, isso é ainda mais comum.
Erros comuns que devs (e operadores) cometem ao tentar “resolver com bloqueio”
1) Confundir “endereço” com “conteúdo”
IP/DNS são localizadores de rede. Conteúdo é algo mais semântico. Se você bloqueia localizadores, você bloqueia junto o que estiver atrás deles.
2) Ignorar multi-tenant, CDN e balanceadores
O mesmo IP pode servir múltiplos domínios e serviços. O Sapo.pt cita explicitamente o efeito de bloqueio em IP compartilhado.
3) Tratar como lista fixa (sem mecanismo de atualização e evidência)
Listas estáticas expiram. Atualização manual é lenta. Evidência fraca cria falso positivo. Isso vira um “runbook de incidentes”.
4) Não medir impacto colateral
Se você não cria métricas (erro por ASN, por país, por categoria de serviço legítimo), você só descobre o estrago depois que usuários reclamam. Eu já vi isso acontecer até em times experientes.
5) Subestimar a capacidade de evasão
Bloqueios “na borda” quase sempre são contornáveis com alternativas de resolução/rota. Se a estratégia não remove a oferta ilegal, ela só atrasa.
Implicações práticas para quem programa (incluindo quem faz web e IA)
Você pode pensar: “isso não me afeta”. Afeta, sim. Alguns impactos práticos que eu observo em desenvolvimento:
- Ambientes de teste: CI/CD e ferramentas externas podem depender de domínios/serviços que acabam tocados por bloqueios genéricos.
- Infra multi-região: quando existe rotação de endpoints, um bloqueio por IP pode “pegar” instantes aleatórios.
- Usuários corporativos: VPNs e túneis são usados para compliance; bloqueio agressivo vira ticket infinito.
- Observabilidade: spikes de erro de rede confundem diagnóstico (parece bug no app, mas é bloqueio upstream).
- Depuração e rate limits: quando falha intermitente ocorre, equipes tendem a errar o alvo (código vs. rede).
Para projetos de dados e IA, também tem um efeito: pipelines que buscam modelos/recursos externos podem ser interrompidos por mudanças de conectividade. Você acha que é “timeout do provedor”; às vezes é bloqueio intermediário.
Como eu abordaria esse tema do ponto de vista de sistema (framework de decisão)
Quando alguém me pede para opinar sobre “mitigação na internet”, eu penso em três critérios, que são bem de engenharia:
- Efetividade real contra evasão: o alvo muda rápido? a lista acompanha?
- Granularidade do bloqueio: a chave é compartilhada? tem blast radius?
- Impacto em serviços legítimos: existe medição e mecanismos de rollback?
Se a resposta para granularidade é “não” e para impacto colateral é “a gente descobre depois”, então eu já sei que vai dar problema. O alerta do Sapo.pt sobre DNS/IP/VPN encaixa exatamente nesse padrão.
FAQ
Bloquear DNS resolve mesmo?
Na prática, não resolve de forma sustentável. Segundo o Sapo.pt, bloqueios focados em DNS são facilmente contornados (DoH/DoT, resolvers alternativos) e não removem o conteúdo da origem. O atacante muda o endpoint.
Por que bloquear IP pode afetar serviços legítimos?
Porque IPs frequentemente são compartilhados por infraestrutura (CDNs, balanceadores, multi-tenant). O caso citado no Sapo.pt (Portugal, 2019) mostra exatamente esse efeito colateral com cloud.
VPN é “só pirataria”?
Não. VPN é ferramenta de segurança e produtividade. Se você bloqueia por categoria de tráfego/provedor, você inevitavelmente atinge usuários e organizações legítimas — como o Sapo.pt relata em exemplos envolvendo ONGs e instituições.
Existe uma forma técnica melhor do que “listas de bloqueio”?
Em geral, a mitigação mais efetiva tende a ser mais específica e coordenada (reduzindo blast radius). Bloqueio cego por infraestrutura raramente acompanha a dinâmica de evasão e aumenta danos colaterais.
O que devo fazer como dev quando vejo instabilidade de rede?
Eu começaria checando: mudanças de resolução (DNS), rotas, status de endpoints externos, e evidências de bloqueio upstream (erros consistentes por ASN/país/ISP). O “caminho” da rede pode estar quebrado fora do seu código.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.