Introdução ao PDNS
PDNS é um produto para gerenciamento de DNS, tanto autoritativo quanto recursivo.
Modalidades de Uso
O produto é implantado em duas modalidades: Cloud e OnPremise
Na modalidade Cloud, cada cliente recebe uma conta Revendedor, a partir da qual pode cadastrar logins administrativos para criar Empresas e, dentro delas, Zonas DNS.
No modo OnPremise, o cliente recebe uma conta de SuperAdministrador, e tem a possibilidade adicional de criar Revendedores, que, por sua vez, podem criar Empresas e estas podem criar Zonas.
Ambos esquemas seguem o conceito de Multi-tenancy, que permite uma granularidade de permissões e delegação de responsabilidades.
Em ambos casos, há uma interface web HTTPS, uma API HTTPS e, no mínimo, dois servidores autoritativos com Bind9, além de, opcionalmente, um ou mais servidores recursivos ou resolvedores Bind9.
Requisitos OnPremise
Para implantar uma instalação OnPremise, são necessárias máquinas virtuais ou físicas com
RedHat9 com pacote Fedora ISC |
Ubuntu22 com pacote ISC |
Debian12 com pacote nativo 9.18.24 |
Desta forma, garantimos versões de
ISC Bind 9.18.24 ou superior |
Python 3.9 ou superior |
MariaDB 10.5 ou superior, |
assim como kernels com capacidade criptográfica moderna, por exemplo, excluindo protocolos obsoletos como SHA1 e garantindo o uso de SHA256 como padrão.
As máquinas virtuais podem ser KVM do Openstack ou Proxmox, VMWare ou VirtualBox.
Obviamente, é possível utilizar servidores virtuais de Clouds Públicos como AWS, Google Cloud Platform, Azure, Linode, etc.
Aviso
A versão do Bind utilizada pelo PDNS a partir de setembro de 2022 é a 9.16.33, que corrige CVE-2022-2906, CVE-2022-3080, CVE-2022-38177 e CVE-2022-38178. No entanto, a partir de fevereiro de 2024, utilizamos a versão 9.18.24, que corrige o Keytrap, o exploit de resolvers que reconhecem DNSSEC (CVE-2023-50387).
Servidores Recursivos
A implantação de servidores recursivos ou Resolvers é realizada também OnPremise, no Cloud da Planisys ou em outros Clouds Públicos, com os mesmos requisitos em termos de sistemas operacionais.
No caso dos Resolvers, são utilizados um ou mais Load-Balancers que balanceiam o tráfego em servidores recursivos por meio de UDP e TCP, permitindo protocolos como DNS-over-HTTPS e DNS-over-TLS, e balanceando de acordo com a distribuição de carga medida em QPS ou Consultas por Segundo distribuídas entre os Resolvers.
Aviso
É importante observar que, embora DoH e DoT sejam protocolos que melhoram a privacidade de navegação em redes públicas expostas (por exemplo, WIFI público), eles também podem ser perigosos em vírus polimórficos que realizam consultas DNS para executar funções de Command & Control em uma organização. A implementação do DoH e DoT deve ser feita no âmbito de uma política de Cibersegurança com avaliação de riscos ou Risk Assessment. O risco reside em fornecer ao malware um meio de se camuflar no tráfego legítimo.
Nota
Recomenda-se o uso de DNS-over-HTTPS e DNS-over-TLS em laptops/portáteis, tablets e dispositivos móveis corporativos que operem fora do ambiente corporativo.
Se recomenda o uso de opções no resolv.conf para minimizar os timeouts e permitir a distribuição round-robin entre os LBs ao implantar mais de um Load-Balancer.
A instalação de RPZ ou Response Policy Zones com mais de 500 mil domínios maliciosos como parte de um Feed zero-day é um produto opcional que funciona como Proteção de Endpoint.
No entanto, pode-se configurar uma lista de domínios para os quais o Load-Balancer forneça uma resposta negativa direta como parte do produto PDNS.
Outra possibilidade opcional dentro do PDNS é fornecer uma Blackhole Landing, que é uma página da web onde o navegador é redirecionado ao resolver certos domínios fornecidos manualmente pelo cliente através da web do PDNS para incluí-los no RPZ. Esta solução é útil como Proteção de Endpoint para navegação segura, por exemplo, para capturar links maliciosos enviados por SMS, WhatsApp, e-mails ou sites. Sua eficácia foi comprovada em ataques massivos de SMS contra grandes corporações para minimizar o impacto.
Funções de usuários
Existem quatro funções possíveis:
Superadministrador |
Administrador de Revendedor |
Operador de Revendedor |
Operador de Empresa |
O superadministrador pode criar, excluir e modificar qualquer um dos usuários com funções inferiores, mas não pode modificar ou excluir outros superadministradores.
Conjuntos NS e Servidores Autoritativos
Um conjunto NS é um conjunto de servidores autoritativos que compartilham uma chave TSIG SHA-256 para a transferência de zonas de um servidor primário para servidores secundários. Todo domínio é delegado a um conjunto de servidores autoritativos, para os quais são declarados registros NS dentro da mesma zona.
O servidor primário possui um pipeline CI/CD que reflete instantaneamente as alterações feitas por meio da interface WEB ou API nas zonas, na lista de zonas ou nas configurações de ACLs para permitir transferências de zonas, e notifica os servidores secundários sobre mudanças nos registros da zona usando o protocolo DNS NOTIFY.
Os servidores secundários também possuem um pipeline CI/CD similar, para reconfigurar-se automaticamente caso ocorram alterações na lista de zonas ou nos direitos de transferência de ACL.
Os direitos de transferência de zona, no caso de zonas do tipo Master (ou seja, delegadas a um conjunto NS), são definidos usando uma chave TSIG em vez de apenas endereços IP, como medida anti-spoofing, pois a zona é transferida com uma assinatura ou hash que utiliza a chave TSIG.
Ao declarar um servidor autoritativo de uma zona, devemos garantir que ele esteja registrado na ICANN. Para isso, acessamos a página https://webwhois.verisign.com/webwhois-ui/index.jsp?language=en_US# e introduzimos o nome do servidor de nomes ao qual queremos delegar um domínio.
Se o servidor de nomes que desejamos usar não for considerado válido, devemos declarar seu nome e endereço IP no Registrar onde o domínio foi comprado, por exemplo, GoDaddy, Gandi, Verisign, etc.
Se desejarmos delegar um domínio, por exemplo, xyzabc.com, para servidores de nomes dns1.xyzabc.com e dns2.xyzabc.com, esses servidores são conhecidos como Glue Records porque pertencem ao mesmo domínio para o qual são servidores autoritativos. Naturalmente, eles devem ser declarados no Registrar antes da delegação do domínio.
O usuário deve verificar, antes de configurar um conjunto NS ou lista de servidores autoritativos, se eles estão declarados na ICANN; caso contrário, ocorrerá um erro ao tentar resolver a zona. Embora o PDNS permita definir servidores autoritativos, ele não possui como verificar se esses servidores estão registrados na ICANN.
ACLs
Uma Lista de Controle de Acesso (ACL) é uma lista de blocos CIDR ou endereços IP (IPv4 ou IPv6) e, eventualmente, chaves TSIG, aplicadas como permissões para que uma zona sob nossa administração possa ser transferida para um servidor externo.
A ação de transferência é conhecida como AXFR e, por padrão, é completamente negada, sendo necessário definir uma lista de condições de autenticação.
O objetivo de uma ACL é aplicá-la a uma zona para permitir que ela seja transferida para um servidor externo à nossa rede, por exemplo, se um cliente precisar manter uma cópia de suas zonas em seus próprios servidores.
Esse caso ocorre quando um domínio é marcado como permitido para transferência, caso em que é obrigatório atribuir uma ACL para definir as permissões de transferência. As «permissões de transferência» são requisitos que o servidor solicitante deve cumprir (deve haver uma correspondência no endereço IPv4, IPv6, ou na chave TSIG, que geralmente é um hash gerado via SHA256).
Se você quiser marcar um grande número de domínios como permitidos para transferência com uma ACL, é mais conveniente usar a API do PDNS em vez de fazer isso pela interface Web.
Zonas Reversas vs. Zonas Diretas
Uma zona reversa é uma zona que possui registros do tipo PTR para especificar reversos de endereços IP tanto IPv4 quanto IPv6. Durante o cadastro via web, é especificado o bloco desejado no formato CIDR, e o PDNS o traduz para o formato in-addr.arpa. Zonas reversas também exigem registros SOA (Start-Of-Authority) e NS (Nameserver).
Uma zona direta pode conter, além dos obrigatórios SOA e NS, registros do tipo CAA, SRV, A, AAAA, TXT, CNAME, ALIAS ou DNAME (semelhante ao CNAME, mas permitido no topo ou Apex da zona, resolvido por um Resolver) e MX.
Esses registros são conhecidos como RRs ou Resource Records.
Zonas DNSSEC
PDNS suporta DNSSEC e permite obter pela web as informações necessárias para fornecer ao domínio pai um registro DS com os elementos vinculados ao registro DNSKEY para estabelecer uma cadeia de confiança verificada entre pai e filho (Chain of Trust):
Domínio |
Algoritmo (por exemplo, ECDSAP256SHA256) |
Algoritmo de Hash (tipicamente SHA256) |
Hash |
KeyTag |
Esses são os dados que um Registrador normalmente solicita quando compramos um domínio e queremos que ele tenha DNSSEC, pois é necessário publicar um registro DNSKEY contendo a chave pública que assina a zona, e o registro DS que vai na zona pai deve conter um hash dessa chave pública. Isso é conhecido como Chain of Trust ou Cadeia de Confiança.
Quando uma zona é marcada como DNSSEC, o PDNS cria automaticamente um par de chaves (pública e privada), armazenando a chave privada de forma segura e publicando a chave pública no registro DNSKEY. Isso é conhecido como ZSK ou Zone-Signing-Key.
Os resolvedores, ao resolver registros de uma zona DNSSEC, verificam a autenticidade dos registros obtidos utilizando a chave pública do registro DNSKEY. O servidor autoritativo primário, ao adicionar ou alterar registros (Resource Records), assina o registro utilizando a chave privada da ZSK.
Nota
DNSSEC utiliza criptografia de chave pública (PKC) para verificar a autenticidade dos dados (verificar o emissor) e a integridade deles (garantindo que não foram alterados durante o transporte pela Internet). No entanto, isso não garante privacidade, pois os registros DNS consultados são transportados em texto claro, a menos que sejam utilizados protocolos como DNS-over-TLS ou DNS-over-HTTP.
Cadeia de Confiança
O processo que ocorre quando, por exemplo, queremos acessar um site da web a partir de um PC, Mac, celular ou tablet, é que precisamos de um DNS Resolver para traduzir um nome, como www.planisys.com, para u
Para que o resolvedor não seja envenenado por um invasor malicioso (Cache Poisoning) ao tentar obter o endereço IP de www.planisys.com, é estabelecida uma cadeia de confiança por meio de registros autenticados de delegação com DNSSEC, que permite chegar a um dos servidores autoritativos do domínio planisys.com e obter a resposta correta.
Os Resolvers fornecidos pelo PDNS têm a validação DNSSEC ativada para verificar a Cadeia de Confiança.
Idiomas
Atualmente, a interface web do PDNS está disponível em espanhol, inglês e português. O idioma pode ser alterado em Configurações clicando no ícone no canto superior direito.
Última atualização em 2024-10-30