Unbound-kindns

Introdução

Servidores de DNS Recursivos precisam ser bem configurados e atender a alguns requisitos de segurança e boas práticas. Como definição para essas ações podemos seguir as práticas do KINDNS da ICANN, descritos aqui. Para diminuir a curva de dificuldade entre instalação e configuração, criei um projeto no GitHub chamado UNBOUND-KINDNS. O projeto tem como objetivo facilitar a instalação de um sistema, para atender as 7 práticas do KINDNS utilizando containers do Docker. Vamos fazer um check list rápido do que contempla o projeto:

• Prática 1 - A validação DNSSEC deve estar obrigatoriamente habilitada nos resolvedores recursivos. Unbound já atende por padrão.
• Prática 2 - Regras de ACL devem ser obrigatoriamente utilizadas para restringir quem pode enviar consultas recursivas aos seus resolvedores/validadores DNS. Este projeto possui arquivos de ACLs para liberar apenas quem pode consultar seu DNS.
• Prática 3 - A minimização de QNAME (QNAME Minimization) deve estar obrigatoriamente habilitada para mitigar o vazamento de nomes de domínio. Este projeto encontra-se com QNAME minimization já ativo.
• Prática 4 - Os serviços DNS autoritativo e recursivo não devem coexistir no mesmo servidor DNS. Unbound não faz Autoritativo, então OK também.
• Prática 5 - Os seus serviços de resolução recursiva devem possuir resiliência, utilizando pelo menos dois servidores distintos, considerando critérios de diversidade. Este projeto te permite configurar DNS(s) Primário e Secundário ou uma rede de DNS(s) Anycast.
• Prática 6 - O monitoramento dos serviços, servidores e equipamentos de rede que compõem a sua infraestrutura DNS deve ser obrigatoriamente implementado. O projeto já entrega um container com Zabbix Agent2 7.0.x e um script para envio de métricas para o Zabbix Server. O template para o Zabbix Server encontra-se aqui.
• Prática 7 - DoT (DNS-over-TLS) ou DoH (DNS-over-HTTPS) deveriam estar habilitados. A implantação de qualquer um deles é a forma mais simples de proteger contra interceptação (eavesdropping), manipulação de consultas DNS e ataques do tipo homem-no-meio (Man-in-the-Middle), por meio da criptografia das consultas DNS entre o resolvedor stub e o resolvedor recursivo, ou entre um resolvedor encaminhador (forwarder) e um resolvedor recursivo. Aqui também o projeto entrega o sistema preparado para DoT e DoH, só necessitando da configuração dos certificados TLS.

Requisitos

O projeto foi concebido para rodar em um GNU/Linux Debian 13 (Trixie) mas fique à vontade para modificá-lo para sua distribuição GNU/Linux favorita. Como os serviços rodam em containers, ficam independentes de distro GNU/Linux.

Um pouco de conhecimento em administração GNU/Linux e Docker.

Um sistema com 8 vCores e 16G de ram suporta +20.000 assinantes simultâneos.

Preparação antes de rodar o script

No topo do script unbound_kindns.sh existem algumas variáveis para configurarmos antes de sua execução:

• CORES: Número de núcleos de CPU dedicados ao Unbound (define o parâmetro num-threads na configuração do Unbound; padrão: 4).
• OSPF_INTERFACE: Interface física de rede utilizada para o roteamento OSPF (por exemplo, ens20). Se deixado em branco, a implantação de OSPF/Anycast (container FRR) será ignorada, executando o sistema em modo autônomo (stand-alone).
• APPARMOR: Defina como 0 para desabilitar o AppArmor e obter o máximo desempenho, ou como 1 para mantê-lo habilitado.
• MITIGATIONS: Defina como off para desabilitar as mitigações de CPU e obter o máximo desempenho, ou como auto para deixá-las no modo automático.
• ZBX_HOSTNAME: Identificador do host no servidor Zabbix. Se deixado em branco, o script utilizará o hostname do sistema.
• CERT_DOMAIN: Nome de domínio utilizado para os certificados SSL do Let's Encrypt (empregado na validação dos serviços DoH e DoT; padrão: doh.brasil.com.br).
• ZBX_SERVER_HOST: Endereço IP do servidor Zabbix.
• ZBX_SERVER_ACTIVE: Endereço IP do servidor Zabbix ativo (Active Zabbix Server).
• ZBX_LISTENIP: Endereço IP de vinculação (binding) para o container do Zabbix Agent 2 escutar conexões (padrão: 0.0.0.0).

