systemli.bind9

Rôle Ansible pour installer et maintenir le serveur de noms Bind9 sur Debian

Ce rôle installe et configure le serveur de noms Bind9 sur Debian.

Fonctionnalités :

Prise en charge de la configuration d'un serveur de noms autoritaire pour les zones DNS et/ou d'un résolveur DNS
Support étendu de DNSSEC :
- création automatique des clés KSK et ZSK
- configuration automatique de la zone DNSSEC
- support pour envoyer des sorties formatées DNSKEY/DS via XMPP
Prise en charge de la configuration de serveurs principaux cachés et secondaires autoritaires
Prise en charge des zones "statiques", c'est-à-dire les zones définies en téléchargeant leur fichier .db brut de Bind
Vérification de validité des fichiers de zone avec named-checkzone
Support de base pour les zones "dynamiques", c'est-à-dire définies par des ensembles de variables YAML

Configuration de base du serveur

Serveur principal

Définissez des variables pour votre serveur principal, par exemple dans host_vars/master_name/vars/XX_bind.yml, ici avec une zone statique example.com et un serveur de redirection :

bind9_authoritative: yes
bind9_zones_static: 
- { name: example.com , type=master }
bind9_forward: yes
bind9_forward_servers:
- 8.8.8.8
- 4.4.4.4
bind9_slaves:
- slave_ip_1
- slave_ip_2
- slave_ip_3
bind9_our_neighbors:
- slave_ip_1
- slave_ip_2
- slave_ip_3

Placez votre fichier de zone BIND dans le répertoire ansible (pas dans le répertoire du rôle) : files/bind/zones/db.example.com

Serveurs esclaves

Définissez des variables pour vos serveurs esclaves :

bind9_zones_static: 
- { name: example.com, type: slave }
bind9_forward: yes
bind9_forward_servers:
- 8.8.8.8
- 4.4.4.4
bind9_masters:
- { name: master_name, addresses: [master_ip] }
bind9_recursor: our_network

Zones dynamiques

Les enregistrements des zones "dynamiques" sont définis par la variable YAML ansible bind9_zones_dynamic, qui est analysée par le modèle bind/zones/db.template.j2. Comme il peut y avoir plusieurs zones et que les définitions de zones peuvent être longues, il est préférable de définir les variables de zone dans un fichier de variables différent, par exemple host_vars/master_name/vars/YY_zones.yml. bind9_zones_dynamic peut être divisé en plusieurs variables, qui peuvent être définies dans des fichiers spécifiques, comme dans l'exemple ci-dessous.

Dans YY_zones.yml nous pouvons avoir :

bind9_zones_dynamic: >
        {{ zones_my_domains
        | union ( zone_my_reverse_inaddr_arpa )
        | union ( zone_my_reverse_ip6_arpa ) }}

# bind9_zone_static:  fichiers de zone copiés depuis `files/bind/zones/`

bind9_zones_static:
- name: static_dom.org
  type: master
- name: static_dom2.org
  type: master
- name: static_dom3.org
  type: slave

Et dans d'autres fichiers de variables :

zones_my_domains:
# Ceci est l'ensemble de variables pour mon domaine
- name: dyn_domain.org
  type: master
  default_ttl: 600
  serial: 2022050501
  refresh: 1D
  retry: 2H
  expire: 1000H
  # Les valeurs des enregistrements NS et autres doivent être données sous forme de noms de domaine pleinement qualifiés, avec ou sans point final, mais pas relatifs à la zone
  primary: ns1.dyn_domain.org         # Optionnel, si vous ne le définissez pas, le premier NS est pris
  admin: postmaster.dyn_domain.org
  ns_records:
  - ns1.dyn_domain.org
  - ns2.dyn_domain.org
  # Les valeurs RR sont soit relatives à la zone, soit avec un point final quand elles sont à l'extérieur.
  rrs:
  - {label: "@", type: MX, rdata: 10 mail}
  - {label: webmail, type: CNAME, rdata: mail}
  - {label: "@", type: A, rdata: 8.8.8.221}
  - {label: "@", type: AAAA, rdata: 2001:db8:6a::95}
  - {label: www, type: CNAME, rdata: webserver.dyn_domain.org.}
  - {label: mail, type: A, rdata: 8.8.8.222}
  - {label: mail, type: AAAA, rdata: 2001:db8:6a::22}
  - {label: webserver, ttl: 86400, type: A, rdata: 8.8.8.223}
  - {label: webserver, ttl: 86400, type: AAAA, rdata: 2001:db8:6a::23}

Et de même pour zone_my_reverse_inaddr_arpa et zone_my_reverse_ip6_arpa pour la résolution DNS inverse IP. Notez que nous avons adopté pour les enregistrements NS génériques la terminologie définie dans RFC 1034, Section 3.6

déployez le rôle sur vos serveurs

Mises à jour DDNS

Génération de clés

Si vous souhaitez que vos clés DDNS soient créées par ce rôle, configurez bind9_generate_ddns_key :

-  bind9_generate_ddns_key: true

Les clés seront par défaut stockées dans files/bind/zones au sein de l'emplacement de votre playbook, mais vous pouvez personnaliser cela avec bind9_local_keydir

-  bind9_local_keydir: credentials/bind

Base de données de zones

Veuillez noter que pour que les mises à jour DDNS fonctionnent, l'emplacement des fichiers de zone doit être accessible en écriture par le processus BIND. Les distributions Linux avec un Contrôle d'Accès Mandatoire (Apparmor, SELinux) n'autorisent généralement pas l'écriture dans le chemin par défaut /etc/bind/zones. Pour contourner cela, vous pouvez vouloir changer l'emplacement des fichiers de zone en /var/lib/bind/zones à la place :

-  bind9_zonedir: /var/lib/bind/zones

Dépendances

Pour la fonctionnalité de notification XMPP, python-xmpp doit être installé.

Variables du rôle

Consultez defaults/main.yml pour une liste des variables du rôle.

Tests et Développement

Tests

Pour développer et tester le rôle, nous utilisons Github Actions, Molecule et Vagrant. Dans l'environnement local, vous pouvez facilement tester le rôle avec

Exécutez des tests locaux avec :