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 151 edições
VisualWikitexto
Sem resumo de edição
Sem resumo de edição
Linha 5: Linha 5:
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 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 1 - A validação DNSSEC deve estar obrigatoriamente habilitada nos resolvedores recursivos. 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 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 - QNAME minimization '''MUST''' be enabled to mitigate leakage of domain names. 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 - 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 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 - 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 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 - 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 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) 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.  
* 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.  
{{ORDENACAOPADRAO:UNBOUND-KINDNS}}
{{ORDENACAOPADRAO:UNBOUND-KINDNS}}

Edição das 21h10min 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 - 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.
Disponível em “https://wiki.ispup.com.br/w/index.php?title=Unbound-kindns&oldid=1150”