Executando a instalação

Ao executar como root ./unbound_kindns.sh <hostname>, verá a tela do instalador abaixo onde fará todo o processo de baixar imagens, compilar os programas e criar os containers. Sim o Unbound que o projeto utiliza é o latest do próprio desenvolvedor NLnet Labs.

Tudo ocorrendo bem veremos a mensagem de Installation finished. Na sequência veremos sobre a administração do sistema.

Administrando o sistema

Unbound

Os arquivos de configuração do Unbound encontram-se em /var/lib/docker/volumes/unbound_config/_data/unbound.conf.d/. Nele existem 2 arquivos que precisam de atenção:

• controle-acesso.conf: esse contém as ACLs que liberam as consultas ao Unbound. Sugiro como fortalecimento da segurança, criar filtros Netfilter/IPTables ou Netfilter/NFTables para restringir os acessos.
• local.conf: esse é o principal arquivo de configuração do Unbound. Dê uma lida nesse outro artigo meu, para entender alguns parâmetros importantes.

Como checar se existem erros de syntax:

• docker exec -it unbound unbound-checkconf /etc/unbound/unbound.conf

Para recarregar as configurações sem zerar o cache e se não estiverem relacionadas com as interfaces:

• docker exec -it unbound unbound-control reload_keep_cache

Para reiniciar o serviço:

• cd /usr/local/src/unbound && docker compose restart unbound

FRRouting

Os dois arquivos de configuração são:

• /var/lib/docker/volumes/frr_config/_data/frr.conf
• /var/lib/docker/volumes/frr_config/_data/daemons

Para acessar o vtysh console:

• docker exec -it frr vtysh

Para reiniciar o serviço:

• cd /usr/local/src/frr && docker compose restart frr

Chrony (NTP/NTS)

Os arquivos de configuração são esses:

• /var/lib/docker/volumes/chrony_config/_data/chrony.conf: configuração principal do Chrony.
• /var/lib/docker/volumes/chrony_config/_data/conf.d/ntp_acl.conf: ACLs para permitir quais dispositivos podem se conectar ao serviço NTP/NTS.
• /var/lib/docker/volumes/chrony_config/_data/sources.d/nic.sources: contém os servidores NTP/NTS, nesse caso os do NIC.br.

Para reiniciar o serviço:

• cd /usr/local/src/chrony && docker compose restart chrony

Zabbix Agent 2

Arquivo de configuração:

• /var/lib/docker/volumes/zabbix_agent2_config/_data/zabbix_agent2.conf

Para reiniciar o serviço:

• cd /usr/local/src/zabbix-agent2 && docker compose restart zabbix-agent2

Para checar se os serviços estão up:

# docker ps
CONTAINER ID   IMAGE                                    COMMAND                  CREATED       STATUS       PORTS     NAMES
72a2448e4cf9   zabbix/zabbix-agent2:alpine-7.0-latest   "/usr/bin/docker-ent…"   4 hours ago   Up 4 hours             zabbix-agent2
ebb255934eee   unbound-unbound                          "/entrypoint.sh /usr…"   4 hours ago   Up 4 hours             unbound
88a0b5138f0d   quay.io/frrouting/frr:10.0.1             "/sbin/tini -- /usr/…"   4 hours ago   Up 4 hours             frr
6341b52b85e1   chrony-chrony                            "/usr/sbin/chronyd -…"   4 hours ago   Up 4 hours             chrony

Atualizando os serviços

Caso queria reinstalar ou atualizar os serviços siga os exemplos abaixo:

Unbound

cd /usr/local/src/unbound
docker compose down
docker compose up -d --build

