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

Apoie este projeto

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

❤️ Apoie este projeto

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 estoque de café em dia. ☕

💙 Contribuir via PayPal