Despliegues de PDNS =================== En esta seccion se presentaran multiples formas de despliegue, de acuerdo a los requerimientos del cliente en cuanto a carga. Debe tenerse en cuenta que dado que el producto es **Multi-Tenant**, tambien va dirigido a empresas que manejan multiples dominios sin requerimientos a nivel arquitectura DNS para Clientes Finales en el Cloud de Planisys ------------------------------------------------- En el cloud de Planisys, se provee la aplicacion PDNS en la nube. .. warning:: En esta seccion mostramos que cosas puede hacer un **usuario cliente**, sin importar la arquitectura network del despliegue. Clientes directos de Planisys acceden a una pagina web https://pdns-app.planisys.net:8443 con un unico nivel de rol de usuario, en el cual pueden crear Zonas (Master, Slave, Reversas IPv4 e IPv6) y crear Registros de Zona o RRs (Resource Records), y tambien utilizar la API con propia **APIKEY** (ver graficos) para p.ej. crear zonas, modificar registros, etc. Se trata de un servicio compartido, en el cual Planisys provee los servidores autoritativos acreditados en **ICANN** que el cliente debera utilizar para delegar sus dominios. .. image:: login-pdns.jpg El cliente puede utilizar los resolvers standard de Planisys. El tipo de zonas que un cliente final puede crear es: .. list-table:: Tipos de Zonas * - Master Directa * - Master Reversa IPv4 * - Master Reversa IPv6 * - Slave de master externo La empresa ademas puede: .. list-table:: Otras acciones * - Consultar el WHOIS del dominio (fecha de vencimiento y mas datos) * - Ver el status de delegacion (si esta dado de baja, si esta delegado a otros NSs) * - Acceder mediante el boton ``Registros`` o ``Records`` a los registros de Zona Registros de Zona (Resource Records) ++++++++++++++++++++++++++++++++++++ Luego al acceder a los registros, se puede ver que inmediatamente despues de la creacion de la Zona, el sistema asigno **automaticamente** dos registros ``NS`` correspondientes al ``NS-SET`` y un registro ``SOA`` cuyos datos se muestran en la parte de arriba por separado. Cualquier modificacion que se haga a nivel registros (borrar/editar/agregar), va a implicar un **incremento automatico del SOA Serial Number**. En este grafico vemos logueado al **usuario reseller**, pero es la misma vista para un **usuario cliente final**. .. image:: rr-list-1.jpg A continuacion se agregara un registro MX (haciendo click en el boton verde de agregar MX) para la zona *assetcrypt.com* , y veremos como cambia solo el *serial number* de 2023010500 a 2023012000. Como el tipo de Serial que tiene esta zona es de formato **YYYYMMDDSS** va a tratar de utilizar la fecha actual y luego SS desde 00 hasta 99. Las zonas se pueden dar de alta con un serial que no corresponda a fechas sino a numeros desde 0 hasta 2^32 -1 (4294967295).. .. image:: add-mx.jpg Aqui se muestra la lista de registros luego de agregar el NX, y se ve el serial number aumentado. Esto es un **trigger** que dispara que el servidor primario regenere la zona, y una vez cargada, se disparen los **zone transfers** hacia los secundarios via el protocolo ``NOTIFY`` (avisa a los secundarios que hagan un AXFR, en general se utiliza el protocolo IXFR que es un **zone transfer incremental** para traerse solo los cambios). .. image:: after-mx.jpg DNS para Revendedores en el Cloud de Planisys --------------------------------------------- Un revendedor de PDNS es una entidad que posee su propio **NS_SET** , es decir sus propios autoritativos, y eventualemente sus propios resolvers. Se provee de un login al Revendedor, cuya pantalla inicial se ve asi: .. image:: login-reseller1.jpg El revendedor tiene permisos para: .. list-table:: Permisos * - Crear Empresas * - Crear Usuarios de Empresas * - Crear Dominios * - Declarar sus Autoritativos * - Declarar sus Bloques CIDR para limitar Resolvers * - Declarar ACLs para zone transfers externos Empresas Clientes +++++++++++++++++ En un principio el revendedor ve sus empresas cliente: .. image:: company-list.jpg Manejo de Zonas ++++++++++++++++ y puede acceder directo a las zonas de sus clientes: .. image:: zone-list.jpg Aunque no se vaya a delegar la operacion de las zonas a sus clientes, ya sea porque estos no tienen personal con conocimientos o prefieren servicio gerenciado, es conveniente a nivel de la operatoria CRM saber que zonas/dominios tienen asignados sus clientes. .. warning:: En el caso de tener dominios sin identificar a que clientes pertenecen, se debera igualmente crear una empresa -aunque sea ficticia- para poder acceder a las zonas. Cambiar una Zona de una Empresa a otra ++++++++++++++++++++++++++++++++++++++ En el caso que tengamos dominios sin identificar, o dominios erroneamente asignados a una empresa, podemos muy facilmente desde la pantalla de zonas, haciendo click en el *icono lapiz*, acceder a la siguiente pantalla de edicion, en donde con solo elegir empresa en el *dropdown de Empresas* y apretar el boton de **Salvar** hacemos el **cambio de titularidad**. .. image:: edit-domain-metadata.jpg Debe notarse que el operador debe ayudarse con el boton ``WHOIS`` de la lista de dominios para establecer la titularidad o **ownership** de un dominio. .. image:: boton-whois.jpg WHOIS +++++ Con el boton WHOIS se despliega la informacion del dominio, que es dependiente de los **Registrars** de dominio, aunque debe ajustarse a las politicas de **ICANN**, p.ej.: .. image:: whois-content.jpg Es importante notar , que en la ventana de texto ``WHOIS`` figura la fecha de vencimiento del dominio. Autoritativos +++++++++++++ Para dar una idea del nivel de independencia que tiene un ``Despliegue de Revendedor``, mostramos aqui sus propios autoritativos, que se pueden encontrar en cualquier Datacenter, y pueden ser ``Unicast`` o ``Anycast`` (ver capitulo sobre **Alta Disponibilidad**): .. image:: auth-list.jpg .. note:: El hecho que la aplicacion PDNS este desplegada en la nube de Planisys, no implica que los autoritativos y resolvers tambien lo esten. En la imagen se ven dos nameservers registrados en **ICANN** que estan en la nube de Planisys, ``dns1.avascorp.net`` y ``dns2.avascorp.net``. Usuarios ++++++++ En este listado vemos un tipico caso de un user con derechos para operar las Zonas de una empresa, y el propio Reseller con un candado que no puede borrarse a si mismo .. image:: user-list-reseller.jpg Agregado de Usuarios ++++++++++++++++++++ En el despliegue de Revendedor podra crear usuarios. En este grafico se ve la creacion de un usuario operador de Empresa. .. image:: user-add-company-operator.jpg En este grafico se ve la creacion de un **Operador DNS** a nivel Revendedor, que puede crear zonas y empresas. Al seleccionar Operador DNS, se ve que desaparece el dropdown de eleccion de Empresa, ya que va a poder operar sobre todas las Empresas Cliente de este Revendedor. .. image:: user-add-reseller-operator.jpg Es importante notar que el usuario reseller1@planisys.com es un **Administrador DNS** a nivel Reseller, que tiene la posibilidad de crear diferentes clusteres de servidores autoritativos y recursivos, es decir con mas permisos que un **Operador DNS**. Despliegue de Recursivos y Autoritativos Externos +++++++++++++++++++++++++++++++++++++++++++++++++ El hecho que PDNS-APP corra dentro de la nube de Planisys, no significa que para un Revendedor, sus Resolvers y Autoritativos deban hacerlo en el mismo cloud. El Revendedor puede contratar servidores en diferentes **Clouds Publicos** o en sus propios Datacenters **OnPremise**, para que Planisys los administre, instale y monitoree sus componentes de software (``pipeline CI/CD``) que se conectan con la aplicacion **PDNS-APP**. Aqui se puede ver un ejemplo de un Revendedor que elige ubicar sus Resolvers y Recursivos en diferentes clouds publicos: .. image:: pdns-aws-azure.jpg Este grafico es una variacion del anterior, en donde el Revendedor elige tambien un Datacenter Corporativo de su empresa u otra junto con Clouds Publicos: .. image:: pdns-corp-aws.jpg PDNS-APP desplegado OnPremise ----------------------------- Para poder desplegar la aplicacion PDNS-APP OnPremise, independientemente de donde se desplieguen Recursivos y Autoritativos, se debera contar **minimamente** con dos VPSs (**Virtual Private Servers**) minimamente en el caso Redhat9 y un solo VPS para el caso Debian/Ubuntu. Tomando el caso de un solo VPS, las medidas son: .. list-table:: Dimensionamiento * - 16G - 4VCPU - 1000 a 5000 dominios * - 32G - 8VCPU - 5000 a 10000 dominios * - 64G - 16VCPU - 10000 a 25000 dominios .. note:: En el caso OnPremise, Planisys proveera **llave en mano** un **superadmin** , es decir un login con poder capaz de crear **Revendedores** con toda la capacidad descripta anteriormente. Si no hay Revendedores en el funcionamiento real, se debera crear un *Falso Revendedor unico* de todas maneras. Si no se quiere delegar la operacion a Empresas Cliente, o no existen Empresas Cliente, igualmente se debera crear una **Empresa Cliente** para poder asignarle las zonasm, aunque sea una *Falsa Empresa unica*. Un **superadmin** tiene el poder de crear otros **superadmins**. A partir de los 20mil dominios o 25mil dominios se hace necesario **clusterizar** y tener VPSs independientes para MariaDB, para Bind9 y para el codigo de PDNS-APP (3 VPSs), y en caso de haber mucha operacion utilizar **load-balancing** y **Galera-Cluster**. En el caso de RedHat9 se debera contar con una suscripcion a los repositorios para que Planisys pueda instalar las componentes de base como MariaDB, Python3, etc y mantener un kernel actualizado. A 2023 las alternativas son Debian11 y Ubuntu 22.04 (la alternativa Ubuntu 22.10 no es viable porque su soporte expira a los 9 meses del Release). Instalacion minima menos a 10 mil dominios ++++++++++++++++++++++++++++++++++++++++++ .. image:: onpremise-pdns-app.jpg .. note:: Aqui se presenta una instalacion en un unico VPS, con el dimensionamiento sugerido anteriormente. .. warning:: En esta instalacion, el proveedor OnPremise tiene la responsabilidad de acumular componentes de **Alta Disponibilidad**, tales como discos con **RAID**, **circuito electrico A+B**, **doble upstream de Internet**, **Snapshot Backups periodicos**, utilizar las capacidades de **VMWare HA**, configurar **Proxmox HA Cluster** con **firmware fencing** (IPMI/iDrac/APC) etc Instalacion para mas de 25 mil dominios +++++++++++++++++++++++++++++++++++++++ En este caso se sugiere partir en mas VPSs la instalacion, utilizar un load-balancer y un Galera-Cluster con Quorum de 3 database servers. Es un ejemplo de un dimensionamiento mayor, en donde Planisys entrega todos los VPSs configurados (incluyendo nginx/haproxy y Galera Cluster). .. image:: onpremise-pdns-big.jpg .. note:: En el grafico figura el requerimiento de **LoadBalancing** segun ``sticky sessions``. Este requerimiento de mantener la sesion basados en la ip y port originantes cliente es solo necesario para la interfaz Web, ya que la interfaz API es **stateless** (no tiene sesiones) ya que se basa en el intercambio de ``JSONs``. .. warning:: En el loadbalancer no debe usarse round-robin ni distribucion por carga cuando el *upstream* es la **interfaz web**. Cuando el *upstream* es la **API** el metodo mas conveniente es ``leastconn` , es decir trata de cargar a los upstreams por igual basado en conexiones abiertas. Ansible Jumphost (Pivote) ------------------------- PDNS utiliza como parte del despliegue un ``jumphost`` , tambien a veces llamado ``pivote``, en donde corre la herramienta de **orquestacion** ``Ansible``. Por medio de esta herramienta, PDNS puede soportar una gran cantidad de servidores *recursivos* y *autoritativos*. La orquestacion se realiza para instalar las componentes necesarias, y los scripts de: .. list-table:: * - pipeline CI/CD * - monitoreo * - analisis de logs * - alertas * - estadisticas Esto requiere que los servidores a ser orquestados tengan **permisos de root** a traves de la ``clave publica ssh`` del pivote Ansible. Esto se hace simplemente agregando la llave publica que provee Planisys en los servidores a orquestar en el archivo **/root/.ssh/authorized_keys**. Es decir si un cliente/revendedor o propietario quiere aprovisionar servidores autoritativos o recursivos, podra hacerlo en forma de container o maquina virtual de cualquier nube , pero debera cederle **Control de Orquestacion** al pivote Ansible de PDNS. De esta manera, se pueden realizar despliegues graduales, o inclusive pruebas de concepto o **PoC** en donde se utilice PDNS-Cloud (en el Cloud de Planisys). NS-Set ------ Un NS-Set o Nameserver Set es un conjunto de servidores autoritativos, en donde uno se configura como **Master** y el resto como **Slave**. El servidor master es el que reconstruye las zonas Bind a partir de la informacion recopilada via Web y via API alojada en la base de datos. Los servidores slave replican las zonas por el mismo protocolo, utilizando **DNS NOTIFY** para ser avisados de cambios en las zonas. El NS-Set es un **circulo de confianza** que comparte una llave TSIG y evitar ``spoofing`` de direcciones IP. Por otra parte , a nivel de las Empresas, se pueden definir **ACLs** o **Access Control Lists** con permisos de transferencia (por IP o por TSIG), para poder intercambiar zonas en ambos sentidos entre el **Master** y **Servidores Bind9 Externos**. .. image:: ns-set.jpg