| ... | @@ -6,6 +6,8 @@ No son pocos los servidores NS que gestionamos: massera y gould en CSIC (legacy) |
... | @@ -6,6 +6,8 @@ No son pocos los servidores NS que gestionamos: massera y gould en CSIC (legacy) |
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
Idea: podemos agrupar un conjunto de NS autoritativos en un grupo y, en este, diseñar una estructura de datos que sea zona por zona, con todo lo necesario para cada uno de los servidores NS involucrados con la zona. A partir de ésta, con un poco de [jmespath](https://jmespath.org/) podemos construir configuraciones coherentes para cada uno de los servidores NS del grupo.
|
|
|
|
|
|
|
# Delegación de la gestión de DNS
|
|
# 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:
|
|
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:
|
| ... | |
... | |
| ... | | ... | |
