Ansible Rolle: manage-bind 2.0

Diese Rolle wurde als Abstraktionsschicht entwickelt, um Bind zu konfigurieren und DNS-Zonen mithilfe von YAML-Syntax zu erstellen.

• Installieren und Verwalten Ihres Bind9-Servers auf Debian/Ubuntu-Servern.
• Verwenden Sie YAML-Syntax/Dateien, um Bind-Optionen, Zonen usw. zu konfigurieren.

Anforderungen

Ansible 2.4+

Hinweis: Diese Rolle benötigt Root-Zugriff auf den Bind-Server.

playbook.yml:

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

Rollenvariablen

# Host-Konfiguration
bind_user:  bind
bind_group: bind
host_dns_srv: self
# Protokollverzeichnis
bind_log_dir: /var/log/bind
# Installationskonfiguration
bind_pkg_state: present
bind_pkgs: ['bind9', 'dnsutils']
bind_service_state: started
bind_service_enabled: yes
# Konfigurationen
bind_configs_dir: /etc/bind
bind_config_master_zones: []
bind_config_default_zones: 'yes'
RFC1918: no
# Zonen-Dateien
bind_zones_dir: /var/lib/bind
# Standardkonfiguration der Zonen
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

# Unmanaged Dateien entfernen, um den Server sauber zu halten
remove_unmanaged_files: true
# Liste der verwalteten Zonendateien initialisieren:
list_zone_files: []

Konfiguration von Bind

Einführung in die Konfiguration von Bind

Bind verwendet einen Mechanismus der Vererbung von Klauseln, um eine präzise Konfiguration zu ermöglichen.

• Eine Klausel ist eine Klasse mit ihrem eigenen Set von Aussagen.
  • Sie können spezifische oder gemeinsame Aussagen haben.
  • Eine innerhalb einer anderen Klausel definierte Klausel erbt implizit ihre gemeinsamen Aussagen.
• Eine Aussage ist eine Eigenschaft einer Klausel.
  • Sie beschreibt das Verhalten des Servers, wie eine Aufgabe ausgeführt wird, ob, wann usw.
  • Sie kann explizit oder implizit definiert werden.
• Einige Vererbungsregeln:
• Options ist die oberste Klausel, die alle anderen umfasst.
• zone ist die niedrigste Klausel. Sie kann keine Kinder haben. Sie enthält auch Zonenrecords.
• Eine Klausel kann die Aussage ihrer Eltern Klausel überschreiben und den neuen Wert an ihr(e) Kind(er) weitergeben, indem sie die Aussage explizit neu definiert.

  Hier ist ein ASCII-Beispiel dieser Regeln:

|##########|  
|  zone1   |  |#########|
|==========|  |  zone2  |
|statement1|  |=========|
|  =john   |  |         |
|##########|  |#########|
     /\            /\
     ||            ||
|#######################|   |##############|   |##############|
|         view1         |   |   zone3      |   |    zone4     |
|=======================|   |==============|   |              |
|  statement2=kangaroo  |   |statement1=bar|   |##############|
|#######################|   |##############|          /\
           /\                     /\                  ||
           ||                     ||                  ||
|#############################################################|
|                          Optionen                            |
|=============================================================|
|                       statement1=foo                        |
|                      statement2=koala                       |
|#############################################################|
Endergebnis:
Laut Aussage1 & Aussage2 sind allgemein gültig für alle Klauseln.
zone1: statement1=john, statement2=kangaroo
zone2: statement1=foo, statement2=kangaroo
zone3: statement1=bar, statement2=koala
zone4: statement1=foo, statement2=koala

manage-bind unterstützt die folgenden Klauseln:

• options
• zone
• key

Die Liste der unterstützten Aussagen: Siehe ./vars/main.yml

TODO: views

Vorsicht beim Definieren einer Aussage!

• Einige Aussagen sind mit komplexen Zuordnungen definiert, während andere nur einen einfachen Wert benötigen. Für den Fall, dass jede Aussage ihre eigene selbstdokumentierte Vorlage hat.
• manage-bind verwendet die Bind-Tools named-checkconf und named-checkzone zur Konfiguration und Zonenvalidierung. Diese Tools sind jedoch auf Syntax und leichte Kohärenz Überprüfung beschränkt. Diese Rolle bietet keine fortgeschrittenen Validierungsmethoden.
• Escape-Sonderzeichen wie @ mit Anführungszeichen.
• Einige Aussagen erfordern die Werte "ja|nein": Escape ja und nein mit Anführungszeichen, da Ansible diese als boolesch wertet.

Die Options-Klausel

Hinweis: Die Rolle kommt mit einigen Standardoptionen.

