Rol de Ansible: manage-bind 2.0

Este rol se construye como una capa de abstracción para configurar bind y crear zonas DNS utilizando la sintaxis YAML.

• Instalar y gestionar tu servidor bind9 en servidores Debian/Ubuntu.
• Usar sintaxis/archivos YAML para configurar opciones de Bind, zonas, etc.

Requisitos

Ansible 2.4+

Nota: este rol requiere acceso de root al servidor bind.

playbook.yml:

- hosts: dnsserver
  roles:
    - role: aalaesar.manage-bind
      become: yes

Variables del Rol

# configuración del host
bind_user:  bind
bind_group: bind
host_dns_srv: self
# directorio de registros
bind_log_dir: /var/log/bind
# Configuración de instalación
bind_pkg_state: present
bind_pkgs: ['bind9', 'dnsutils']
bind_service_state: started
bind_service_enabled: yes
# Configuraciones
bind_configs_dir: /etc/bind
bind_config_master_zones: []
bind_config_default_zones: 'yes'
RFC1918: no
# Archivos de zonas
bind_zones_dir: /var/lib/bind
# Configuración predeterminada de zonas
zones_config_ttl: 38400 #10h45m
zones_config_refresh: 10800 #3h
zones_config_retry: 3600 #1h
zones_config_expire: 604800 #1w
zones_config_minimum: 38400 #10h45m

# eliminar archivos no gestionados para mantener el servidor limpio
remove_unmanaged_files: true
# inicializar lista de archivos de zonas gestionadas:
list_zone_files: []

Configurando Bind

Introducción a la configuración de Bind

Bind utiliza un mecanismo de herencia de declaraciones de cláusulas para permitir una configuración precisa.

• Una cláusula es una clase con su propio conjunto de declaraciones.
  • Pueden tener declaraciones específicas o comunes.
  • Una cláusula definida dentro de otra cláusula heredará implícitamente las declaraciones comunes de su madre.
• Una declaración es una propiedad de la cláusula.
  • Describe el comportamiento del servidor sobre cómo realizar una tarea, cuándo, etc.
  • Puede estar definida de forma explícita o implícita.
• Algunas reglas de herencia:
• Options es la cláusula superior que incluye todas las demás.
• zone es la cláusula más baja. No puede tener ningún hijo. También contiene registros de zona.
• una cláusula puede sobreescribir la declaración de su madre y pasar el nuevo valor a su(s) hijo(s) redefiniendo explícitamente la declaración.

  Aquí hay un ejemplo ASCII de estas reglas:

|##########|  
|  zone1   |  |#########|
|==========|  |  zone2  |
|statement1|  |=========|
|  =john   |  |         |
|##########|  |#########|
     /\            /\
     ||            ||
|#######################|   |##############|   |##############|
|         view1         |   |   zone3      |   |    zone4     |
|=======================|   |==============|   |              |
|  statement2=kangaroo  |   |statement1=bar|   |##############|
|#######################|   |##############|          /\
           /\                     /\                  ||
           ||                     ||                  ||
|#############################################################|
|                          Options                            |
|=============================================================|
|                       statement1=foo                        |
|                      statement2=koala                       |
|#############################################################|
Resultado final:
Según statement1 y statement2 son comunes a todas las cláusulas
zone1: statement1=john, statement2=kangaroo
zone2: statement1=foo, statement2=kangaroo
zone3: statement1=bar, statement2=koala
zone4: statement1=foo, statement2=koala

manage-bind admite las siguientes cláusulas:

• options
• zone
• key

La lista de declaraciones soportadas: Ver ./vars/main.yml

TODO: views

Precaución al definir una declaración !

• algunas declaraciones están definidas con mapeos complejos mientras que otras requieren solo un valor simple. Por si acaso, cada declaración tiene su propia plantilla auto-documentada.
• manage-bind utiliza las herramientas de bind named-checkconf y named-checkzone para la configuración y validación de zonas. Sin embargo, estas herramientas están limitadas a la sintaxis y verificación ligera de coherencia. Este rol no proporciona métodos de validación avanzados.
• Escapa caracteres especiales como @ con comillas.
• Algunas declaraciones requieren valores de cadena "yes|no": Escapa yes y no con comillas ya que Ansible los evalúa como booleanos.

La cláusula Options

Nota: El rol viene con algunas opciones predeterminadas.

Definiendo las declaraciones de opciones

Al llamar a manage-bind, puedes pasar declaraciones de opciones:

• en un archivo YAML externo declarado con options_file.
  • debe contener un mapeo de declaraciones llamado options.
• en un mapeo llamado options dentro de tu playbook.

Nota: El primer método excluye el segundo: el rol solo cargará las declaraciones en el archivo si lo declaras en tu playbook.

playbook.yml:

- hosts: dnsserver
  become: yes
  roles:
    - role: aalaesar.manage-bind
      options_file: ./files/options.yml # el rol solo cargará estas opciones
      options: # las siguientes líneas son inútiles en este caso
        statement1: ...
        statement2: ...

./files/options.yml:

---
options:
  statement1: ...
  statement2: ...

La lista de todas las declaraciones disponibles para las opciones está en ./tests/bind_options.yml

Cambiando las opciones predeterminadas del rol:

Están definidas en ./defaults/default_options.yml

Puedes usar este archivo para compartir una política común en tu infraestructura y anular opciones específicas fácilmente.

