Ansible-Rolle für NSD

Diese Ansible-Rolle installiert und konfiguriert NSD, einen autoritativen DNS-Server. Sie ermöglicht auch die Veröffentlichung von DNS-Zonen in NSD.

Installation

Diese Rolle ist auf Ansible Galaxy verfügbar.

Funktionen

Diese Rolle unterstützt sowohl NSD3 als auch NSD4 und ermöglicht die Verwaltung von NSD-Konfigurationen und Zonendateien, im Master- oder Slave-Modus, mit oder ohne Zonenübertragung (TSIG).

Im Vergleich zu anderen NSD-Rollen (elnappo, reallyenglish, creicm, adarnimrod, hudecof) hat sie folgende Merkmale:

• Ermöglicht die Speicherung von Zoneninformationen in "klassischen" Zonendateien, anstatt Zonen als Ansible-Variablen zu schreiben wie hier
• Zonendateien werden als Jinja-Vorlagen geparst, falls etwas Dynamisches benötigt wird
• Unterstützt sowohl Master- als auch Slave-Szenarien oder sogar eine Mischung aus beiden (einige Zonen laufen als Master und andere als Slave auf demselben NSD-Server)
• Vollständig generische NSD-Konfiguration (Sie können jede Konfigurationsoption definieren, die von NSD unterstützt wird, es gibt keine festgelegte Liste in der Rolle). Dies ähnelt hier, hat jedoch eine einfachere Syntax (automatische Erweiterung von Listen)
• Unterstützt Zonenübertragungen: TSIG-Schlüssel, Benachrichtigung der Slaves...
• Hoffentlich flexibel und dennoch einfach zu bedienen!

Sie behandelt jedoch keine anderen Dinge wie die Konfiguration der Firewall oder E-Mails und unterstützt vorerst nur Debian.

Anwendungsfälle

Hinweis: Alle diese Anwendungsfälle können unabhängig für jede Zone verwendet werden! Das heißt, ein einzelner NSD-Server kann sowohl ein Master für example.com als auch ein Slave für example.org sein.

Reines Multi-Master

Wenn alle Ihre DNS-Server mit Ansible konfiguriert sind, ist dies die einfachste Einrichtung: Alle Server sind Master für die Zone, und die Zoneninformationen werden mit Ansible bereitgestellt.

In dieser Konfiguration ist keine DNS-basierte Zonenübertragung erforderlich.

Multi-Master mit zusätzlichen Slaves, die nicht mit dieser Rolle konfiguriert sind

In dieser Konfiguration werden eine oder mehrere Master mit Ansible konfiguriert, wie im vorherigen Anwendungsfall. Es wird jedoch auch eine DNS-basierte Zonenübertragung eingerichtet, um externen Slaves zu ermöglichen, Zoneninformationen von einem Master abzurufen. Jedes Mal, wenn Ansible eine Zone auf den Mastern aktualisiert, wird NSD informiert, um die Slaves zu benachrichtigen.

Bitte beachten Sie, dass in dieser Konfiguration Ihre Verantwortung darin besteht, die Slaves entsprechend zu konfigurieren (Benachrichtigung von allen Mastern annehmen und Zoneninformationen von einem oder mehreren Mastern abrufen).

Nur Slave

In dieser Konfiguration werden die NSD-Server einfach als Slaves für die Zone konfiguriert. In diesem Fall werden keine Zoneninformationen auf die Server kopiert, da die Informationen von einem externen Master mit normalen DNS-Zonenübertragungsmechanismen abgerufen werden.

Bitte beachten Sie, dass in dieser Konfiguration Ihre Verantwortung darin besteht, den Master entsprechend zu konfigurieren (benachrichtigen Sie die Slaves und erlauben Sie Zonenübertragungen von den Slaves).

Anforderungen

Diese Rolle wurde auf Debian (wheezy, jessie, stretch, buster, bullseye) getestet. Sie könnte möglicherweise auch auf anderen Systemen mit einigen Anpassungen funktionieren. Patches sind willkommen.

Diese Rolle richtet nsd-control nicht ein, da dies bereits automatisch durch das Debian-Paket erfolgt. Andere Systeme müssen es möglicherweise stattdessen über Ansible einrichten.

Rollenvairablen

Dies dokumentiert alle Rollenvairablen, die Sie in Ihren Playbooks setzen können. Am Ende dieser README finden Sie ein vollständiges Beispiel.

