Introdução ao PDNS
PDNS é um produto para gerenciamento de DNS, tanto autoritativo quanto recursivo.
Modalidades de Uso
El producto se despliega en dos modalidades: Cloud y OnPremise
Na modalidade Cloud, cada cliente recebe uma conta Revendedora ou Revenda, a partir da qual pode cadastrar logins administrativos onde poderá 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 os esquemas obedecem ao conceito de Multi-tenancy que permite uma granularidade de permissões e delegação de responsabilidades.
Em ambos os casos, há uma interface da Web HTTPS, uma API HTTPS e pelo menos dois servidores com Bind9 autoritativo e, opcionalmente, um ou mais servidores Bind9 recursivos ou resolvedores.
Requisitos OnPremise
Para implantar uma instalação no local, são necessárias máquinas virtuais ou físicas com os seguintes sistemas operacionais
RedHat9 con paquete Fedora ISC |
Ubuntu22 con paquete ISC |
Debian12 con paquete nativo 9.18.24 |
Desta forma, garantimos as seguintes versões de software base
ISC Bind 9.18.24 o superior |
Python 3.9 o superior |
MariaDB 10.5 o superior, |
bem como kernels com capacidade criptográfica moderna, por exemplo excluindo protocolos obsoletos como SHA1, garantindo o uso de sha256 por padrão.
As máquinas virtuais podem ser KVM da Openstack ou Proxmox, VMWare ou VirtualBox.
Obviamente se pueden utilizar servidores virtuales de Clouds Publicos como AWS, Google Cloud Platform, Azure, Linode, etc
Aviso
La version de Bind a partir de setiembre 2022 utilizada por PDNS es 9.16.33, que corrige CVE-2022-2906, CVE-2022-3080, CVE-2022-38177 y CVE-2022-38178.
Sin embargo, a partir de Febrero 2024, utilizamos la versión 9.18.24 que corrige Keytrap, el exploit de resolvers que reconocen DNSSEC (CVE-2023-50387)
Servidores Recursivos
El despliegue de servidores recursivos o Resolvers se realiza tambien OnPremise, en el Cloud de Planisys, o en otros Clouds Publicos, con los mismos requerimientos en cuanto a sistemas operativos.
En el caso de Resolvers, se utiliza uno o mas Load-Balancers que balancean trafico sobre servidores recursivos en UDP y TCP, permitiendo protocolos como DNS-over-HTTPS y DNS-over-TLS, y balanceando de acuerdo a la distribucion de carga medida en QPS o Queries-Por-Segundo distribuidos entre los Resolvers.
Aviso
Debe notarse sin embargo que si bien DoH y DoT son protocolos que mejoran la privacidad de navegacion en redes publicas expuestas (p.ej. Wifi publico), tambien puede resultar peligroso en virus polimorficos que dentro de una organizacion realizan consultas via DNS para ejecutar funciones de Command & Control. El despliegue de los protocolos DoH y DoT debe realizarse en el marco de una politica de Ciberseguridad con evaluacion de riesgo o Risk Assessment. El riesgo consiste en proveer a un malware de un medio para camuflarse y mezclarse con trafico legitimo.
Nota
Se recomienda el uso de DNS-over-HTTPS y DNS-over-TLS en laptops/portatiles/tables/moviles corporativos que operen fisicamente fuera del entorno corporativo
En caso de realizar un despliegue de mas de un Load-Balancer, se recomienda utilizar opciones de resolv.conf para minimizar los timeouts y permitir distribucion round-robin entre los LBs.
La instalacion de RPZ o Response Policy Zones con mas de 500k dominios maliciosos como parte de Feed zero-day es un producto opcional que opera como Endpoint Protection.
Sin embargo, se puede configurar una lista de dominios para los que el Load-Balancer de una respuesta negativa directa, como parte del producto PDNS.
Otra posibilidad opcional dentro de PDNS, es proveer una Blackhole Landing, que es una pagina web en la cual se «aterriza» con el navegador web, al resolver ciertos dominios provistos por el cliente de forma manual via la web de PDNS, para incluirlos en RPZ. Este producto opcional, es util como Endpoint Protection para la navegacion, p.ej. para atrapar links maliciosos enviados por SMS o Whatsapp o e-mails o mismo dentro de una web. Se ha probado su efectividad en ataques masivos de SMS a grandes corporaciones para minimizar el impacto.
Funções do usuário
Existem quatro funções possíveis:
Superadministrador |
Administrador do Revendedor |
Operador do Revendedor |
Operador de Compañía |
El Superadministrador puede crear, borrar y modificar a cualquiera de los usuarios con roles inferiores, pero no puede modificar ni borrar otros superadministradores.
NS-Sets y Nameservers Autoritativos
Un NS-Set es un conjunto de servidores autoritativos que comparten una llave TSIG SHA-256 para la transferencia de zonas desde un primario a los secundarios. Todo dominio es delegado a un conjuntos de autoritativos, para los cuales se declaran , dentro de la misma zona, registros NS.
El servidor primario dispone de un pipeline CI/CD que refleja instantáneamente los cambios hechos via WEB o API en las zonas, en la lista de zonas, o en configuraciones de ACLs para permitir zone-transfers y avisa a los servidores secundarios si hay cambios en los registros de zona via el protocolo DNS NOTIFY.
Los servidores secundarios también disponen de un pipeline CI/CD similar, para eventualmente reconfigurar si es que hubieran cambios en la lista de zonas o en los permisos ACL de transferencia.
Los permisos de transferencia de zona, cuando se trata de zonas de tipo Master (es decir, que están delegadas a un NS-SET) se establecen a partir de un secret TSIG aparte de IPs como medida anti-spoofing, porque ademas la zona se transfiere con una firma o hash que utiliza la key TSIG.
Cuando declaramos un servidor autoritativo de una zona, debemos asegurarnos que este registrado en ICANN. Para esto consultamos la pagina web https://webwhois.verisign.com/webwhois-ui/index.jsp?language=en_US# e introducimos el nombre del nameserver al cual queremos delegar un dominio.
En caso de no figurar como valido el nameserver que queremos utilizar, debemos declarar nombre y direccion IP del mismo en el Registrar en donde se ha comprado el dominio, p.ej. Godaddy, Gandi, Verisign, etc.
En caso de querer delegar un dominio p.ej. xyzabc.com a nameservers dns1.xyzabc.com y dns2.xyzabc.com , dichos nameservers se los conoce como Glue Records porque pertenecen al mismo dominio para el cual sirven de autoritativos. Por supuesto se los debe declarar en el Registrar previo a delegar el dominio a ellos.
El usuario debe verificar, antes de armar un NS-SET o lista de autoritativos, que los mismos esten declarados en ICANN, de lo contrario se generara una falla al momento de tratar de resolver la zona. Si bien PDNS permite definir autoritativos, no tiene modo de verificar que los mismos esten declarados en ICANN.
ACLs
Una Access Control List es una lista de bloques CIDR o direcciones IP (ipv4 o ipv6), y eventualmente llaves TSIG, para aplicar como permisos para que una zona que esta bajo nuestra administracion, pueda sea transferida a un servidor externo.
La accion de transferencia es conocida como AXFR, y por default esta completamente denegada, de modo que se deben explicitar una lista de condiciones de autenticacion.
El objetivo de una ACL es aplicarsela a una zona para permitir que se transfiera a un servidor externo a nuestras redes, como p.ej. si un cliente requiere tener una copia de sus zonas en sus propios servidores.
Este caso se da cuando un dominio se marca como permitido de transferir , en cuyo caso es obligatorio asignarle una ACL para determinar cuales son los permisos de transferencia. Los «permisos de transferencia» son requisitos que debe cumplir el servidor que pide el contenido de una zona (debe haber un match en la direccion ipv4 o en la direccion ipv6 o en la llave TSIG que normalmente es un hash generado via SHA256).
En caso de querer marcar masivamente una gran cantidad de dominios como permitidos de transferir con una ACL, es mas conveniente utilizar la API de PDNS en vez de hacerlo por interfaz Web.
Zonas reversas x zonas diretas
Uma zona reversa é uma zona que possui registros do tipo PTR para especificar endereços IP reversos para IPv4 e IPv6.Durante o registro via web, o bloco para o qual você deseja é especificadoreverso no formato CIDR e o PDNS o traduz para no formatoaddr.arpa. Zonas reversas também precisam ser obrigatórias Requer registros SOA (Start-Of-Authority) e NS (Nameserver).
Una zona directa, puede contener además de los obligatorios SOA y NS, registros de tipo CAA, SRV, A, AAAA, TXT, CNAME, ALIAS o DNAME (similar a CNAME pero permitido en el tope o Apex de la zona, lo termina de resolver un Resolver) y MX.
Esses registros são conhecidos como RRs ou Resource Records.
Zonas DNSSEC
PDNS suporta DNSSEC e permite que informações sejam obtidas via webnecessário fornecer ao domínio pai um registro DS com a itens vinculados ao registro DNSKEY para ter uma string de herança verificada pai/filho (cadeia de confiança):
Domain |
Algorithm (p.ej. ECDSAP256SHA256) |
Hash Algorithm (tipicamente SHA256) |
Hash |
KeyTag |
Estes são os dados que um Registrador normalmente pede quando compramosum domínio e queremos que ele tenha DNSSEC , pois um » deve ser publicadRegistro DNSKEY contendo a chave pública que assina a zona, e o Registro DS que vai na zona pai, deve conter um hash do dito chave pública. Isso é conhecido como Chain of Trust ou Chain of Confiar.
Ao marcar uma zona como DNSSEC , o PDNS cria automaticamente um parde chaves (públicas e privadas), mantendo o privado de forma segura, e publicando o público no registro DNSKEY. Isso é o que se sabe como ZSK ou chave de assinatura de zona.
Resolvedores, ao resolver registros para uma zona DNSSEC, marque a autenticidade dos registros obtidos usando a chave pública do DNSKEY. O servidor autoritativo primário, antes de cada adição ou alterar registros (Registros de Recursos), assine o registro usando a chave privada do ZSK.
Nota
DNSSEC utiliza criptografia de clave publica o PKC para verificar la autenticidad de los datos (verificar el emisor) y la integridad de los mismos (no fueron modificados al ser transportados por el Internet).
Sin embargo, no se debe confundir esto con privacidad , ya que los registros DNS consultados son transportados en claro, a menos que se utilicen protocolos de consulta como DNS-over-TLS o DNS-over-HTTP.
Cadena de Confianza
El proceso que ocurre cuando p.ej. queremos acceder a un sitio web desde una PC o Mac o Celular o Tablet, es que precisamos de un DNS Resolver para poder traducir un nombre p.ej. www.planisys.com a una direccion IP (ipv4 o ipv6, dependiendo de la red donde este nuestro dispositivo).
Para que el resolver , al querer obtener la direccion IP de www.planisys.com, no sea envenenado por un atacante malicioso (Cache Poisoning) es que se establece una cadena de confianza por medio de registros autenticados de delegacion mediante DNSSEC, para poder llegar a alguno de los servidores autoritativos del dominio planisys.com que nos dara la respuesta correcta.
Los Resolvers provistos por PDNS, tienen activada la validacion DNSSEC para poder verificar la Cadena de Confianza.
Idiomas
Actualmente la interfaz web PDNS esta disponible en castellano, ingles y portugues. Se accede al cambio de lenguaje en Settings al hacer click en el icono de la derecha arriba.
Última atualização 2024-04-20