Cláusulas de Zonas

Las cláusulas de zona se definen con declaración y registros de zona.

declaración de zona

Cada zona se declara como un elemento de la lista llamada zones.

'zones' deben definirse en el playbook y es obligatorio.

playbook.yml:

- hosts: dnsserver
  become: yes
  roles:
    - role: aalaesar.manage-bind
      zones:
        "zona 1":
          declaraciones ...
        "zona 2":
          declaraciones ...

Definiendo las declaraciones de la zona

Una zona es un mapeo donde el nombre de la zona es su clave principal y sus declaraciones son claves:valor.

• [declaración]:valor
• type es una declaración obligatoria.
• force_file [booleano]: Indica a ansible que reescriba el archivo de base de datos de registros. Útil si tu zona es poblada dinámicamente por DNS. - falso para zonas esclavas - verdadero para otras.
• Algunos tipos de zona tienen sus propias declaraciones obligatorias.

playbook.yml:

zones:
  ejemplo.com: # El nombre del dominio
    type: master # Obligatorio. El tipo de la zona: master|slave|forward|stub
    recursion: "no" # declaración que sobrescribe la opción global "recursion" para esta zona.
    ... # etc

La lista de todas las declaraciones de la zona disponibles está en ./tests/zone_statements.md

Definiendo los registros de la zona

Los registros de la zona se definen en un mapeo llamado 'records'.

Este mapeo 'records' puede declararse:

• en un archivo YAML especificado en la clave yamlfile.
• como un mapeo dentro de su mapeo de zona.

Nota: el contenido de los archivos Yaml se combina con la configuración de la zona: Así que, en caso de registros duplicados, el contenido del archivo tendrá prioridad.

playbook.yml:

zones:
  ejemplo.com:
    records:
      SOA: ...
      NS: ...
      ... # etc
    ... # etc
  test.tld:
    yamlfile: "./files/test.tld.yml"
    records:
      SOA: ...
      NS: ...
      A:
       localhost: 127.0.0.1
       test1: 9.8.7.6 # será sobrescrito por el archivo yaml
    ... # etc

En el archivo yaml, records debe ser un mapeo de nivel superior:

./files/test.tld.yml:

---
records:
  SOA: ...
  NS: ...
  A:
   test1: 1.2.3.4
   test2: 5.6.7.8
  ... # etc

Agregando registros en la zona

Los registros de zona tienen diferentes tipos, se declaran por tipo dentro de records.

cada tipo de registro es diferente y sigue su propia estructura YAML.

Manage-bind admite los siguientes registros:

• SOA
• NS
• A
• AAAA
• MX
• SRV
• PTR
• CNAME
• DNAME
• TXT
• ttl puede declararse junto a los registros de la zona.

Dependencias

Ninguna.

Ejemplos de Playbooks

Ejemplo de configuración:

• Posees las zonas example.tld, example.com y example.org.
• Tienes 2 servidores de nombres: dnserver1 (11.22.33.44) y dnserver2 (55.66.77.88).
• dnserver1 es maestro de example.tld y esclavo de example.com.
• dnserver2 es maestro de example.com y esclavo de example.tld.
• example.tld es poblado dinámicamente por un servidor DHCP.

playbook de dnserver1:

---
- hosts: dnserver1
  roles:
    - role: aalaesar.manage-bind
      options:
        allow_recursion: '55.66.77.88'
        allow_transfer: '55.66.77.88'
      zones:
        example.tld:
          type: master
          force_file: no
          notify: '55.66.77.88'
          allow_update:
            - key dhcp_updater
          records:
            - SOA:
                serial: 2016080401
                ns: dnserver1.example.tld.
                email: admin.example.tld.
            - NS:
              - dnserver1.example.tld.
              - dnserver2.example.tld.
            - A:
                dnserver1: 11.22.33.44
                dnserver2: 55.66.77.88
        example.com:
          type: slave
          masters: '55.66.77.88'
      keys:
      - name: dhcp_updater
        algorithm: "hmac-md5"
        secret: "{{myvault_dhcp_key}}"

playbook de dnserver2:

---
- hosts: dnserver2
  roles:
    - role: aalaesar.manage-bind
      options:
        allow_recursion: '11.22.33.44'
        allow_transfer: '11.22.33.44'
      zones:
        example.com:
          type: slave
          notify: '11.22.33.44'
        example.tld:
         type: slave
         masters: '11.22.33.44'
         ymlfile: example.com.yml

Archivo YAML para example.com.yml en dnserver2

---
records:
  ttl: 3d
  SOA:
    serial: 2016080401
    ns: dnserver2.example.com.
    email: admin.example.com.
  NS:
    - srvdns01.example.com.
  A:
    127.0.0.1:
      - '@'
      - dnserver2.example.com.
    host1: 12.34.56.78
    mailsrv: 98.76.54.32
    'ftp.domain.tld.': 95.38.94.196
  MX:
    '@':
      - target: backup.fqdn.
        priority: 20
  CNAME:
    host1: ftp
    '@':
      - www
      - webmail
  TXT:
    - text: '"v=spf1 mx -all"'
    - text: '( "v=DKIM1; k=rsa; t=s; n=core; p=someverylongstringbecausethisisakeyformailsecurity" )  ; ----- DKIM key mail for example.com'
      label: mail._domainkey

Más ejemplos están disponibles en la carpeta de pruebas.

Licencia

BSD