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.
Como fazer forward para o IP da nuvem da Planisys com o unbound
Se você já possui um ou mais servidores unbound em sua nuvem própria (on-premise) e deseja encaminhar todas as consultas que não estejam no cache do unbound, realize a seguinte configuração no unbound:
server:
interface: 0.0.0.0 # listen on all interfaces
access-control: 0.0.0.0/0 allow # or restrict to your network
# Forwardear todos los DNS queries que no estén en caché a través de Planisys
forward-zone:
name: "."
forward-addr: <PLANISYS_IP>
Nota
las direcciones IP cliente logueadas, serán las de los servidores unbound, perdiéndose el rastro de cual es la verdadera IP cliente
Requisitos OnPremise
Para implantar uma instalação OnPremise, são necessárias máquinas virtuais ou físicas com
Debian12 con paquete 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).
Nota
El motivo por el que utilizamos la distribución Bind9 de Debian12 (o a partir de noviembre 2025 Debian13 Trixie), es porque es la versión OFICIAL de Internet Software Consortium , la empresa con la cual colabora Planisys para el desarrollo de bind9 y es la que contiene DNSTAP lo que nos permite realizar Log Shipping
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.
Aviso
Todas las instalaciones deberán contar con un certificado SSL para el TLS, que es parte de la instalacion. El mantenimiento (reemplazo del certificado) correrá a cargo del Operador que deberá realizar un rndc reconfig y rndc reload despues del cambio En caso de existir sobrecarga se deberá realizar systemctl restart named lo que provocará una interrupción temporaria del servicio. Se recomienda realizar estos cambios en ventana de mantenimiento.
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.
Delegação de zonas
A delegação de um domínio que está sob um TLD (como, por exemplo, .com, .co ou .ar), assim como as delegações de sub-TLDs (como com.ar), deve ser feita no registrador correspondente. O mesmo vale para reversos, por exemplo, acessando www.lacnic.net para delegar aos nameservers responsáveis pela resolução reversa.
Os registros NS não podem apontar para um CNAME
No sistema de nomes de domínio (DNS), os registros NS (Name Server) são fundamentais para a delegação de um domínio, pois indicam quais servidores são responsáveis por responder consultas sobre uma determinada zona. No entanto, de acordo com os padrões do DNS, um registro NS nunca deve apontar para um CNAME (alias).
Isso é proibido pelas especificações RFC 1912 (Seção 2.4) e RFC 2181 (Seção 10.3), devido aos problemas de resolução que isso pode causar.
RFC 2181 (Seção 10.3)
Por que essa configuração não é permitida?
As delegações devem ser diretas
Um registro NS deve sempre apontar para um nome de host com um registro A ou AAAA, nunca para um CNAME.
Risco de resolução em loop
Alguns resolvedores não seguem CNAMEs em delegações de NS, o que pode fazer com que o domínio se torne irresolvível.
Inconsistência entre a delegação do TLD e a resolução final
O TLD delega para um NS que, em seguida, é um CNAME, o que gera discrepâncias e pode fazer com que alguns usuários não consigam resolver o domínio corretamente.
O uso de CNAME em registros NS é um erro grave e deve ser evitado. Sempre que um servidor de nomes for configurado, deve-se garantir que os registros NS apontem para nomes que tenham registros A ou AAAA válidos. Caso contrário, o domínio pode se tornar inacessível para alguns usuários e causar problemas de resolução em toda a infraestrutura de DNS.
Delegações incompletas ou lame delegations
Por outro lado, os servidores autoritativos para os quais uma zona é delegada conforme o registrador devem responder todos com pelo menos o mesmo conjunto de registros NS declarado no registrador. Dizemos pelo menos porque é possível adicionar servidores stealth nos autoritativos, ou seja, servidores adicionados que não constam no registrador.
Esses servidores stealth também devem respeitar que o conjunto de registros NS seja o mesmo que nos nameservers declarados. Embora não estejam registrados no registrador, os stealth servers devem manter a coerência na configuração de NS para evitar problemas.
Se algum servidor de nomes, seja declarado ou stealth, não responder com o conjunto completo de registros NS, temos uma lame delegation. Ou seja, uma consulta pode falhar dependendo dos resolvedores.
- Para que uma delegação seja válida, todos os servidores de nomes autoritativos de uma zona devem responder com o mesmo conjunto de registros NS que foi declarado no registrador do domínio. No entanto, ocorre uma lame delegation quando:
Um servidor autoritativo listado no registrador não responde corretamente ou não contém todos os registros NS esperados.
Um servidor stealth (autoridade adicional não listada no registrador) não mantém a coerência nos registros NS.
Um resolvedor obtém respostas inconsistentes dependendo de qual servidor responde, o que gera falhas intermitentes na resolução.
O mundo dos resolvedores
Quando se estabelecem regras como evitar lame delegation ou proibir CNAMEs nos registros NS, não se está pensando nos resolvedores públicos, mas sim nos centenas de milhões de CPEs ou roteadores ADSL ou de Fibra que executam um resolvedor e aderem às RFCs.
Muchas veces los Resolvers Públicos no adhieren a las RFCs como las nombradas anteriormente, para facilitar la resolución a quien consulte específicamente. Pero tienen el lado negativo de ocultar problemas de delegación. Esto puede ocultar problemas reales y dar la falsa sensación de que un dominio funciona correctamente, cuando en realidad tiene errores de configuración
Este problema no solo afecta a resolvers pequeños, sino también a entornos corporativos y proveedores de Internet que implementan resolvers más estrictos.
Recomendações para Evitar Lame Delegations
- Para garantir uma delegação correta e evitar problemas de resolução, é fundamental:
Manter a coerência nos registros NS:
- Todos os servidores de nomes devem retornar o mesmo conjunto de registros NS, tanto os declarados no registrador quanto os stealth.
Verificar a delegação com ferramentas DNS:
- Recomenda-se usar ferramentas como dig, nslookup ou dnsviz.net para detectar discrepâncias na delegação.
Evitar servidores stealth mal configurados:
- Se forem adicionados servidores stealth, certifique-se de que eles reflitam exatamente as mesmas informações que os servidores listados no registrador.
Fazer testes com diferentes resolvers:
Não confie apenas em resolvers públicos. Teste com resolvers de diferentes ISPs e ambientes corporativos para detectar possíveis falhas.
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 2025-07-14