| ... | ... | @@ -29,40 +29,35 @@ Para evitar que las sucesivas modificaciones del DNS se "pisen", gestionamos el |
|
|
|
|
|
|
|
## Modificación y despliegue DNS
|
|
|
|
|
|
|
|
El despliegue de una configuración DNS sólo puede ser realizado por los administradores de la redUI (o de cada uno de los servidores NS) pero, al ser gestionadas las configuraciones de zona en este gitlab, la solicitud de una modificación puede ser realizada, incluyendo de preferencia la codificación de los registros de zona, por cualquier persona con acceso a este repositorio gitlab (incluso sólo en lectura) y un mínimo de entendimiento del DNS.
|
|
|
|
|
|
|
|
Si sólo tienes derecho de lectura (guest) al [repositorio de la IaC de la redUI](https://git.interior.edu.uy/adminsys/config), empieza por bifurcar el repositorio (hacer un _fork_), desde el cual propondrás las configuraciones DNS.
|
|
|
|
|
|
|
|
Si no, puedes empezar por [una incidencia (_issue_)](https://git.interior.edu.uy/adminsys/config/-/issues/new) redactando las necesidades, y luego [una propuesta de fusión (_merge request_)](https://git.interior.edu.uy/adminsys/config/-/merge_requests) que pasa los requerimientos a código yaml/bind conforme a la API del rol [`cielito.system.dns`](https://galaxy.ansible.com/ui/repo/published/cielito/system/content/role/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.
|
|
|
|
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).
|
|
|
|
|
|
|
|
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.
|
|
|
|
Para manejar una zona, hay que modificar manualmente ya sea su estructura de variables YAML, ya sea su archivo bind.
|
|
|
|
|
|
|
|
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.
|
|
|
|
**SIEMPRE RECORDAR:**
|
|
|
|
* cualquier modificación que se haga en una zona, es indispensable incrementar el serial (por supuesto siguiendo la nomenclatura `AAAAMMDDXX`: año, mes, día, serial menor). Esto es necesario 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.
|
|
|
|
* la actualización de una zona gestionada con un archivo bind `db.` siempre puede ser la ocasión de migrarla a yaml.
|
|
|
|
|
|
|
|
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:
|
|
|
|
Luego de dicha modificación corremos el playbook Ansible, para lo cual es necesario ser administrador (acceso ssh privilegiado) al menos del servidor primario de cada una de las zonas que se despliegan:
|
|
|
|
|
|
|
|
```
|
|
|
|
ansible-playbook -i hosts_prod --limit guabiyu.interior.edu.uy site.yml -vv --tags ns_master
|
|
|
|
./site.yml -i hosts_prod -l guabiyu.interior.edu.uy -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.
|
|
|
|
**OjO**: El uso de Ansible sólo facilita la detección de error, no disminuye mucho el riesgo de error, sea de dedo que la edición del archivo **db.**, sea de coherencia dns (más allá de un [`named-checkconf`](https://git.interior.edu.uy/cielito/system/-/blob/c0464968397597b60087b48c17b103ba03247529/roles/dns/tasks/30_configure_bind9.yml#L73).
|
|
|
|
|
|
|
|
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*.
|
|
|
|
Por ende, **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 |
|
|
|
Ver también: [zonas NS que maneja la redUI](DNS/redUI-zonas-dns-manejadas) |
