Rôle Ansible pour NSD

Ce rôle Ansible installe et configure NSD, un serveur DNS autoritaire. Il permet également de publier des zones DNS dans NSD.

Installation

Ce rôle est disponible sur Ansible Galaxy.

Caractéristiques

Ce rôle prend en charge NSD3 et NSD4, et permet de gérer la configuration de NSD ainsi que les fichiers de zones, en mode maître ou esclave, avec ou sans transfert de zone (TSIG).

Surtout, par rapport à d'autres rôles NSD, il a les caractéristiques suivantes :

• permet de stocker les données de zone dans des fichiers de zone "classiques", au lieu d'écrire les zones comme des variables Ansible.
• les fichiers de zone sont analysés comme des modèles Jinja, au cas où vous auriez besoin de quelque chose de dynamique.
• prend en charge les scénarios à la fois maître et esclave, ou même un mélange des deux (certaines zones fonctionnant comme maître et d'autres comme esclave sur le même serveur NSD).
• configuration NSD complètement générique (vous pouvez définir n'importe quel attribut de configuration supporté par NSD, il n'y a pas de liste codée en dur dans le rôle).
• prend en charge les transferts de zone : clés TSIG, notifications aux esclaves...
• flexible tout en étant simple à utiliser !

Cependant, il ne gère pas d'autres éléments comme la configuration du pare-feu ou les emails, et ne prend en charge que Debian pour l'instant.

Cas d'utilisation

Remarque : tous ces cas d'utilisation peuvent être utilisés indépendamment pour chaque zone ! C'est-à-dire qu'un seul serveur NSD peut être à la fois un maître pour example.com et un esclave pour example.org.

Multi-maître pur

Si tous vos serveurs DNS sont configurés avec Ansible, il s'agit de la configuration la plus simple : tous les serveurs sont des maîtres pour la zone, et les données de zone sont déployées à l'aide d'Ansible.

Dans cette configuration, il n'est pas nécessaire d'effectuer des transferts de zone basés sur DNS.

Multi-maître avec esclaves supplémentaires non configurés par ce rôle

Dans cette configuration, un ou plusieurs maîtres sont configurés à l'aide d'Ansible, comme dans le cas précédent. Cependant, un transfert de zone basé sur DNS est également mis en place pour permettre aux esclaves externes de récupérer les données de zone d'un maître. Chaque fois qu'Ansible met à jour une zone sur les maîtres, il informera NSD de notifier les esclaves.

Notez que dans cette configuration, il est de votre responsabilité de configurer correctement les esclaves (accepter les notifications de tous les maîtres et récupérer les données de zone d'un ou plusieurs maîtres).

Esclave uniquement

Dans cette configuration, les serveurs NSD sont simplement configurés comme des esclaves pour la zone. Dans ce cas, aucune donnée de zone n'est copiée sur les serveurs, car les données seront récupérées d'un maître externe à l'aide de mécanismes de transfert de zone DNS normaux.

Notez que dans cette configuration, il est de votre responsabilité de configurer correctement le maître (notifier les esclaves et autoriser les transferts de zone des esclaves).

Exigences

Ce rôle a été testé sur Debian (wheezy, jessie, stretch, buster, bullseye). Il pourrait éventuellement fonctionner sur d'autres systèmes avec quelques adaptations. Les patchs sont les bienvenus.

Ce rôle ne configure pas nsd-control car cela est déjà fait automatiquement par le package Debian. D'autres systèmes pourraient nécessiter une configuration via Ansible à la place.

Variables du rôle

Cela documente toutes les variables du rôle que vous pouvez définir dans vos playbooks. Consultez la fin de ce README pour un exemple complet.

Configuration du serveur

nsd_server_config [dict]

Dictionnaire de paires clé-valeur qui seront ajoutées à la section de configuration server: de NSD. Une valeur peut être soit une chaîne, soit une liste. Dans ce dernier cas, la valeur sera développée en plusieurs entrées de configuration.

Vous pouvez ajouter n'importe quelle option de configuration que vous souhaitez dans ce dictionnaire, mais assurez-vous qu'il s'agit d'une option de configuration comprise par NSD ! En tant que sécurité, le rôle demande à NSD de vérifier la configuration générée avant de continuer, mais cela ne sera pas fait lors de l'exécution de ansible-playbook --check.

nsd_local_server_config [dict]

La même syntaxe et sémantique que nsd_server_config. Cette deuxième variable est fournie pour faciliter l'ajout d'une configuration spécifique à une machine unique. Vous définiriez généralement nsd_server_config dans group_vars ou dans un playbook, tandis que nsd_local_server_config serait défini dans host_vars.

Clés TSIG

nsd_tsig_keys [list of dict]

Liste optionnelle de clés TSIG. Chaque clé TSIG doit être un dictionnaire avec les attributs suivants :

• tsig_keyname: nom de cette clé TSIG. Notez que dans une configuration DNS maître/esclave, le nom de la clé TSIG doit être le même sur le maître et les esclaves ! Ce nom est également utilisé pour faire référence aux clés TSIG depuis les variables de rôle nsd_primary_zones et nsd_secondary_zones. Obligatoire.
• tsig_secret: valeur codée en base64 de la clé. Obligatoire.
• tsig_algorithm: algorithme utilisé par la clé, par exemple hmac-md5. Obligatoire.

Zones principales

nsd_primary_zones [list of dict]

Liste des zones à servir comme maître. Chaque zone doit être un dictionnaire avec les attributs suivants :

• zone_name: nom de la zone, par exemple example.com ou 8.b.d.0.1.0.0.2.ip6.arpa.. Obligatoire.
• zone_filename: nom du fichier contenant les données de zone (recherché dans files/nsd/). Obligatoire.
• slaves: liste des esclaves DNS, le format est décrit ci-dessous. Facultatif.

Le format pour une entrée esclave est le suivant :

• ip: adresse IPv4 ou IPv6 de l'esclave DNS. Utilisée pour envoyer des messages "notify", et pour autoriser des transferts de zone depuis cette IP. Obligatoire.
• tsig_key: nom de la clé TSIG à utiliser lors de la communication avec cet esclave. Le nom doit correspondre au champ tsig_keyname d'une clé TSIG définie précédemment, voir ci-dessus. Facultatif.

Zones secondaires

nsd_secondary_zones [list of dict]

Liste des zones à servir comme esclaves. Chaque zone doit être un dictionnaire avec les attributs suivants :

• zone_name: nom de la zone, par exemple example.com ou 8.b.d.0.1.0.0.2.ip6.arpa.. Obligatoire.
• masters: liste des maîtres DNS, le format est décrit ci-dessous. Facultatif, mais une zone esclave est assez inutile sans maître.

Le format pour une entrée maître est le suivant :

• ip: adresse IPv4 ou IPv6 du maître DNS. Utilisée pour demander des transferts de zone, et pour autoriser des messages de notification. Obligatoire.
• tsig_key: nom de la clé TSIG à utiliser lors de la communication avec ce maître. Le nom doit correspondre au champ tsig_keyname d'une clé TSIG définie précédemment, voir ci-dessus. Facultatif.

Variables de configuration avancées

Ces variables ne devraient pas avoir besoin d'être modifiées dans la plupart des cas. Les variables sont présentées ici avec leur valeur par défaut.

nsd_local_zones_dir: files/nsd/

Répertoire local dans lequel chercher les fichiers de zone (les entrées zone_filename sont relatives à ce répertoire).

nsd_version: 4

La version de NSD. Utilisée pour ignorer des tâches ou des gestionnaires qui n'ont pas de sens selon la version.

nsd_service_name: "nsd"

Le nom du service init, utilisé pour redémarrer NSD.

nsd_pkg_name: "nsd"

Nom du package à installer.

nsd_control_program: "/usr/sbin/nsd-control"

Programme utilisé pour contrôler NSD, pour recharger, reconstruire, notifier...

nsd_config_dir: "/etc/nsd"

Répertoire où la configuration de NSD sera stockée.

nsd_zones_config_file: "/etc/nsd/zones.conf"

Nom du fichier de configuration qui contiendra la configuration des zones (il est ensuite inclus dans le fichier de configuration principal de NSD).

nsd_primary_zones_dir: "/etc/nsd/primary"

Répertoire où les fichiers de zone seront copiés par ce rôle.

nsd_secondary_zones_dir: "/etc/nsd/secondary"

Répertoire où les fichiers de zone esclave seront placés par NSD après un transfert de zone.

Exemples de playbook

Voici un exemple complet de playbook avec plusieurs clés TSIG et plusieurs zones DNS : la première zone est une zone principale sans esclave, la deuxième zone a deux esclaves, et la troisième zone est une zone secondaire avec deux maîtres.

- hosts: dnsservers
  roles:
    - nsd
  vars:
    nsd_server_config:
      verbosity: 2
      ip4-only: 'yes'
    nsd_tsig_keys:
    # Deux clés TSIG, utilisées dans la définition de la zone ci-dessous
      - tsig_keyname: "tsig-key.example.org"
        tsig_secret: "3znH//y866vzpOZdahYYUlWeiY4iidiJGFRX6CI6OkUBggRNYFpZAMvlYbtnUosiBVPsgghA6zT0TzOEX0vetQ=="
        tsig_algorithm: hmac-md5
      - tsig_keyname: "key-eu.org"
        tsig_secret: "t6ELXqsSLYl57iO2rxj+X9+DNpOV3exTBFWu9wS/3jI="
        tsig_algorithm: hmac-sha256
    nsd_primary_zones:
    # Zone maître sans esclave
      - zone_name: "example.com."
        zone_filename: "example.com.zone"
    # Zone maître avec deux esclaves, un double-pile avec une clé TSIG, et un simple-pile sans clé
      - zone_name: "example.org."
        zone_filename: "example.org.zone"
        slaves:
          - ip: 2001:db8:42:1337::1
            tsig_key: "tsig-key.example.org"
          - ip: 198.51.100.12
            tsig_key: "tsig-key.example.org"
          - ip: 203.0.113.8
    nsd_secondary_zones:
    # Zone esclave avec deux maîtres, le premier sans clé, le second avec une clé
      - zone_name: "example.eu.org"
        masters:
          - ip: 192.0.2.42
          - ip: 2001:db8:1234:5678::9
            tsig_key: "key-eu.org"

Aussi dans host_vars/ns1.yml :

nsd_local_server_config:
  ip-address: ['2001:db8:ffff::42', '203.0.113.199']

Les données de zone pour les deux zones principales doivent être stockées dans nsd_local_zones_dir (qui par défaut est files/nsd/ à la racine de votre répertoire ansible) :

# ls files/nsd/
example.org.zone   example.com.zone
# head -3 files/nsd/example.org.zone
$ORIGIN example.org
$TTL 3h
@  IN  SOA  ns1 root.example.org. (2017090101 1d 2h 4w 1h)

Vous pouvez utiliser le rendu Jinja dans vos fichiers de zone pour générer des enregistrements dynamiques.

Exemple de configuration avancée

Si vous avez besoin de personnalisation plus avancée, vous pouvez utiliser les variables avancées. Par exemple, pour prendre en charge NSD3 sur Debian wheezy, la configuration appropriée était :

nsd_version: 3
nsd_service_name: "nsd3"
nsd_pkg_name: "nsd3"
nsd_control_program: "/usr/sbin/nsdc"
nsd_config_dir: "/etc/nsd3"
nsd_zones_config_file: "/etc/nsd3/zones.conf"
nsd_primary_zones_dir: "/etc/nsd3/primary"
nsd_secondary_zones_dir: "/etc/nsd3/secondary"

Cela pourrait être placé dans un fichier group_vars/wheezy.yml ou équivalent.

Limitations

Pour une zone donnée, toutes les machines utilisant ce rôle doivent être soit toutes maîtres, soit toutes esclaves.

Cela simplifie grandement la configuration, et il n'est généralement pas nécessaire d'avoir des maîtres et des esclaves pour la même zone gérés par Ansible, car Ansible peut simplement pousser les données de zone à tous les serveurs (donc, ils peuvent tous être maîtres).

Vous pourriez contourner cette limitation en appelant simplement ce rôle plusieurs fois avec des machines et des configurations différentes.

Il existe des cas où avoir plusieurs maîtres dont la zone est poussée par Ansible ne serait probablement pas souhaitable :

• enregistrements DNS dynamiques (qui ne sont de toute façon pas pris en charge par NSD)
• DNSSEC (je n’ai pas d'expérience avec DNSSEC, les contributions sont les bienvenues)

Licence

MIT