[MASOCH-L] Bloqueio de sites no Bind

[Ricardo Rodrigues]

Respeito bastante as opiniões do Marlon, mas tenho observado uma visão
diferente em operadoras da Europa e Estados Unidos (não vou entrar no
mérito do que é feito aqui no Brasil). E quando analiso o que elas
fazem, é porque elas têm centenas de milhares / milhões de usuários e
estão preocupadas com escalabilidade, latência e segurança.

Escalabilidade: É óbvio que soluções proxy funcionam em determinados
ambientes. "Teoricamente", está correto: analisar TODO o tráfego.
Minha dúvida é se funciona bem em ambientes com centenas de milhares
de usuários. Conheço um case de uma operadora que tinha apenas 2
(DOIS) servidores DNS Cache para atender seus clientes e teve que
instalar 20 servidores proxy para fazer bloqueio a uma lista de
domínios. E com o crescente aumento da banda ao longo dos anos, fico
com receio de usar proxies para analisar TODO este tráfego e fazer o
bloqueio de milhões de domínios impróprios.

Ainda no quesito escalabilidade, faço uma analogia com o controle de
SPAM. "Teoricamente", o correto seria analisar o CONTEÚDO de todas as
mensagens. Mas o que vejo na prática são black-lists de IP Spammers
implementada usando-se o protocolo DNS ao invés de se fazer análise de
conteúdo de SPAM de todas os e-mails que chegam.

Seguem mais comentários abaixo.

2009/5/21 MARLON BORBA <MBORBA at trf3.jus.br>:
> Eu (e tenho certeza que Danton concordará comigo) vou insistir num
> ponto: DNS não é o local adequado para esse tipo de filtragem. Motivos
> para isso:
>
> a) Interfere no processo padronizado de resolução de nomes (as Teles
> têm abusado disso ao introduzir "páginas personalizadas" que aparecem
> quando um "host" não é resolvido. Se não existe, não existe e ponto
> final);

O que vejo na maioria destas "páginas personalizadas" é um verdadeiro
tiro no pé. A operadora quer maximixar o lucro com este serviço e
acaba afetando outras aplicações. Com isso o cliente fica insatisfeito
e acontece o seguinte:
- Clientes com conhecimento técnico: passam a apontar para outros
servidores DNS -> param de gerar receita no serviço de
redirecionamento
- Clientes sem conhecimento técnico: mudam para a concorrência e geram
uma perda muito maior de receita

Além disso, as operadoras devem oferecer ao cliente a opção de
desativar o serviço e receber o "comportamento default" do DNS. Isso
tem sido feito no exterior com muito sucesso e a taxa de rejeição é
ínfima, ou seja, a esmagadora maioria dos usuários vêm benefício neste
serviço.

> b) Como os "sites" de pornografia simplesmente mudam de lugar
> periodicamente, você vai ter de "mexer" na configuração do BIND inúmeras
> vezes. Ou seja, se você cometer algum erro de configuração ou de
> sintaxe, a estabilidade do seu servidor de DNS será posta em risco. Se
> esse servidor é autoritativo para domínios dos seus clientes, qualquer
> instabilidade afetará a acessibilidade das páginas deles. "If it is
> working, don't fix it";

Esta é uma conclusão de um trabalho realizado a alguns anos quando um
Estado da Alemanha obrigou o bloqueio de sites de exploração sexual
infantil. Todas as operadoras estudaram diversas tecnologias e TODAS
escolheram implementar a solução usando DNS. Chegaram à conclusão de
que é preciso que o software DNS tenha sido projetado especificamente
para esta função. Muitas soluções DNS sequer permitem que se
criem/editem/removam zonas/registros sem necessidade de
reinicialização do DNS.

> c) DNS é pouco flexível em termos de filtragem. Você pode criar
> "views", ou simplesmente introduzir registros AA para evitar que os
> "sites" sejam resolvidos, mas não mais do que isso. Filtros de conteúdo
> baseados no Squid suportam REGEXes, além de regras "prontas", permitindo
> construir bloqueios para vários "sites" de uma só vez. Acredito que seja
> possível encontrar listas públicas de "sites" reconhecidamente
> pornográficos e usá-las para os bloqueios.

Como fica a performance do Squid quando coloco 5 milhões de domínios
(Conficker) para serem bloqueados?

> Além disso, redirecionamento de DNS é algo arriscado, pois diminui a
> disponibilidade do serviço (por exemplo, se você fizer alguma "caca" com
> o seu servidor DNS, de qualquer maneira terá de modificar ou de remover
> o redirecionamento, para que seus clientes não fiquem sem resolução de
> nomes, o que impede TOTALMENTE sua navegação pela Web). Force seus
> clientes, isso sim, a usarem seus "proxies" via redirecionamento HTTP.

Usando as ferramentas corretas, não vejo problema em implementar via
DNS. O que me preocupa são a escalabilidade e a latência da solução
proxy.

Abs,
Ricardo