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. Cómo hacer forward a la IP de la nube de Planisys con unbound ------------------------------------------------------------- En caso de ya tener uno o más servidores unbound en su nube propia on-premise, y querer hacer forward de todo aquello que no esté en la caché del unbound, realizar la siguiente configuración en unbound: .. code:: bash 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: .. note:: 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 poder desplegar una instalación OnPremise, se requiere de Máquinas Virtuales o Físicas con .. list-table:: Sistemas Operativos y paquetes * - Debian12 con paquete nativo 9.18.24+ De esta manera nos aseguramos versiones de .. list-table:: Software de Base * - 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 .. 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. 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) .. note:: 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 --------------------- 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 .. warning:: 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. 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*. Delegación de zonas ------------------- La delegación de un dominio que cuelga debajo de un **TLD** (como p.ej. .com, o .co , o .ar) , así como las delegaciones de **sub-TLDs** (p.ej. com.ar) deben realizarse en el Registrar correspondiente. Lo mismo vale para reversos, por ej. yendo a www.lacnic.net para delegar a los nameservers que corresponda la resolución reversa. **Los registros NS no pueden apuntar a un CNAME** En el sistema de nombres de dominio (DNS), los registros NS (Name Server) son fundamentales para la delegación de un dominio, ya que indican qué servidores son responsables de responder consultas sobre una zona específica. Sin embargo, según los estándares DNS, un registro NS nunca debe apuntar a un CNAME (alias). **Esto está prohibido por las especificaciones RFC 1912 (Sección 2.4) y RFC 2181 (Sección 10.3), debido a los problemas de resolución que esto puede generar.** RFC 2181 (Seccion 10.3) .. image:: rfc2181.png **¿Por qué no se permite esta configuración?** 1. Las delegaciones deben ser directas Un NS debe apuntar siempre a un nombre de host con un registro A o AAAA, no a un CNAME. 2. Riesgo de resolución en bucle Algunos resolvers no siguen CNAMES en delegaciones de NS, lo que puede causar que el dominio se vuelva irresoluble. 3. Inconsistencia entre la delegación del TLD y la resolución final El TLD delega a un NS que luego es un CNAME, lo que genera discrepancias y puede hacer que algunos usuarios no puedan resolver el dominio correctamente. El uso de **CNAME** en registros NS es un **error grave** y debe evitarse. Siempre que se configure un servidor de nombres, debe asegurarse de que los registros NS apunten a nombres que tengan registros A o AAAA válidos. De lo contrario, el dominio puede volverse inaccesible para algunos usuarios y provocar problemas de resolución en toda la infraestructura de DNS. Delegaciones rengas o lame delegations ++++++++++++++++++++++++++++++++++++++ Por otro lado, los autoritativos a los que resuelve una zona segun el Registrar, deben responder **todos** con **al menos el mismo** conjunto de registros NS que lo que se ha declarado en el registrar. Decimos *al menos* porque es posible en los autoritativos agregar **stealth servers**, es decir servidores agregados pero que no figuran en el Registrar. Estos stealth servers también deben respetar que el conjunto de registros NS sea el mismo que en los nameservers declarados. Los stealth servers, si bien no están declarados en el registrar, deben mantener la coherencia en su configuración de NS para evitar problemas. Si algún nameserver , ya sea *declarado* o *stealth* , no responde con el conjunto completo de registros NS , tenemos una **lame delegation**. Es decir un query puede fallar en función de los resolvers. Para que una delegación sea válida, todos los nameservers autoritativos de una zona deben responder con el mismo conjunto de registros NS que fueron declarados en el registrar del dominio. Sin embargo, una lame delegation ocurre cuando: • Un servidor autoritativo listado en el registrar no responde correctamente o no contiene todos los registros NS esperados. • Un servidor stealth (autoridad adicional no listada en el registrar) no mantiene coherencia en los registros NS. • Un resolver obtiene respuestas inconsistentes dependiendo de qué servidor responde, lo que genera fallos intermitentes en la resolución. El mundo de los resolvers +++++++++++++++++++++++++ Cuando se establecen reglas como las de evitar **lame delegation** o la de **prohibir CNAMEs** en los registros NS, no se está pensando en los *Resolvers públicos* , sino más bien en los **cientos de millones** de CPEs o routers tipo ADSL o Fibra que corren un resolver, y adhieren a las 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. Recomendaciones para Evitar Lame Delegations Para garantizar una delegación correcta y evitar problemas de resolución, es fundamental: 1. Mantener la coherencia en los registros NS: Todos los nameservers deben devolver el mismo conjunto de registros NS, tanto los declarados en el registrar como los stealth. 2. Verificar la delegación con herramientas DNS: Se recomienda usar herramientas como dig, nslookup o dnsviz.net para detectar discrepancias en la delegación. 3. Evitar servidores stealth mal configurados: Si se agregan stealth nameservers, asegurarse de que reflejen exactamente la misma información que los servidores listados en el registrar. 4. Hacer pruebas con distintos resolvers: No confiar solo en resolvers públicos. Probar con resolvers de diferentes ISPs y entornos empresariales para detectar posibles fallos. 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|