|
|
|
# Estructura de datos para servidores NS
|
|
|
|
|
|
|
|
Tenemos [una base de proceso de gestión de DNS con Ansible](https://proyectos.interior.edu.uy/projects/dns/wiki/Manejo_de_zonas_con_ansible) y estamos en [un refactor del rol bind9](https://git.interior.edu.uy/adminsys/config/issues/348) para lograr mejores y más detalladas configuraciones en los servidores NS.
|
|
|
|
|
|
|
|
No son pocos los servidores NS que gestionamos: massera y gould en CSIC (legacy), anaconda, seciu, guabiyú, ritchie, y ahora catanga.
|
|
|
|
|
|
|
|
Al planificar la migración de zonas, se hace evidente la necesidad de una adecuación de datos: configuramos los NS, zona por zona, decidiendo qué primarios y qué secundarios para cada zona. No obstante, nuestra configuración ansible requiere, como los servidores BIND9, definir las cosas servidor por servidor. No hay a priori verificación de la coherencia global de la configuración del conjunto de NS.
|
|
|
|
|
|
|
|
# Delegación de la gestión de DNS
|
|
|
|
|
|
|
|
Ya tenemos [una base de proceso de gestión de DNS con Ansible](https://proyectos.interior.edu.uy/projects/dns/wiki/Manejo_de_zonas_con_ansible). No obstante, en este proceso, para modificar un registro de NS, es necesario:
|
|
|
|
* tener acceso y derecho de escritura sobre [el proyecto de infraestructura de nube del Interior](https://git.interior.edu.uy/adminsys/config),
|
|
|
|
* tener derechos de administración en [el servidor guabiyú](https://git.interior.edu.uy/adminsys/config/tree/master/host_vars/guabiyu.interior.edu.uy/)
|
| ... | ... | |
| ... | ... | |
