Introducción a PDNS =================== **PDNS** es un producto para administrar DNS, tanto `autoritativo` como `recursivo`. .. image:: pdns-overview.jpg 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 .. list-table:: Sistemas Operativos * - RedHat9 * - Ubuntu22 * - Debian11 De esta manera nos aseguramos versiones de .. list-table:: Software de Base * - ISC Bind 9.16 o superior * - Python 3.8 o superior * - MariaDB 10.3 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`` etc .. warning:: 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 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. .. warning:: 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. .. note:: 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: .. list-table:: Roles * - 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. .. image:: icann.jpg 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. .. image:: pdns-acl.jpg 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**): .. list-table:: Registro DS * - 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. .. note:: 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*. .. image:: name-resolution.jpg 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. .. image:: change_lang.jpg .. |date| date:: Last Updated on |date|