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 |
||
| (Uma revisão intermediária pelo mesmo usuário não está sendo mostrada) | |||
| Linha 1: | Linha 1: | ||
{{EXIBETITULO:UNBOUND-KINDNS}} | {{EXIBETITULO:UNBOUND-KINDNS}} | ||
[[Arquivo:Unbound-kindns01.png|nenhum|miniaturadaimagem|825x825px]] | |||
== 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: | |||
* Prática 1 - DNSSEC validation '''MUST''' be enabled for recursive resolvers. Unbound já atende por padrão. | |||
* Prática 2 - ACL statements '''MUST''' be used to restrict who may send recursive queries to your DNS resolvers/validators. Este projeto possui arquivos de ACLs para liberar apenas quem pode consultar seu DNS. | |||
* Prática 3 - QNAME minimization '''MUST''' be enabled to mitigate leakage of domain names. Este projeto encontra-se com QNAME minimization já ativo. | |||
* Prática 4 - Authoritative and recursive DNS service '''MUST NOT''' coexist on the same DNS server. Unbound não faz Autoritativo, então OK também. | |||
* Prática 5 - Your recursion services '''MUST''' have resilience by using at least two distinct servers that take diversity into consideration. Este projeto te permite configurar DNS(s) Primário e Secundário ou uma rede de DNS(s) Anycast. | |||
* Prática 6 - Monitoring of the services, servers, and network equipment that make up your DNS infrastructure '''MUST''' be implemented. 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) or DoH (DNS-over-HTTPS) '''SHOULD''' be enabled. Deploying either is the easiest way to protect against eavesdropping and manipulation of DNS queries and man-in-the-middle attacks by encrypting DNS queries between stub and recursive resolvers, or between a forwarding and recursive resolver. Aqui também o projeto entrega o sistema preparado para '''DoT''' e '''DoH''', só necessitando da configuração dos certificados TLS. | |||
{{ORDENACAOPADRAO:UNBOUND-KINDNS}} | {{ORDENACAOPADRAO:UNBOUND-KINDNS}} | ||
Edição das 20h00min 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 o KINDNS da ICANN, descritos aqui. Para diminuir a curva de implementação 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 - DNSSEC validation MUST be enabled for recursive resolvers. Unbound já atende por padrão.
- Prática 2 - ACL statements MUST be used to restrict who may send recursive queries to your DNS resolvers/validators. Este projeto possui arquivos de ACLs para liberar apenas quem pode consultar seu DNS.
- Prática 3 - QNAME minimization MUST be enabled to mitigate leakage of domain names. Este projeto encontra-se com QNAME minimization já ativo.
- Prática 4 - Authoritative and recursive DNS service MUST NOT coexist on the same DNS server. Unbound não faz Autoritativo, então OK também.
- Prática 5 - Your recursion services MUST have resilience by using at least two distinct servers that take diversity into consideration. Este projeto te permite configurar DNS(s) Primário e Secundário ou uma rede de DNS(s) Anycast.
- Prática 6 - Monitoring of the services, servers, and network equipment that make up your DNS infrastructure MUST be implemented. 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) or DoH (DNS-over-HTTPS) SHOULD be enabled. Deploying either is the easiest way to protect against eavesdropping and manipulation of DNS queries and man-in-the-middle attacks by encrypting DNS queries between stub and recursive resolvers, or between a forwarding and recursive resolver. Aqui também o projeto entrega o sistema preparado para DoT e DoH, só necessitando da configuração dos certificados TLS.