Pi-hole vs AdGuard Home: Filtro DNS Network-Wide para PME

1. Introdução

O tráfego DNS é o primeiro ponto de contacto de qualquer dispositivo com a Internet. Cada consulta DNS pode revelar padrões de navegação, expor dispositivos a domínios maliciosos ou carregar publicidade indesejada. Para uma pequena ou média empresa (PME), filtrar essas consultas ao nível da rede — em vez de depender de extensões de navegador em cada máquina — oferece proteção uniforme, redução de largura de banda e visibilidade sobre o tráfego.

Duas soluções código aberto dominam este espaço: Pi-hole e AdGuard Home. Ambas funcionam como servidores DNS locais que interceptam consultas e decidem, com base em listas de bloqueio, se permitem ou bloqueiam cada domínio. Nenhuma das duas requer instalação em dispositivos individuais — basta apontar o DHCP da rede para o servidor de filtragem.

Este artigo compara as duas plataformas com foco em cenários de PME: instalação via Docker, gestão de listas, integração com unbound para DNS recursivo e recomendações operacionais. O Pi-hole é tratado em maior detalhe por ser a solução mais adoptada em ambientes Linux auto-hospedado.

2. Pi-hole — Visão Geral

O Pi-hole é um sinkhole DNS (DNS sinkhole) desenvolvido em PHP e Bash, originalmente concebido para Raspberry Pi mas compatível com qualquer sistema Linux. O projecto é mantido no GitHub (repositório oficial) e distribuido sob a licença EUPL.

O Pi-hole actua como intermediário DNS entre os dispositivos da rede e os resolvedores a montante (Cloudflare, Google, Quad9, ou um resolvedor local como unbound). Quando um dispositivo consulta um domínio presente numa lista de bloqueio, o Pi-hole responde com um endereço IP nulo ou uma página de bloqueio, impedindo a ligação.

2.1 Funcionalidades-chave

• Interface web em PHP com painel de estatísticas em tempo real (consultas, bloqueios, clientes).
• Gestão de listas com suporte para múltiplas fontes externas em formato hosts ou AdBlock.
• Grupos de clientes — aplicar listas diferentes por dispositivo ou sub-rede.
• API REST para integração com sistemas de monitorização (Zabbix, Prometheus).
• FTL DNS — motor de resolução em C optimizado para alto débito.

2.2 Requisitos

• Sistema Linux (Debian, Ubuntu, Alpine, Fedora).
• Porta 53 UDP/TCP livre (DNS) e porta 80 TCP (interface web).
• Endereço IP estático no servidor.
• ~512 MB de RAM para redes até 100 dispositivos.

3. Instalação do Pi-hole via Docker

A forma mais limpa de implantar o Pi-hole numa PME é via Docker Compose. Isto garante isolamento, fácil actualização e reprodutibilidade. O repositório oficial mantém uma imagem Docker publicada no Docker Hub.

Criar o ficheiro docker-compose.yml no directório do projecto:

services:
  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    hostname: pihole
    environment:
      TZ: "Europe/Lisbon"
      WEBPASSWORD: "alterar-esta-password"
      DNS1: "1.1.1.1"
      DNS2: "9.9.9.9"
    volumes:
      - ./etc-pihole:/etc/pihole
      - ./etc-dnsmasq.d:/etc/dnsmasq.d
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
    cap_add:
      - NET_ADMIN
    restart: unless-stopped

Iniciar o contentor:

docker compose up -d

Aceder à interface web em http://<IP-servidor>/admin com a palavra-passe definida em WEBPASSWORD.

4. Configurar Listas e Grupos

A força do Pi-hole está nas listas de bloqueio. Por defeito, vem com listas básicas de publicidade. Para uma PME, recomenda-se adicionar listas adicionais orientadas a segurança (malware, phishing, telemetry).

4.1 Listas recomendadas

Adicionar via interface web em Adlists ou via CLI:

# Listas de publicidade
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts

# Listas de malware e phishing
https://urlhaus-filter.pages.dev/hosts

# Telemetry da Microsoft
https://raw.githubusercontent.com/jdlingu/adaway-list/master/hosts

4.2 Grupos de clientes

Os grupos permitem aplicar políticas diferentes por dispositivo. Exemplos para PME:

• Grupo “Workstations” — listas de publicidade + malware. Permite redes sociais.
• Grupo “Servidores” — apenas listas de malware. Sem bloqueio de publicidade (pode interferir com APIs).
• Grupo “IoT” — listas de telemetry + malware. Bloqueia domínios de fabricantes conhecidos.
• Grupo “Convidados” — listas máximas. Sem acesso a redes sociais ou transmissão.

Atribuir clientes a grupos via Group Management → Clients, especificando o endereço IP ou MAC de cada dispositivo.

5. Pi-hole + unbound (DNS recursivo)

Por defeito, o Pi-hole reenvia consultas para um resolvedor a montante (Cloudflare, Google). Isto significa que esse resolvedor conhece todo o tráfego DNS da empresa. Para privacidade máxima, pode-se integrar o unbound como resolvedor recursivo local — o Pi-hole consulta o unbound, que por sua vez resolve directamente os servidores raiz (root servers) sem intermediários.

Adicionar o unbound ao docker-compose.yml:

services:
  pihole:
    # ... configuração do Pi-hole (igual ao passo 3)
    environment:
      TZ: "Europe/Lisbon"
      WEBPASSWORD: "alterar-esta-password"
      DNS1: "127.0.0.1#5335"
      DNS2: ""
    depends_on:
      - unbound

  unbound:
    image: mvance/unbound:latest
    container_name: unbound
    ports:
      - "5335:53/tcp"
      - "5335:53/udp"
    volumes:
      - ./unbound:/opt/unbound/etc/unbound
    restart: unless-stopped

A configuração do unbound deve activar DNSSEC, privacidade (qname-minimisation) e caching. O Pi-hole passa a usar 127.0.0.1#5335 como único a montante, eliminando dependência de resolvedores externos.

6. Comparação Pi-hole vs AdGuard Home

O AdGuard Home é a alternativa principal ao Pi-hole. Escrito em Go, oferece uma abordagem mais integrada com suporte nativo a DoH (DNS over HTTPS) e DoT (DNS over TLS). A tabela seguinte resume as diferenças relevantes para PME:

7. Boas Práticas para PME

Implementar filtragem DNS numa empresa requer planeamento. As seguintes recomendações aplicam-se a ambas as plataformas:

7.1 Configuração de rede

• Atribuir IP estático ao servidor de filtragem e configurar o DHCP para distribuir esse IP como DNS primário.
• Configurar um segundo DNS (fallback) apenas se houver redundância física — um fallback externo permite contornar o filtro.
• Registar registos DNS para retenção mínima de 90 dias (RGPD/levantamento forense).

7.2 Operação

• Actualizar listas automaticamente (cron diário ou graças ao scheduler nativo).
• Monitorizar falsos positivos — domínios legítimos bloqueados causam chamados ao suporte. Configurar whitelist activa.
• cópia de segurança regular de /etc/pihole e volumes Docker.
• Actualizar o contentor Docker mensalmente: docker compose pull && docker compose up -d.

7.3 Segurança

• Alterar a palavra-passe predefinida da interface web imediatamente após instalação.
• Restringir o acesso à interface web por IP ou VPN — não expor a porta 80 à Internet.
• Activar DNSSEC no unbound para validar respostas e prevenir envenenamento de cache.
• Combinar filtragem DNS com firewall de rede — o DNS bloqueia domínios, mas não portas ou protocolos.