Unbound-kindns: mudanças entre as edições
Ir para navegação
Ir para pesquisar
Sem resumo de edição |
Sem resumo de edição |
||
| (4 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
| 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¤cy_code=BRL | |||
{{ORDENACAOPADRAO: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 [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 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 '''[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. | |||
== 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. | |||
== Apoie este projeto == | |||
Se este projeto foi útil para você e deseja contribuir com seu desenvolvimento, considere fazer uma doação. | |||
[https://www.paypal.com/donate/?hosted_button_id=7LD8SPXNF2KH2 ❤️ Doar via PayPal]{{ORDENACAOPADRAO:UNBOUND-KINDNS}} | |||
Edição atual tal como às 21h39min 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. 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.
Apoie este projeto
Se este projeto foi útil para você e deseja contribuir com seu desenvolvimento, considere fazer uma doação.