|
|
|
# Manejo de zonas con Ansible
|
|
|
|
|
|
|
|
[Conceptos y bases de DNS](DNS/Conceptos y bases de DNS)
|
|
|
|
|
|
|
|
El Sistema de Nombres de Dominio (DNS) es un servicio de la Internet que permite asociar nombres de dominio (como: www.udelar.edu.uy, git.interior.edu.uy o matera.interior.edu.uy) esencialmente a direcciones IPv4 e IPv6.
|
|
|
|
|
|
|
|
## Servicios DNS de la redUI
|
|
|
|
|
|
|
|
Para la resolución DNS de los hosts de nuestra infraestructura de computación en la nube, mantenemos dos **resolvedores NS**:
|
|
|
|
* araza.interior.edu.uy
|
|
|
|
* mburucuya.interior.edu.uy
|
|
|
|
|
|
|
|
También mantenemos [un cluster de servidores DNS autoritativos](https://git.interior.edu.uy/adminsys/config/-/blob/main/group_vars/cielito_ns_authoritative/vars/30_bind.yml?ref_type=heads#L71), en los que se gestiona, con Ansible, la definición de [las zonas DNS que se les delegan](DNS/redUI-zonas-dns-manejadas).
|
|
|
|
|
|
|
|
Los servicios, grupos y proyectos que quieran manejar su(s) propia(s) zonas y dominios deberán solicitarlas al correspondiente _registrar_:
|
|
|
|
* para una sub-zona de `udelar.edu.uy`, se la debe solicitar [al SeCIU ](https://www.seciu.edu.uy/),
|
|
|
|
* para una zona en `.uy`, en https://nic.uy/
|
|
|
|
* otros registrar globales, como [Gandi](https://gandi.net)
|
|
|
|
|
|
|
|
Al registrar la zona se deberá ingresar a qué servidores NS se delega la gestión. Conviene haber solicitado previamente el hospedaje de la zona (mediante [una tarea](https://git.interior.edu.uy/adminsys/config/-/issues/new)), proceso en el cual se acordará [en qué servidores NS del cluster](https://git.interior.edu.uy/adminsys/config/-/blob/main/group_vars/cielito_ns_authoritative/vars/30_bind.yml?ref_type=heads#L71) desplegarla.
|
|
|
|
|
|
|
|
## Arquitectura lógica de nuestro DNS
|
|
|
|
|
|
|
|
En la redUI tenemos [un cluster de servidores DNS autoritativos](https://git.interior.edu.uy/adminsys/config/-/blob/main/group_vars/cielito_ns_authoritative/vars/30_bind.yml?ref_type=heads#L71), distribuidos en las sedes de la UdelaR en el Interior que, desde 2023, configuramos con ansible, con el rol [`cielito.system.dns`](https://galaxy.ansible.com/ui/repo/published/cielito/system/content/role/dns/), de la colección [`cielito.system`](https://galaxy.ansible.com/ui/repo/published/cielito/system/), que desarrollamos a partir de los primeros roles que utilizamos inicialmente.
|
|
|
|
|
|
|
|
De preferencia, las zonas que gestionamos se definen en yaml, en [uno o varios archivos de variables de la IaC](https://git.interior.edu.uy/adminsys/config/-/tree/main/group_vars/cielito_ns_authoritative/vars/zonas?ref_type=heads). No obstante, por razones histórica, algunas zonas aún se configuran en un archivo bind `db.<zona>`, en en [esta carpeta](https://git.interior.edu.uy/adminsys/config/tree/main/files/bind/zones).
|
|
|
|
|
|
|
|
Para evitar que las sucesivas modificaciones del DNS se "pisen", gestionamos el dns _**exclusivamente**_ desde la rama `main`, y subimos las modificaciones del dns inmediatamente luego de haberlas desplegado.
|
|
|
|
|
|
|
|
## Modificación y despliegue DNS
|
|
|
|
|
|
|
|
**Antes que nada**: si trabajamos en una instancia local del proyecto [`adminsys/config`](https://git.interior.edu.uy/adminsys/config) conviene pararse en la rama main y recuperar la última versión:
|
|
|
|
```
|
|
|
|
git checkout main
|
|
|
|
git pull
|
|
|
|
```
|
|
|
|
Para la mayoría de las zonas, manejamos directamente el archivo BIND de definición de zona ubicado en [esta carpeta](https://git.interior.edu.uy/adminsys/config/tree/main/files/bind/zones) del repositorio del proyecto.
|
|
|
|
|
|
|
|
Por ejemplo [este es el archivo de la zona **interior.edu.uy**](https://git.interior.edu.uy/adminsys/config/blob/main/files/bind/zones/db.interior.edu.uy) a la versión de hoy.
|
|
|
|
|
|
|
|
Ciertas zonas (actualmente las resoluciones inversas de nuestras IPv4 e IPv6) se configuran, no directamente en el archivo de zona, sino en una estructura de variables que los construye, situada en [este archivo](https://git.interior.edu.uy/adminsys/config/blob/main/host_vars/guabiyu.interior.edu.uy/vars/30_zones.yml) del repositorio del proyecto.
|
|
|
|
|
|
|
|
Para manejar una zona, hay que modificar manualmente ya sea su archivo ya sea su estructura de variables YAML. Luego de dicha modificación corremos el playbook Ansible:
|
|
|
|
|
|
|
|
```
|
|
|
|
ansible-playbook -i hosts_prod --limit guabiyu.interior.edu.uy site.yml -vv --tags ns_master
|
|
|
|
```
|
|
|
|
**OjO**: El uso de Ansible sólo facilita la detección de error, no disminuye el riesgo de error dado que la edición del archivo **db.** no deja de ser manual.
|
|
|
|
|
|
|
|
En particular:
|
|
|
|
* cualquier modificación que se haga en ese NS master, es indispensable incrementar el serial (por supuesto siguiendo la nomenclatura `AAAAMMDDXX`: año, mes, día, serial menor). Esto es neceario para la propagación a los secundarios y caches,
|
|
|
|
* si se van a hacer migraciones de servidores o dominios, conviene previamente, al menos con 86400 segundos (un día) de anticipación, bajar los TTL a 10 minutos, para asegurar que la propagación sea más ágil, y menos costosa en eventuales DoS si hubiera que hacer marcha atrás.
|
|
|
|
|
|
|
|
**SIEMPRE VERIFICAR** que la modificación DNS realizada es **EFECTIVA**, y en cada uno de los servidores NS de zona. Los errores de DNS pueden ser fatales: gracias a los secundarios todo parece funcionar, pero en realidad el master está caído. El resultado salta una semana después, cuando los secundarios dejan de tener datos vigentes. Además, el DNS es un servicio arquetípico de un adagio: *la internet está tan bien hecha, que funciona hasta cuando se la configura mal*.
|
|
|
|
|
|
|
|
**Una vez la modificación DNS se realizó satisfactoriamente, no olvides guardar y versionar los cambios en el repositorio del proyecto, realizando un *commit* y un *push* al mismo.** ([Lectura recomendada.](la-importancia-de-la-rama-estable))
|
|
|
|
|
|
|
|
Las zonas de resolución inversa son manejadas como lo que el [role bind](https://github.com/UdelaRInterior/ansible-role-bind9) denomina "zonas dinámicas". Al revés de las precedentes "zonas estáticas" cuyo archivo **db.** es manejado directamente, los datos de las zonas dinámicas se presentan como estructuras yaml y Ansible construye el archivo de zona.
|
|
|
|
|
|
|
|
El archivo en el que se encuentran dichas estructuras es [este](https://git.interior.edu.uy/adminsys/config/blob/main/host_vars/guabiyu.interior.edu.uy/vars/30_zones.yml).
|
|
|
|
|
|
|
|
## Zonas que actualmente se manejan con Ansible
|
|
|
|
* interior.edu.uy
|
|
|
|
* chea.edu.uy
|
|
|
|
* softwarelibre.edu.uy
|
|
|
|
* softwarelibre.uy
|
|
|
|
* dedicaciontotal.udelar.edu.uy
|
|
|
|
* ... |
|
|
\ No newline at end of file |