Zabbix Agent 2

Edit as variáveis se for necessário em /etc/environment primeiro:

cd /usr/local/src/zabbix-agent2
docker compose pull             
docker compose down
docker compose up -d            

FRRouting (OSPFv2 e OSPFv3)

cd /usr/local/src/frr
docker compose pull              
docker compose down
docker compose up -d

Chrony

cd /usr/local/src/chrony
docker compose down
docker compose up -d --build

Validações e testes

Unbound

Teste de recursividade:

dig @127.0.0.1 google.com
dig @::1 google.com

Inspecionando flags e versão do Unbound:

docker exec -it unbound unbound -V

Logs ficam localizados aqui:

• /var/log/unbound/unbound.log

FRRouting

Consultando o OSPF:

# Show active OSPFv2 (IPv4) neighbors
docker exec -it frr vtysh -c "show ip ospf neighbor"

# Show active OSPFv3 (IPv6) neighbors
docker exec -it frr vtysh -c "show ipv6 ospf6 neighbor"

# Show routes learned via OSPF
docker exec -it frr vtysh -c "show ip route ospf"

Chrony

Checando o serviço:

# Clock synchronization status
docker exec -it chrony chronyc tracking

# Active NTP servers and sources
docker exec -it chrony chronyc sources -v

Zabbix Agent 2

Para validar o serviço:

# Test the agent directly from inside the container (Expected output: agent.ping [s|1])
docker exec -it zabbix-agent2 zabbix_agent2 -t agent.ping

# Verify if port 10050 is open/listening on the host using netcat (Expected: Connection to ... succeeded!)
nc -zv 127.0.0.1 10050
nc -zv ::1 10050

Configurações pós instalação

Em /etc/crontab existe a seguinte linha comentada:

#*/5 * * * *     root    /root/scripts/unboundSend.sh <ZBX_SERVER> <ZBX_HOSTNAME> 1> /dev/null

A linha acima após descomentada e reiniciado o cron, executa o script unboundSend.sh que de 5 em 5 minutos envia as estatísticas do Unbound para o Zabbix Server. O template para o Zabbix Server pode ser baixado aqui.

Se você optou por um DNS Recursivo Anycast, existe um arquivo em /etc/cron.d/ chamado teste_dns. Dentro dele tem uma chamada para o script /root/scripts/teste_dns.sh mas ela está comentada. Esse script testa se existe algum problema de recursividade no DNS e se tiver, ele desliga o FRR parando de anunciar os IPs que estão na loopback do host até que o problema seja resolvido. Isso faz com que os assinantes deste servidor migrem suas consultas para o próximo DNS Recursivo Anycast mais próximo. O frr.conf já vem com uma configuração genérica esqueleto e precisa ser adaptada para sua rede. Abaixo a atenção:

# Precisa ser alterado o md5
ip ospf message-digest-key 5 md5 Cu3Xhmf2

# Alterar o router-id nos dois blocos abaixo
router ospf
 ospf router-id 172.20.24.14
 area 0 authentication message-digest
exit
!
router ospf6
 ospf6 router-id 172.20.24.14
exit

Apoie este projeto

Se este projeto foi útil para você e deseja contribuir com seu desenvolvimento, considere fazer uma doação.

A ISPFocus possui um sistema de administração para servidores DNS Recursivos Anycast deste projeto. Como por exemplo o RPZ Manager que ajuda o administrador e o suporte, para inclusão, exclusão e consulta de bloqueios de domínios provenientes dos Ofícios Jurídicos e Anatel. Os bloqueios de domínios são replicados automaticamente para todos os servidores da rede através do RPZ Manager. Gostaria de saber mais? Entre em contato por e-mail: [email protected] ou por WhatsApp (22)99743-9060.

❤️ Apoie este projeto UNBOUND-KINDNS

Este projeto é desenvolvido e mantido no meu tempo livre.

Se ele foi útil para você, considere fazer uma contribuição para ajudar a manter o desenvolvimento ativo — e o meu estoque de café em dia. ☕

💙 Contribuir via PayPal