Serverkonfiguration

nsd_server_config [dict]

Ein Dictionary von Schlüssel-Wert-Paaren, die zum Konfigurationsabschnitt server: von NSD hinzugefügt werden. Ein Wert kann entweder eine Zeichenfolge oder eine Liste sein. Im letzteren Fall wird der Wert in mehrere Konfigurationseinträge erweitert.

Sie können jede gewünschte Konfigurationsoption in diesem Dictionary hinzufügen, aber stellen Sie sicher, dass sie eine Konfigurationsoption ist, die von NSD verstanden wird! Als Sicherheitsnetz fordert die Rolle NSD auf, die generierte Konfiguration vor dem Fortfahren zu überprüfen. Dies geschieht jedoch nicht, wenn ansible-playbook --check ausgeführt wird.

nsd_local_server_config [dict]

Gleiche Syntax und Semantik wie nsd_server_config. Diese zweite Variable wird bereitgestellt, um es einfacher zu machen, spezifische Konfigurationen für eine einzelne Maschine hinzuzufügen. Normalerweise würden Sie nsd_server_config in group_vars oder in einem Playbook definieren, während nsd_local_server_config in host_vars definiert werden würde.

TSIG-Schlüssel

nsd_tsig_keys [list of dict]

Optionale Liste von TSIG-Schlüsseln. Jeder TSIG-Schlüssel muss ein Dictionary mit den folgenden Attributen sein:

• tsig_keyname: Name dieses TSIG-Schlüssels. Bitte beachten Sie, dass der Name des TSIG-Schlüssels in einer Master/Slave-DNS-Konfiguration auf Master und Slaves gleich sein muss! Dieser Name wird auch verwendet, um auf TSIG-Schlüssel von den Rollenvairablen nsd_primary_zones und nsd_secondary_zones zuzugreifen. Verpflichtend.
• tsig_secret: Base64-kodierter Wert des Schlüssels. Verpflichtend.
• tsig_algorithm: Algorithmus, der von dem Schlüssel verwendet wird, zum Beispiel hmac-md5. Verpflichtend.

Primäre Zonen

nsd_primary_zones [list of dict]

Liste von Zonen, die als Master bereitgestellt werden sollen. Jede Zone muss ein Dictionary mit den folgenden Attributen sein:

• zone_name: Name der Zone, zum Beispiel example.com oder 8.b.d.0.1.0.0.2.ip6.arpa.. Verpflichtend.
• zone_filename: Name der Datei, die die Zoneninformationen enthält (wird nach files/nsd/ durchsucht). Verpflichtend.
• slaves: Liste von DNS-Slaves, das Format wird weiter unten beschrieben. Optional.

Das Format für einen Slave-Eintrag ist folgendes:

• ip: IPv4- oder IPv6-Adresse des DNS-Slaves. Wird verwendet, um "Benachrichtigen"-Nachrichten zu senden und um Zonenübertragungen von dieser IP zuzulassen. Verpflichtend.
• tsig_key: Name des TSIG-Schlüssels, der bei der Kommunikation mit diesem Slave verwendet werden soll. Der Name muss dem Feld tsig_keyname eines zuvor definierten TSIG-Schlüssels entsprechen, siehe oben. Optional.

Sekundäre Zonen

nsd_secondary_zones [list of dict]

Liste von Zonen, die als Slave bereitgestellt werden sollen. Jede Zone muss ein Dictionary mit den folgenden Attributen sein:

• zone_name: Name der Zone, zum Beispiel example.com oder 8.b.d.0.1.0.0.2.ip6.arpa.. Verpflichtend.
• masters: Liste von DNS-Mastern, das Format wird weiter unten beschrieben. Optional, aber eine Slave-Zone ist ohne Master ziemlich nutzlos.

Das Format für einen Master-Eintrag ist folgendes:

• ip: IPv4- oder IPv6-Adresse des DNS-Masters. Wird verwendet, um Zonenübertragungen anzufordern und um Benachrichtigungsnachrichten zuzulassen. Verpflichtend.
• tsig_key: Name des TSIG-Schlüssels, der bei der Kommunikation mit diesem Master verwendet werden soll. Der Name muss dem Feld tsig_keyname eines zuvor definierten TSIG-Schlüssels entsprechen, siehe oben. Optional.

Erweiterte Konfigurationsvariablen

