Quando você tenta controlar acesso por domínio usando só firewall, descobre rápido que está lutando contra as forças da natureza:
CDNs mutantes, IPs rotativos, pools gigantes e serviços que trocam endereço como quem troca de meia.
A saída elegante — e totalmente dominante — é usar DNS como filtro primário.
E o método supremo é o DNS “Deny All” com Unbound.
A ideia é brilhantemente minimalista:
- Bloqueia absolutamente tudo por DNS.
- Libera somente os domínios aprovados.
- Encaminha o resto para resolvers externos confiáveis.
- (Opcional) Mostra página personalizada de bloqueio.
- Sem wildcard. Sem proxy. Sem bullying de certificado HTTPS.
E funciona até em rede dentro de rede dentro de rede em L3.
Como o Unbound trata domínios (a parte mágica)
No Unbound, você controla o destino de um domínio inteiro definindo uma zona local.
Se disser:
local-zone: "dominio.com" static
Tudo isso é bloqueado automaticamente:
- dominio.com
- www.dominio.com
- api.dominio.com
- *.cdn.gcp-us-east-1.dominio.com
- qualquer.lista.de.bagunça.dominio.com
DNS não pergunta. Se está na árvore, cai.
E não existe wildcard aqui:
DNS trabalha por zona → você manda na raiz → Unbound domina tudo abaixo.
Redirecionando para uma página de bloqueio
Sim, você pode fazer estilo “Firewall Corporativo anos 2000” e mandar tudo para um portal dizendo que o acesso foi negado.
Exemplo:
local-zone: "dominio.com" redirect
local-data: "dominio.com A 10.0.0.50"
Agora todo domínio que cair nessa zona aponta para seu servidor de aviso.
(E sim, todos os subdomínios também.)
Fazendo o “Deny All” de verdade (o feitiço base do sistema)
Para bloquear a internet inteira, você usa a zona raiz:
local-zone: "." refuse #se usar static, mata tudo
O “.” é literal. É a raiz do DNS global.
Com esse único ponto, você matou todo tráfego DNS da sua rede.
Nada resolve. Nada abre. Ninguém vai a lugar nenhum.
Agora vem o whitelist.
Liberando só certos domínios (a whitelist elegante)
Para domínios permitidos, você troca o comportamento para transparent:
local-zone: "google.com" transparent
local-zone: "gstatic.com" transparent
local-zone: "youtube.com" transparent
“transparent” significa:
Não bloqueie; encaminhe normalmente para resolução externa.
Essa é a whitelist verdadeira, funcional até para apps de smartphone, sem proxy, sem certificado, sem sniffing HTTPS.
Mas quem responde as consultas externas?
A mágica do forwarder
Você não precisa recriar a internet, nem rodar bind9 como servidor autoritativo, nem sincronizar root hints.
Basta encaminhar para DNS externos confiáveis:
forward-zone:
name: "."
forward-addr: 1.1.1.1
forward-addr: 9.9.9.9
Esses DNS resolvem tudo para você.
O Unbound só bloqueia, libera e controla o fluxo, sem ser obrigado a conhecer todas as zonas de todas as empresas do planeta.
Qual DNS externo usar (rápido e objetivo)
- 1.1.1.1 – Cloudflare (rápido, privacidade decente)
- 9.9.9.9 – Quad9 (segurança forte, filtra malware conhecido)
- 8.8.8.8 – Google (funciona, ponto, mas sem privacidade)
Combinação mais comum: 1.1.1.1 + 9.9.9.9.
Colando tudo junto: exemplo completo
Esse é o modelo pronto para produção.
server:
interface: 0.0.0.0
access-control: 0.0.0.0/0 allow
verbosity: 1
do-ip4: yes
do-ip6: no
hide-identity: yes
hide-version: yes
prefetch: yes
qname-minimisation: yes
# DNS DENY ALL
local-zone: "." refuse
# Whitelist de domínios liberados
local-zone: "google.com" transparent
local-zone: "gstatic.com" transparent
local-zone: "youtube.com" transparent
local-zone: "cloudflare.com" transparent
# Redirecionamento
local-zone: "facebook.com" redirect
local-data: "facebook.com A 10.0.0.84"
# Forward só para a internet real
forward-zone:
name: "."
forward-addr: 1.1.1.1
forward-addr: 9.9.9.9
Resumo estilo tatuagem de sysadmin
- local-zone: “.” static → desliga a internet inteira.
- transparent → deixa passar.
- redirect → manda pra página legal.
- forward-zone → quem resolve tudo é o DNS externo.
- Nada de wildcard.
- Nada de proxy transparente.
- Nada de interceptar HTTPS.
- Funciona em smartphone, tablet, IoT, qualquer coisa que faça query DNS.
Quando usar
- Wi-Fi escolar ou corporativo
- Subrede isolada
- IoT com behavior suspeito
- Celas hostis dentro do teu próprio datacenter
- Ambientes com política “somente domínios específicos”
- Quando quer controle absoluto sem gambiarra de proxy