Rôle Ansible : manage-bind 2.0

Ce rôle est conçu comme une couche d'abstraction pour configurer bind et créer des zones DNS en utilisant la syntaxe YAML.

• Installer et gérer votre serveur bind9 sur des serveurs Debian/Ubuntu.
• Utilisez la syntaxe/fichiers YAML pour configurer les options, zones, etc. de Bind.

Exigences

Ansible 2.4+

Remarque : ce rôle nécessite un accès root au serveur bind.

playbook.yml:

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

Variables de Rôle

# Configuration de l'hôte
bind_user:  bind
bind_group: bind
host_dns_srv: self
# Répertoire des logs
bind_log_dir: /var/log/bind
# Configuration d'installation
bind_pkg_state: present
bind_pkgs: ['bind9', 'dnsutils']
bind_service_state: started
bind_service_enabled: yes
# Configurations
bind_configs_dir: /etc/bind
bind_config_master_zones: []
bind_config_default_zones: 'yes'
RFC1918: no
# Fichiers de zones
bind_zones_dir: /var/lib/bind
# Configuration par défaut des zones
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

# Supprimer les fichiers non gérés pour garder le serveur propre
remove_unmanaged_files: true
# Initialiser la liste des fichiers de zones gérés :
list_zone_files: []

Configuration de Bind

Introduction à la configuration de Bind

Bind utilise un mécanisme d'héritage des déclarations de clauses pour permettre une configuration précise.

• Une clause est une classe avec son propre ensemble de déclarations.
  • Elles peuvent avoir des déclarations spécifiques ou communes.
  • Une clause définie à l'intérieur d'une autre clause héritera implicitement des déclarations communes de sa mère.
• Une déclaration est une propriété d'une clause.
  • Elle décrit le comportement du serveur sur la manière d'effectuer une tâche, que ce soit, quand, etc.
  • Elle peut être définie explicitement ou implicitement.
• Quelques règles d'héritage :
• Options est la clause supérieure qui comprend toutes les autres.
• zone est la clause inférieure. Elle ne peut pas avoir d'enfants. Elle contient également des enregistrements de zone.
• une clause peut remplacer la déclaration de son parent et transmettre la nouvelle valeur à son ou ses enfants en redéfinissant explicitement la déclaration.

  Voici un exemple ASCII de ces règles :

|##########|  
|  zone1   |  |#########|
|==========|  |  zone2  |
|statement1|  |=========|
|  =john   |  |         |
|##########|  |#########|
     /\            /\
     ||            ||
|#######################|   |##############|   |##############|
|         view1         |   |   zone3      |   |    zone4     |
|=======================|   |==============|   |              |
|  statement2=kangaroo  |   |statement1=bar|   |##############|
|#######################|   |##############|          /\
           /\                     /\                  ||
           ||                     ||                  ||
|#############################################################|
|                          Options                            |
|=============================================================|
|                       statement1=foo                        |
|                      statement2=koala                       |
|#############################################################|
Résultat final :
Selon statement1 et statement2 qui sont communs à toutes les clauses
zone1 : statement1=john, statement2=kangaroo
zone2 : statement1=foo, statement2=kangaroo
zone3 : statement1=bar, statement2=koala
zone4 : statement1=foo, statement2=koala

manage-bind supporte les clauses suivantes :

• options
• zone
• key

La liste des déclarations supportées : Voir ./vars/main.yml

À FAIRE : vues

Avertissement lors de la définition d'une déclaration !

• certaines déclarations sont définies avec des mappages complexes tandis que d'autres nécessitent juste une valeur simple. Au cas où, chaque déclaration a son propre modèle auto-documenté.
• manage-bind utilise les outils de bind named-checkconf et named-checkzone pour la configuration et la validation des zones. Cependant, ces outils sont limités à la syntaxe et à la légère cohérence. Ce rôle ne fournit pas de méthodes de validation avancées.
• Échapper les caractères spéciaux comme @ avec des guillemets.
• Certaines déclarations nécessitent des valeurs de chaîne "yes|no" : Échapper yes et no avec des guillemets car Ansible les évalue comme boolean.

