Introducción a PDNS
PDNS es un producto para administrar DNS, tanto autoritativo como recursivo.
Modalidades de Uso
El producto se despliega en dos modalidades: Cloud y OnPremise
En la modalidad Cloud, cada cliente recibe una cuenta de Reseller o Revendedor , desde la cual puede dar de alta logins administrativos en donde crear Compañías, y dentro de las mismas, Zonas DNS.
En la modalidad OnPremise, el cliente recibe una cuenta de SuperAdministrador , y tiene la capacidad adicional de crear Resellers , que a su vez pueden crear Compañías y éstas pueden crear Zonas.
Ambos esquemas se ajustan al concepto de Tenencia Múltiple o Multi-tenancy que premite una granularidad de permisos y delegación de responsabilidades.
En ambos casos se dispone de una interfaz Web HTTPS, una API HTTPS, y mínimo dos servidores con Bind9 autoritativos, y opcionalmente uno o más servidores Bind9 recursivos o resolvers.
Requisitos OnPremise
Para poder desplegar una instalación OnPremise, se requiere de Máquinas Virtuales o Físicas con
RedHat9 con paquete Fedora ISC |
Ubuntu22 con paquete ISC |
Debian12 con paquete nativo 9.18.24 |
De esta manera nos aseguramos versiones de
ISC Bind 9.18.24 o superior |
Python 3.9 o superior |
MariaDB 10.5 o superior, |
así como kernels con capacidad criptográfica moderna, p.ej. excluyendo protocolos deprecados como SHA1, o el uso de SHA256 como default.
Las máquinas virtuales pueden ser KVM de Openstack o Proxmox, VMWare o VirtualBox.
Obviamente se pueden utilizar servidores virtuales de Clouds Publicos como AWS, Google Cloud Platform, Azure, Linode, etc
Advertencia
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.
Advertencia
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.
Roles de usuarios
Existen 4 roles posibles:
Superadministrador |
Administrador de Revendedor |
Operador de 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 vs Zonas Directas
Una zona reversa, es una zona que tiene registros de tipo PTR para especificar reversos de direcciones IP tanto IPv4 como IPv6. Durante el alta via web, se especifica el bloque para el cual se quiere reverso en formato CIDR, y el PDNS lo traduce a formato in-addr.arpa. Las zonas reversas necesitan además obligatoriamente registros SOA (Start-Of-Authority obligatorio) y 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.
Estos registros se conocen como RRs o Resource Records.
Zonas DNSSEC
PDNS soporta DNSSEC y permite obtener via web la información necesaria para proveer al dominio padre de un registro DS con los items que enlazan al registro DNSKEY para tener una cadena de herencia verificada padre/hijo (Chain of Trust):
Domain |
Algorithm (p.ej. ECDSAP256SHA256) |
Hash Algorithm (tipicamente SHA256) |
Hash |
KeyTag |
Estos son los datos que un Registrar normalmente pide cuando compramos un dominio y queremos que tenga DNSSEC , ya que se debe publicar un registro DNSKEY conteniendo la clave pública que firma la zona, y el registro DS que va en la zona padre, debe contener un hash de dicha clave pública. Esto se conoce como Cadena de Confianza o Chain of Trust.
Al marcar una zona como DNSSEC , el PDNS crea automáticamente un par de claves (pública y privada), guardando la privada de manera segura, y publicando la pública en el registro DNSKEY. Esto es lo que se conoce como ZSK o Zone-Signing-Key.
Los resolvers, cuando resuelven registros de una zona DNSSEC, verifican la autenticidad de los registros obtenidos valiéndose de la clave pública de la DNSKEY. El servidor autoritativo primario, ante cada agregado o cambio de registros (Resource Records), firma el registro utilizando la clave privada de la 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.
Last Updated on 2024-04-20