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

De ISPUP!
Ir para navegação Ir para pesquisar
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]]
[[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


== 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 o '''KINDNS''' da '''ICANN''', descritos [https://kindns.org/shared-private-resolvers/ '''aqui''']. Para diminuir a curva de implementação 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. Vamos fazer um check list rápido:


* 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.
Linha 12: Linha 12:
* 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 ==
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.
{{ORDENACAOPADRAO:UNBOUND-KINDNS}}
{{ORDENACAOPADRAO:UNBOUND-KINDNS}}

Edição das 21h37min de 5 de julho de 2026

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

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. Vamos fazer um check list rápido:

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