Unbound-kindns: mudanças entre as edições

De ISPUP!
Ir para navegação Ir para pesquisar
← Edição anteriorEdição posterior →

Gondim (discussão | contribs)

3 grupos de usuário
1 152 edições
VisualWikitexto
Sem resumo de edição
Sem resumo de edição
Linha 1: Linha 1:
{{EXIBETITULO:UNBOUND-KINDNS}}
{{EXIBETITULO:UNBOUND-KINDNS}}
[[Arquivo:Unbound-kindns01.png|nenhum|miniaturadaimagem|825x825px]]https://www.paypal.com/donate/?business=7LD8SPXNF2KH2&no_recurring=0&item_name=Sua+contribui%C3%A7%C3%A3o+ajuda+a+manter+meu+estoque+de+caf%C3%A9+em+dia+%3A%29&currency_code=BRL
[[Arquivo:Unbound-kindns01.png|nenhum|miniaturadaimagem|825x825px]]
 
== Introdução ==
== 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 [https://kindns.org/shared-private-resolvers/ '''aqui''']. Para diminuir a curva de dificuldade entre instalação e configuração, criei um projeto no '''GitHub''' chamado '''[https://github.com/gondimcodes/unbound-kindns UNBOUND-KINDNS].''' O projeto tem como objetivo facilitar a instalação de um sistema, para atender as 7 práticas do KINDNS. Vamos fazer um check list rápido:
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 [https://kindns.org/shared-private-resolvers/ '''aqui''']. Para diminuir a curva de dificuldade entre instalação e configuração, criei um projeto no '''GitHub''' chamado '''[https://github.com/gondimcodes/unbound-kindns 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 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 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 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 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 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 '''[https://github.com/gondimcodes/template_zabbix_dns_unbound aqui]'''.
* '''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 '''[https://github.com/gondimcodes/template_zabbix_dns_unbound 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.  
* '''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 ==
== Requisitos ==
O script de instalação 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.
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 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:
 
* <code>CORES</code>: Número de núcleos de CPU dedicados ao Unbound (define o parâmetro <code>num-threads</code> na configuração do Unbound; padrão: '''4''').
* <code>OSPF_INTERFACE</code>: Interface física de rede utilizada para o roteamento '''OSPF''' (por exemplo, <code>ens20</code>). Se deixado em branco, a implantação de '''OSPF/Anycast''' (container '''FRR''') será ignorada, executando o sistema em modo autônomo (stand-alone).
* <code>APPARMOR</code>: Defina como <code>0</code> para desabilitar o AppArmor e obter o máximo desempenho, ou como <code>1</code> para mantê-lo habilitado.
* <code>MITIGATIONS</code>: Defina como <code>off</code> para desabilitar as mitigações de CPU e obter o máximo desempenho, ou como <code>auto</code> para deixá-las no modo automático.
* <code>ZBX_HOSTNAME</code>: Identificador do host no servidor Zabbix. Se deixado em branco, o script utilizará o '''hostname''' do sistema.
* <code>CERT_DOMAIN</code>: 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: <code>doh.brasil.com.br</code>).
* <code>ZBX_SERVER_HOST</code>: Endereço IP do servidor Zabbix.
* <code>ZBX_SERVER_ACTIVE</code>: Endereço IP do servidor Zabbix ativo (Active Zabbix Server).
* <code>ZBX_LISTENIP</code>: Endereço IP de vinculação (binding) para o container do Zabbix Agent 2 escutar conexões (padrão: <code>0.0.0.0</code>).
 
== Executando a instalação ==
Ao executar '''./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'''.
[[Arquivo:Unbound-kindns02.png|nenhum|miniaturadaimagem|1046x1046px]]
Tudo ocorrendo bem veremos a mensagem de '''Installation finished'''. Na sequência veremos sobre a administração do sistema.
 
== Administrando o sistema ==


== Apoie este projeto ==
== Apoie este projeto ==

Edição das 22h31min de 5 de julho de 2026

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 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 ./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

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

Disponível em “https://wiki.ispup.com.br/w/index.php?title=Unbound-kindns&oldid=1155”