La clause Options

Remarque : Le rôle est livré avec certaines options par défaut.

Définir les déclarations d'options

Lors de l'appel à manage-bind, vous pouvez passer des déclarations d'options :

• dans un fichier YAML externe déclaré avec options_file.
  • il doit contenir un mappage de déclarations appelé options.
• dans un mappage appelé options à l'intérieur de votre playbook.

Remarque : La première méthode exclut la seconde : le rôle ne chargera que les déclarations du fichier si vous le déclarez dans votre playbook.

playbook.yml:

- hosts: dnsserver
  become: yes
  roles:
    - role: aalaesar.manage-bind
      options_file: ./files/options.yml # le rôle ne chargera que ces options
      options: # les lignes suivantes sont inutiles dans ce cas
        statement1: ...
        statement2: ...

./files/options.yml:

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

La liste de toutes les déclarations disponibles pour les options se trouve dans ./tests/bind_options.yml

Changer les options par défaut du rôle :

Elles sont définies dans ./defaults/default_options.yml

Vous pouvez utiliser ce fichier pour partager une politique commune dans votre infrastructure et remplacer facilement des options spécifiques.

Clauses de Zones

Les clauses de zone sont définies avec déclaration et enregistrements de zone.

Déclaration de zone

Chaque zone est déclarée comme un élément de la liste nommée zones.

'zones' doivent être définies dans le playbook et est obligatoire.

playbook.yml:

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

Définir les déclarations de zone

Une zone est un mappage où le nom de la zone est sa clé principale et ses déclarations sont des clés:valeur

• [déclaration]:valeur
• type est une déclaration obligatoire.
• force_file [boolean] : Indique à Ansible de réécrire le fichier de base de données des enregistrements. Utile si votre zone est remplie dynamiquement par DNS. - false pour les zones esclaves - true pour les autres.
• Certains types de zones ont leurs propres déclarations obligatoires.

playbook.yml:

zones:
  example.com: # Le nom du domaine
    type: master # Obligatoire. Le type de la zone : master|slave|forward|stub
    recursion: "no" # déclaration remplaçant l'option globale "recursion" pour cette zone.
    ... # etc

La liste de toutes les déclarations de zone disponibles se trouve dans ./tests/zone_statements.md

Définir les enregistrements de la zone

Les enregistrements de la zone sont définis dans un mappage nommé 'records'.

Ce mappage 'records' peut être déclaré :

• dans un fichier YAML spécifié dans la clé yamlfile.
• comme un mappage à l'intérieur de son propre mappage de zone.

Remarque : _Le contenu des fichiers YAML est combiné avec la configuration de la zone : Donc, en cas d'enregistrements en double, le contenu du fichier aura la priorité.

playbook.yml:

zones:
  example.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 # sera remplacé par le yamlfile
    ... # etc

Dans le fichier YAML, records doit être le mappage de niveau supérieur :

./files/test.tld.yml:

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

Ajouter des enregistrements dans la zone

Les enregistrements de zone ont différents types, ils sont déclarés par type à l'intérieur de records.

chaque type d'enregistrement est différent et suit sa propre structure YAML.

Manage-bind supporte les enregistrements suivants :

• SOA
• NS
• A
• AAAA
• MX
• SRV
• PTR
• CNAME
• DNAME
• TXT
• ttl peut être déclaré avec les enregistrements de la zone.

Dépendances

Aucune.

Exemples de Playbooks

Exemple de configuration :

• Vous possédez les zones example.tld, example.com et example.org.
• Vous avez 2 serveurs de noms : dnserver1 (11.22.33.44) & dnserver2 (55.66.77.88).
• dnserver1 est le maître de example.tld et l'esclave de example.com.
• dnserver2 est le maître de example.com et l'esclave de example.tld.
• example.tld est rempli dynamiquement par un serveur DHCP.

Playbook pour 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 pour 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

Fichier YAML pour example.com.yml sur 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

D'autres exemples sont disponibles dans le dossier de tests.

Licence

BSD