Definieren von Optionsaussagen

Beim Aufrufen von manage-bind können Sie Optionsaussagen übergeben:

• in einer externen YAML-Datei, die mit options_file deklariert ist.
  • sie muss eine Zuordnung von Aussagen namens options enthalten.
• in einer Zuordnung namens options innerhalb Ihres Playbooks.

Hinweis: Die erste Methode schließt die zweite aus: Die Rolle lädt nur die Aussagen in der Datei, wenn Sie sie in Ihrem Playbook deklarieren.

playbook.yml:

- hosts: dnsserver
  become: yes
  roles:
    - role: aalaesar.manage-bind
      options_file: ./files/options.yml # die Rolle lädt nur diese Optionen
      options: # die nächsten Zeilen sind in diesem Fall nutzlos
        statement1: ...
        statement2: ...

./files/options.yml:

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

Die Liste aller Optionen verfügbaren Aussagen befindet sich in ./tests/bind_options.yml.

Ändern der Standardeinstellungen der Rolle:

Sie sind in ./defaults/default_options.yml definiert.

Sie können diese Datei verwenden, um eine gemeinsame Richtlinie über Ihre Infrastruktur zu teilen und spezifische Optionen einfach zu überschreiben.

Zonen-Klauseln

Zonen-Klauseln werden mit Aussage und Zonenrecords definiert.

Zonen-Deklaration

Jede Zone wird als Element der Liste namens zones deklariert.

'zones' müssen im Playbook definiert werden und sind verpflichtend.

playbook.yml:

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

Definieren von Zonen-Aussagen

Eine Zone ist eine Zuordnung, bei der der Zonenname der Hauptschlüssel ist und ihre Aussagen die Schlüssel:Werte sind.

• [Aussage]:Wert
• type ist eine obligatorische Aussage.
• force_file [boolesch]: Sagt Ansible, dass die Datensatzdatei neu geschrieben werden soll. Nützlich, wenn Ihre Zone dynamisch über DNS befüllt wird. - false für Slave-Zonen - true für andere.
• Einige Zonentypen haben ihre eigenen obligatorischen Aussagen.

playbook.yml:

zones:
  example.com: # Der Name der Domain
    type: master # Obligatorisch. Der Typ der Zone: master|slave|forward|stub
    recursion: "no" # Aussage überschrieb die globale Option "recursion" für diese Zone.
    ... # usw.

Die Liste aller verfügbaren Zonen-Aussagen befindet sich in ./tests/zone_statements.md.

Definieren von Zonenrecords

Die ZonenRecords werden in einer Zuordnung namens 'records' definiert.

Diese Zuordnungen 'records' können deklariert werden:

• in einer YAML-Datei, die im yamlfile Schlüssel angegeben ist.
• als Zuordnung innerhalb der Zuordnung seiner Zone.

Hinweis: Der Inhalt der YAML-Dateien wird mit der Zonenkonfiguration kombiniert: Also, im Falle von Duplikaten gelten die Dateiinhalte Priorität.

playbook.yml:

zones:
  example.com:
    records:
      SOA: ...
      NS: ...
      ... # usw.
    ... # usw.
  test.tld:
    yamlfile: "./files/test.tld.yml"
    records:
      SOA: ...
      NS: ...
      A:
       localhost: 127.0.0.1
       test1: 9.8.7.6 # wird von der yamlfile überschrieben.
    ... # usw.

In der YAML-Datei müssen records eine Zuordnung auf oberster Ebene sein:

./files/test.tld.yml:

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

Hinzufügen von Records in die Zone

Zonenrecords haben unterschiedliche Typen, sie sind je nach Typ innerhalb records deklariert.

Jeder Recordtyp ist anders und folgt seiner eigenen YAML-Struktur.

Manage-bind unterstützt die folgenden Records:

• SOA
• NS
• A
• AAAA
• MX
• SRV
• PTR
• CNAME
• DNAME
• TXT
• TTL kann zusammen mit den Zonenrecords deklariert werden.

Abhängigkeiten

Keine.

Beispiel-Playbooks

Beispielkonfiguration:

• Sie besitzen die Zonen example.tld, example.com und example.org.
• Sie haben 2 Nameserver: dnserver1 (11.22.33.44) & dnserver2 (55.66.77.88).
• dnserver1 ist Master von example.tld und Slave von example.com.
• dnserver2 ist Master von example.com und Slave von example.tld.
• example.tld wird dynamisch von einem DHCP-Server befüllt.

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

YAML-Datei für example.com.yml auf 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

Weitere Beispiele sind im Tests-Ordner verfügbar.

Lizenz

BSD