Diese Variablen sollten in den meisten Fällen nicht verändert werden müssen. Variablen werden hier mit ihrem Standardwert präsentiert.

nsd_local_zones_dir: files/nsd/

Lokales Verzeichnis, in dem nach Zonendateien gesucht wird (zone_filename-Einträge sind relativ zu diesem Verzeichnis).

nsd_version: 4

Die Version von NSD. Wird verwendet, um Aufgaben oder Handler zu überspringen, die je nach Version keinen Sinn machen.

nsd_service_name: "nsd"

Der Name des Init-Dienstes, der verwendet wird, um NSD neu zu starten.

nsd_pkg_name: "nsd"

Name des zu installierenden Pakets.

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

Programm zur Steuerung von NSD, für Neuladen, Wiederherstellung, Benachrichtigung...

nsd_config_dir: "/etc/nsd"

Verzeichnis, in dem die NSD-Konfiguration gespeichert wird.

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

Name der Konfigurationsdatei, die die Zonen-Konfiguration enthält (sie wird dann aus der Hauptkonfigurationsdatei von NSD inkludiert).

nsd_primary_zones_dir: "/etc/nsd/primary"

Verzeichnis, in das die Zoneninformationen von dieser Rolle kopiert werden.

nsd_secondary_zones_dir: "/etc/nsd/secondary"

Verzeichnis, in dem die Slave-Zonendateien von NSD nach der Zonenübertragung abgelegt werden.

Beispiel-Playbook

Dies ist ein vollständiges Beispiel-Playbook mit mehreren TSIG-Schlüsseln und mehreren DNS-Zonen: Die erste Zone ist eine primäre Zone ohne Slave, die zweite Zone hat zwei Slaves und die dritte Zone ist eine sekundäre Zone mit zwei Mastern.

- hosts: dnsservers
  roles:
    - nsd
  vars:
    nsd_server_config:
      verbosity: 2
      ip4-only: 'ja'
    nsd_tsig_keys:
    # Zwei TSIG-Schlüssel, die in der Zonenbeschreibung unten verwendet werden
      - 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:
    # Master-Zone ohne Slave
      - zone_name: "example.com."
        zone_filename: "example.com.zone"
    # Master-Zone mit zwei Slaves, einer dual-stacked mit einem TSIG-Schlüssel und einer single-stacked ohne Schlüssel
      - 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:
    # Slave-Zone mit zwei Mastern, der erste ohne Schlüssel, der zweite mit Schlüssel
      - zone_name: "example.eu.org"
        masters:
          - ip: 192.0.2.42
          - ip: 2001:db8:1234:5678::9
            tsig_key: "key-eu.org"

Auch in host_vars/ns1.yml:

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

Die Zoneninformationen für die beiden primären Zonen müssen in nsd_local_zones_dir gespeichert werden (standardmäßig files/nsd/ im Root-Verzeichnis Ihres Ansible-Verzeichnisses):

# 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)

Sie können Jinja-Templating in Ihren Zonendateien verwenden, um dynamische Datensätze zu generieren.

Beispiel für eine erweiterte Konfiguration

Wenn Sie eine ausgefeiltere Anpassung benötigen, können Sie die erweiterten Variablen verwenden. Zum Beispiel, um NSD3 unter Debian Wheezy zu unterstützen, war die passende Konfiguration:

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"

Dies könnte in einer Datei group_vars/wheezy.yml oder ähnlichem platziert werden.

Einschränkungen

Für eine gegebene Zone müssen alle Maschinen, die diese Rolle verwenden, entweder alle Master oder alle Slaves sein.

Dies vereinfacht die Konfiguration erheblich, und es ist normalerweise nicht erforderlich, dass Master und Slaves für die gleiche Zone von Ansible verwaltet werden, da Ansible einfach die Zoneninformationen an alle Server pushen kann (sodass sie alle Master sein können).

Sie könnten diese Einschränkung umgehen, indem Sie diese Rolle einfach mehrmals mit unterschiedlichen Maschinen und unterschiedlichen Konfigurationen aufrufen.

Es gibt Fälle, in denen es wahrscheinlich nicht wünschenswert wäre, mehrere Master zu haben, deren Zone von Ansible gepusht wird:

• dynamische DNS-Einträge (die ohnehin von NSD nicht unterstützt werden)
• DNSSEC (ich habe keine Erfahrung mit DNSSEC, Beiträge sind willkommen)

Lizenz

MIT