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.
Advertencia
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.
El cliente puede utilizar los resolvers standard de Planisys.
El tipo de zonas que un cliente final puede crear es:
Master Directa |
Master Reversa IPv4 |
Master Reversa IPv6 |
Slave de master externo |
La empresa ademas puede:
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 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.
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)..
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).
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:
El revendedor tiene permisos para:
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:
Manejo de Zonas
y puede acceder directo a las zonas de sus clientes:
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.
Advertencia
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.
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.
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.:
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):
Nota
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
Agregado de Usuarios
En el despliegue de Revendedor podra crear usuarios. En este grafico se ve la creacion de un usuario operador de Empresa.
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.
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:
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:
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:
16G - 4VCPU - 1000 a 5000 dominios |
32G - 8VCPU - 5000 a 10000 dominios |
64G - 16VCPU - 10000 a 25000 dominios |
Nota
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
Nota
Aqui se presenta una instalacion en un unico VPS, con el dimensionamiento sugerido anteriormente.
Advertencia
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).
Nota
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.
Advertencia
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:
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.
