bertvv.bind

Ansible-Rolle BIND

Eine Ansible-Rolle zur Einrichtung von ISC BIND als ausschließlich autoritativen DNS-Server für mehrere Domains. Die Aufgaben dieser Rolle sind:

Installation von BIND
Einrichtung der Hauptkonfigurationsdatei (Primär-/Sekundär-/Weiterleitungsserver)
Einrichtung von Forward- und Reverse-Lookup-Zonendateien

Diese Rolle unterstützt mehrere Forward- und Reverse-Zonen, einschließlich IPv6. Auch wenn das Aktivieren von Rekursion unterstützt wird (was sehr davon abgeraten wird), sollten Sie eine andere Rolle verwenden, wenn Sie einen Caching- oder Weiterleitungs-DNS-Server einrichten möchten.

Wenn Ihnen diese Rolle gefällt oder Sie sie verwenden, ziehen Sie bitte in Betracht, sie zu bewerten und auf der Ansible Galaxy-Seite der Rolle einen Stern zu vergeben. Danke!

Siehe das Änderungsprotokoll für bemerkenswerte Änderungen zwischen den Versionen.

WARNUNG: Wenn Sie diese Rolle vor v5.0.0 verwendet haben, überprüfen Sie das Änderungsprotokoll auf wichtige Informationen zu brechenden Änderungen. Alte Playbooks werden fehlschlagen, wenn Sie auf v5.0.0 aktualisieren.

Unterstützte Plattformen

Diese Rolle kann auf mehreren Plattformen verwendet werden; siehe meta/main.yml für eine aktualisierte Liste. Wir bemühen uns, automatisierte Tests für jede unterstützte Plattform einzurichten (siehe .ci.yml), aber dies ist nicht immer möglich.

Einige Anmerkungen zu unterstützten Rollen, die nicht in automatisierte Tests einbezogen sind:

Arch Linux und FreeBSD sollten funktionieren, aber derzeit ist es nicht möglich, die Rolle auf diesen Distributionen zu testen, da keine geeigneten Docker-Images verfügbar sind.
CentOS 6 sollte funktionieren, aber Idempotenztests schlagen fehl, selbst wenn BIND erfolgreich installiert wurde und Akzeptanztests erfolgreich sind.

Anforderungen

Die Pakete python-netaddr (benötigt für den ipaddr Filter) und dnspython sollten auf dem Verwaltungsrechner installiert sein.

Rollenvariablen

Variable	Standard	Kommentare (Typ)
`bind_acls`	`[]`	Eine Liste von ACL-Definitionen, die Zuordnungen mit den Schlüsseln `name:` und `match_list:` sind. Unten finden Sie ein Beispiel.
`bind_allow_query`	`['localhost']`	Eine Liste von Hosts, die erlaubt sind, diesen DNS-Server abzufragen. Setzen Sie sie auf ['any'], um allen Hosts Zugriff zu gewähren.
`bind_allow_recursion`	`['any']`	Ähnlich wie `bind_allow_query`, diese Option gilt für rekursive Abfragen.
`bind_check_names`	`[]`	Überprüfen Sie Hostnamen auf Übereinstimmung mit RFC 952 und RFC 1123 und ergreifen Sie die definierte Maßnahme (z. B. `warn`, `ignore`, `fail`).
`bind_dns_keys`	`[]`	Eine Liste von Binding-Schlüsseln, die Zuordnungen mit den Schlüsseln `name:`, `algorithm:` und `secret:` sind. Unten finden Sie ein Beispiel.
`bind_dns64`	`false`	Wenn `true`, wird die Unterstützung für DNS64 aktiviert.
`bind_dns64_clients`	`['any']`	Eine Liste von Clients, auf die die DNS64-Funktion angewendet wird (kann jede ACL sein).
`bind_dnssec_enable`	`true`	Wenn `true`, ist DNSSEC aktiviert.
`bind_dnssec_validation`	`true`	Wenn `true`, wird die DNSSEC-Überprüfung aktiviert.
`bind_extra_include_files`	`[]`	Eine Liste von benutzerdefinierten Konfigurationsdateien, die aus der Hauptkonfigurationsdatei einbezogen werden sollen.
`bind_forward_only`	`false`	Wenn `true`, wird BIND als Caching-Nameserver eingerichtet.
`bind_forwarders`	`[]`	Eine Liste von Nameservern, an die DNS-Anfragen weitergeleitet werden sollen.
`bind_listen_ipv4`	`['127.0.0.1']`	Eine Liste der IPv4-Adressen der Netzwerk-Schnittstelle(n), auf denen zugehört werden soll. Setzen Sie sie auf ['any'], um auf allen Schnittstellen zu hören.
`bind_listen_ipv4_port`	`[53]`	Eine Liste von Portnummern, auf denen für IPv4-Adressen zugehört werden soll.
`bind_listen_ipv6`	`['::1']`	Eine Liste der IPv6-Adressen der Netzwerk-Schnittstelle(n), auf denen zugehört werden soll.
`bind_listen_ipv6_port`	`[53]`	Eine Liste von Portnummern, auf denen für IPv6-Adressen zugehört werden soll.
`bind_log`	`data/named.run`	Pfad zur Logdatei.
`bind_other_logs`	-	Eine Liste von Protokollkanälen, die konfiguriert werden sollen, mit einer separaten Zuordnung für jede Zone und relevanten Details.
`bind_query_log`	-	Eine Zuordnung mit den Schlüsseln `file:` (z. B. `data/query.log`), `versions:`, `size:`. Wenn definiert, wird das Abfrageprotokoll aktiviert.
`bind_recursion`	`false`	Bestimmt, ob Anfragen, für die der DNS-Server nicht autoritativ ist, weitergeleitet werden sollen.
`bind_rrset_order`	`random`	Definiert die Reihenfolge für DNS-Round-Robin (entweder `random` oder `cyclic`).
`bind_statistics_channels`	`false`	Wenn `true`, wird BIND mit einer `statistics-channels` Klausel konfiguriert (derzeit nur Unterstützung für das Zuhören auf einer einzigen Schnittstelle).
`bind_statistics_allow`	`['127.0.0.1']`	Eine Liste von Hosts, die auf die Serverstatistik zugreifen können.
`bind_statistics_host`	`127.0.0.1`	IP-Adresse der Netzwerkschnittstelle, an der der Statistikdienst zuhören soll.
`bind_statistics_port`	8053	Netzwerkport, an dem der Statistikdienst zuhören soll.
`bind_zone_dir`	-	Wenn definiert, legt einen benutzerdefinierten absoluten Pfad zum Serververzeichnis (für Zonendateien usw.) anstelle des Standardpfads fest.
`bind_key_mapping`	[]	`Primary: Keyname` - Zuordnung von TSIG-Schlüsseln, die für einen bestimmten Primärserver verwendet werden sollen.
`bind_zones`	n/a	Eine Liste von Zuordnungen mit Zonen-Definitionen. Unten finden Sie Beispiele für diese Tabelle.
`- allow_update`	`['none']`	Eine Liste von Hosts, die berechtigt sind, diese DNS-Zone dynamisch zu aktualisieren.
`- also_notify`	-	Eine Liste von Servern, die eine Benachrichtigung erhalten, wenn die primäre Zonen-Datei neu geladen wird.
`- create_forward_zones`	-	Wenn initialisiert und auf `false` gesetzt, wird die Erstellung von Forward-Zonen übersprungen (wodurch eine nur rückwärts gerichtete Zone entsteht).
`- create_reverse_zones`	-	Wenn initialisiert und auf `false` gesetzt, wird die Erstellung von Rückwärts-Zonen übersprungen (wodurch eine nur vorwärts gerichtete Zone entsteht).
`- delegate`	`[]`	Zonendelegation.
`- forwarders`	-	Liste von Forwardern für die Forward-Zone.
`- hostmaster_email`	`hostmaster`	Die E-Mail-Adresse des Systemadministrators für die Zone.
`- hosts`	`[]`	Host-Definitionen.
`- ipv6_networks`	`[]`	Eine Liste der IPv6-Netzwerke, die Teil der Domain sind, im CIDR-Notation (z.B. 2001:db8::/48).
`- mail_servers`	`[]`	Eine Liste von Zuordnungen (mit den Schlüsseln `name:` und `preference:`), die die Mail-Server für diese Domain angeben.
`- name_servers`	`[ansible_hostname]`	Eine Liste der DNS-Server für diese Domain.
`- name`	`example.com`	Der Domainname.
`- naptr`	`[]`	Eine Liste von Zuordnungen mit den Schlüsseln `name:`, `order:`, `pref:`, `flags:`, `service:`, `regex:` und `replacement:`, die NAPTR-Datensätze angeben.
`- networks`	`['10.0.2']`	Eine Liste der Netzwerke, die Teil der Domain sind.
`- other_name_servers`	`[]`	Eine Liste der DNS-Server außerhalb dieser Domain.
`- primaries`	-	Eine Liste von primären DNS-Servern für diese Zone.
`- services`	`[]`	Eine Liste von Diensten, die durch SRV-Datensätze beworben werden sollen.
`- text`	`[]`	Eine Liste von Zuordnungen mit den Schlüsseln `name:` und `text:`, die TXT-Datensätze angeben. `text:` kann eine Liste oder einen String sein.
`- caa`	`[]`	Eine Liste von Zuordnungen mit den Schlüsseln `name:` und `text:`, die CAA-Datensätze angeben. `text:` kann eine Liste oder einen String sein.
`- type`	-	Optionale Zonenart. Wenn nicht angegeben, wird die automatische Erkennung verwendet. Mögliche Werte sind `primary`, `secondary` oder `forward`.
`bind_zone_file_mode`	0640	Die Dateiberechtigungen für die Hauptkonfigurationsdatei (named.conf).
`bind_zone_minimum_ttl`	`1D`	Mindest-TTL-Feld im SOA-Datensatz.
`bind_zone_time_to_expire`	`1W`	Zeit bis zum Ablauffeld im SOA-Datensatz.
`bind_zone_time_to_refresh`	`1D`	Zeit zum Auffrischen-Feld im SOA-Datensatz.
`bind_zone_time_to_retry`	`1H`	Zeit bis zur erneuten Anfrage im SOA-Datensatz.
`bind_zone_ttl`	`1W`	Time to Live-Feld im SOA-Datensatz.
`bind_python_version`	-	Die Python-Version, die für Ansible verwendet werden soll. Abhängig von der Distribution, entweder `2` oder `3`. Standardmäßig die des OS.

† Beste Praktik für einen autoritativen Nameserver ist es, die Rekursion ausgeschaltet zu lassen. Für einige Fälle kann es jedoch notwendig sein, die Rekursion zu aktivieren.

Minimale Variablen für eine funktionierende Zone

Um einen autoritativen Nameserver einzurichten, der für Clients verfügbar ist, sollten mindestens die folgenden Variablen definiert werden:

Variable	Primär	Sekundär	Forward
`bind_allow_query`	V	V	V
`bind_listen_ipv4`	V	V	V
`bind_zones`	V	V	V
`- hosts`	V	--	--
`- name_servers`	V	--	--
`- name`	V	V	--
`- networks`	V	V	V
`- primaries`	V	V	--
`- forwarders`	--	--	V

Zonenbeschreibungen

bind_zones:
  # Beispiel einer primären Zone (hosts: und name_servers: sind definiert)
  - name: mydomain.com           # Domainname
    create_reverse_zones: false  # Erstellung von Rückwärtszonen überspringen
    primaries:
      - 192.0.2.1                # Primärserver für diese Zone
    name_servers:
      - pub01.mydomain.com.
      - pub02.mydomain.com.
    hosts:
      - name: pub01
        ip: 192.0.2.1
        ipv6: 2001:db8::1
        aliases:
          - ns1
      - name: pub02
        ip: 192.0.2.2
        ipv6: 2001:db8::2
        aliases:
          - ns2
      - name: '@'                # Ermöglicht "http://mydomain.com/"
        ip:
          - 192.0.2.3            # Mehrere IP-Adressen für einen Host
          - 192.0.2.4            #   Ergebnisse in DNS-Round-Robin
        sshfp:                   # Secure Shell-Fingerabdruck
          - "3 1 1262006f9a45bb36b1aa14f45f354b694b77d7c3"
          - "3 2 e5921564252fe10d2dbafeb243733ed8b1d165b8fa6d5a0e29198e5793f0623b"
        ipv6:
          - 2001:db8::2
          - 2001:db8::3
        aliases:
          - www
      - name: priv01             # Diese IP ist in einem anderen Subnetz, was
        ip: 10.0.0.1             #   zu mehreren Rückwärtszonen führt
      - name: mydomain.net.
        aliases:
          - name: sub01
            type: DNAME          # Beispiel eines DNAME-Aliasdatensatzes
    networks:
      - '192.0.2'
      - '10'
      - '172.16'
    delegate:
      - zone: foo
        dns: 192.0.2.1
    services:
      - name: _ldap._tcp
        weight: 100
        port: 88
        target: dc001
    naptr:                       # Name Authority Pointer-Datensatz, verwendet für IP
      - name: "sip"              #   Telefonie
        order: 100
        pref: 10
        flags: "S"
        service: "SIP+D2T"
        regex: "!^.*$!sip:[email protected]!"
        replacement: "_sip._tcp.example.com."
  # Minimales Beispiel einer sekundären Zone
  - name: acme.com
    primaries:
      - 172.17.0.2
    networks:
      - "172.17"
  # Minimales Beispiel einer Weiterleitungszone
  - name: acme.com
    forwarders:
      - 172.17.0.2
    networks:
      - "172.17"

Hosts

Hostnamen, die dieser DNS-Server auflösen soll, können in bind_zones.hosts als eine Liste von Zuordnungen mit den Schlüsseln name:, ip:, aliases: und sshfp: angegeben werden. Aliase können CNAME (Standard) oder DNAME-Datensätze sein.

Um auf http://example.com/ zuzugreifen, setzen Sie den Hostnamen Ihres Webservers auf '@' (muss in Anführungszeichen gesetzt werden!). In der BIND-Syntax bedeutet @ den Domänennamen selbst.

Wenn Sie mehrere IP-Adressen für einen Host angeben möchten, fügen Sie Einträge zu bind_zones.hosts mit demselben Namen hinzu (z. B. priv01 im Codebeispiel). Dadurch ergeben sich mehrere A/AAAA-Datensätze für diesen Host und ermöglichen DNS-Round-Robin, eine einfache Lastenausgleichstechnik. Die Reihenfolge, in der die IP-Adressen zurückgegeben werden, kann mit der Variablen bind_rrset_order konfiguriert werden.

Netzwerke

Wie Sie sehen können, befinden sich nicht alle Hosts im selben Subnetz. Diese Rolle wird geeignete Rückwärts-Lookup-Zonen für jedes Subnetz generieren. Alle Subnetze sollten in bind_zones.networks angegeben werden, andernfalls erhält der Host keinen PTR-Datensatz für die Rücktabelle.

Beachten Sie, dass hier nur der Netzwerkanteil angegeben werden sollte! Wenn Sie eine Klasse-B-IP-Adresse (z.B. "172.16") in einer Variablen-Datei angeben, muss sie in Anführungszeichen gesetzt werden. Andernfalls interpretiert der YAML-Parser sie als Float.

Basierend auf der Idee und den Beispielen, die unter https://linuxmonk.ch/wordpress/index.php/2016/managing-dns-zones-with-ansible/ für das gdnsd-Paket aufgeführt sind, sind die Zonendateien vollständig idempotent und werden daher nur aktualisiert, wenn sich "echte" Inhalte ändern.

Zonentypen und automatische Erkennung des Zonentyps

Der Zonentyp ist ein optionaler Zonenparameter, der definiert, ob der Zonentyp primary, secondary oder forward sein soll. Wenn der Zonentyp-Parameter weggelassen wird, wird der Zonentyp basierend auf der Schnittmenge der Host-IP-Adressen und der primaries-Aufzeichnung bei der Konfiguration von primären oder sekundären Zonen automatisch erkannt. Wenn primaries nicht definiert ist und forwarders definiert ist, wird der Zonentyp auf forward gesetzt.

Die Funktion zur automatischen Erkennung von Zonen ist besonders nützlich, wenn mehrere DNS-Infrastrukturen verteilt werden. Es ist praktisch, "gemeinsame" bind_zones-Definitionen in einer einzigen Gruppeninventar-Datei für alle DNS-Server (z. B. group_vars\dns.yml) zu haben. Ein solcher Ansatz ermöglicht es, durch Aktualisieren der primaries-Aufzeichnung und erneutes Ausführen des Playbooks zwischen der Rolle des primären und sekundären Servers zu wechseln. Die Erkennung des Zonentypes kann mit dem Molekülszenario "shared_inventory" getestet werden, indem Sie Folgendes ausführen: molecule test --scenario-name shared_inventory

HINWEIS

BIND unterstützt keine automatisierte Multi-Master-Konfiguration, und die Liste der primaries sollte nur einen Eintrag haben.
Wenn die primaries-Aufzeichnung aktualisiert wird, um die Rolle des primären auf die des sekundären Servers zu wechseln, werden die Zonen gelöscht und aus der Vorlage neu erstellt, da wir derzeit keine dynamischen Updates für bestehende Zonen unterstützen.

Zonentypen können auch explizit im Inventar pro Host definiert werden, um die automatische Erkennung zu überspringen:

# Primärer Server
bind_zones:
  - name: mydomain.com
    type: primary
    primaries:
      - 192.0.2.1
...
# Sekundärer Server
bind_zones:
  - name: mydomain.com
      type: secondary
      primaries:
        - 192.0.2.1
...
# Weiterleitungsserver
bind_zones:
  - name: anotherdomain.com
      type: forward
      forwarders:
        - 192.0.3.1

Zonendelegation

Um eine Zone an einen DNS-Server zu delegieren, reicht es aus, einen NS-Datensatz (unter delegate) zu erstellen, was dem Äquivalent von:

foo IN NS 192.0.2.1

entspricht.

Dienstdatensätze

Dienst (SRV) Datensätze können mit den Dienstdefinitionen hinzugefügt werden. Dies sollte eine Liste von Zuordnungen mit den erforderlichen Schlüsseln name: (Dienste name), target: (Host, der den Dienst bereitstellt), port: (TCP/UDP-Port des Dienstes) und optionalen Schlüsseln priority: (standardmäßig = 0) und weight: (standardmäßig = 0) sein.

ACLs

ACLs können so definiert werden:

bind_acls:
  - name: acl1
    match_list:
      - 192.0.2.0/24
      - 10.0.0.0/8

Die Namen der ACLs werden in der allow-transfer Klausel in globalen Optionen hinzugefügt.

Bindungs-Schlüssel

Bindungs-Schlüssel können so definiert werden:

bind_dns_keys:
  - name: primary_key
    algorithm: hmac-sha256
    secret: "azertyAZERTY123456"
bind_extra_include_files:
  - "{{ bind_auth_file }}"

Tipp: Zusätzliche Include-Dateien müssen als Ansible-Variable festgelegt werden, da die Datei vom Betriebssystem abhängig ist.

Dies wird in einer Datei "{{ bind_auth_file }} (z. B. /etc/bind/auth_transfer.conf für Debian) festgelegt, die der Liste der Variablen bind_extra_include_files hinzugefügt werden muss.

Verwendung von TSIG zur Autorisierung von Zonenübertragung (XFR)

Um die Übertragung von Zonen zwischen Primär- und Sekundärservern basierend auf einem TSIG-Schlüssel zu autorisieren, setzen Sie die Zuordnung in der Variablen bind_key_mapping:

bind_key_mapping:
  primary_ip: TSIG-keyname

Jeder Primärserver kann nur einen Schlüssel (pro Sicht) haben.

Es wird eine Überprüfung durchgeführt, um sicherzustellen, dass der Schlüssel tatsächlich in der Zuordnung bind_dns_keys vorhanden ist. Dadurch wird eine Serveranweisung für das a in bind_auth_file auf einem Sekundärserver hinzugefügt, der den angegebenen Schlüssel enthält.

Abhängigkeiten

Keine Abhängigkeiten.

Beispiel-Playbooks

Siehe die Test-Playbooks und das Inventar für ein ausführliches Beispiel, das die meisten Funktionen zeigt.

Standardinventar

Variablen, die für alle Server gelten, definiert in all.yml
bind_zone-Variable, die auf Host-Basis definiert ist (Primär, Sekundär und Weiterleitungsserver)

❯ tree --dirsfirst molecule/default
molecule/default
├── group_vars
│   └── all.yml
├── host_vars
│   ├── ns1.yml    # Primär
│   ├── ns2.yml    # Sekundär
│   └── ns3.yml    # Weiterleitungsserver
├── converge.yml
...

Gemeinsames Inventar

Variablen, die für primäre und sekundäre Server gelten, die in all.yml definiert sind.

❯ tree --dirsfirst molecule/shared_inventory
molecule/shared_inventory
├── group_vars
│   └── all.yml
├── converge.yml
...

Tests

Diese Rolle wird mit Ansible Molecule getestet. Tests werden automatisch auf Github Actions nach jedem Commit und PR gestartet.

Diese Molecule-Konfiguration wird:

Yamllint und Ansible Lint ausführen
Drei Docker-Container erstellen, einen primären (ns1), einen sekundären (ns2) DNS-Server und einen Weiterleiter (ns3) - default Moleculeszenario
Eine Syntaxprüfung durchführen
Die Rolle mit einem Test-Playbook anwenden und die Idempotenz überprüfen
Akzeptanztests mit verify playbook durchführen
Zwei zusätzliche Docker-Container erstellen, einen primären (ns4) und einen sekundären (ns5) und das Szenario shared_inventory ausführen.

Dieser Prozess wird für alle unterstützten Linux-Distributionen wiederholt.

Lokale Testumgebung

Um die Akzeptanztests für diese Rolle lokal auszuführen, können Sie die erforderlichen Tools auf Ihrem Rechner installieren oder dieses reproduzierbare Setup in einer VirtualBox-VM (mit Vagrant eingerichtet) verwenden: https://github.com/bertvv/ansible-testenv.

Schritte zur manuellen Installation der Tools:

Docker sollte auf Ihrem Computer installiert sein.
Erstellen Sie, wie von Molecule empfohlen, eine Python-virtuelle Umgebung.
Installieren Sie die Softwaretools python3 -m pip install molecule molecule-docker docker netaddr dnspython yamllint ansible-lint.
Navigieren Sie zum Stammverzeichnis des Rollenverzeichnisses und führen Sie molecule test aus.

Molecule löscht automatisch die Container nach einem Test. Wenn Sie die Container selbst überprüfen möchten, führen Sie molecule converge gefolgt von molecule login --host HOSTNAME aus.

Die Docker-Container basieren auf von Jeff Geerling erstellten Images, speziell für Ansible-Tests (suchen Sie nach Images mit Namen geerlingguy/docker-DISTRO-ansible). Sie können eines seiner Images verwenden, aber nur die in meta/main.yml genannten Distributionen werden unterstützt.

Die Standardkonfiguration startet drei CentOS 8-Container (die primär unterstützte Plattform zu diesem Zeitpunkt). Wählen Sie eine andere Distribution über die Festlegung der MOLECULE_DISTRO-Variablen mit dem Befehl, z.B.:

MOLECULE_DISTRO=debian9 molecule test

oder

MOLECULE_DISTRO=debian9 molecule converge

Sie können die Akzeptanztests auf allen Servern mit molecule verify ausführen.

Überprüfungstests werden mit dem "dig" Lookup-Modul durchgeführt, indem DNS-Datensätze abgefragt und die Antworten validiert werden. Dies erfordert eine direkte Netzwerkkommunikation zwischen dem Ansible-Controllerknoten (Ihrem Computer, der Ansible ausführt) und dem Ziel-Docker-Container.

HINWEIS

Die Molecule-Überprüfungstests schlagen fehl, wenn Docker auf MacOS ausgeführt wird, da macOS nicht direkt auf die Container-IP zugreifen kann. Dies ist ein bekanntes Problem. Siehe #2670.

Umgehung:

Führen Sie den Molecule-Linter aus: molecule lint.
Provisionieren Sie die Container: molecule converge.
Verbinden Sie sich mit dem Container: molecule login --host ns1.
Gehen Sie zum Rollenverzeichnis: cd /etc/ansible/roles/bertvv.bind.
Führen Sie das Verifizierungs-Playbook aus:

ansible-playbook -c local -i "`hostname`," -i molecule/default/inventory.ini molecule/default/verify.yml

Wiederholen Sie die Schritte 2-4 für ns2 und ns3.

Lizenz

BSD

Mitwirkende

Diese Rolle könnte nur dank der Beiträge vieler realisiert werden. Wenn Sie eine Idee haben, um sie noch weiter zu verbessern, zögern Sie nicht, sich zu melden!

Probleme, Funktionsanfragen, Ideen, Vorschläge usw. können im Abschnitt "Issues" gepostet werden.

Pull-Requests sind ebenfalls sehr willkommen. Bitte erstellen Sie einen Themenzweig für Ihre vorgeschlagenen Änderungen. Wenn Sie das nicht tun, kann das nach dem Merge zu Konflikten in Ihrem Fork führen. Zögern Sie nicht, sich auf der Mitwirkendenliste unten in Ihrem PR zu verewigen!

Pflegekräfte:

Mitwirkende:

Über das Projekt

Sets up ISC BIND as an authoritative DNS server for one or more domains (primary and/or secondary).

role dns networking system

Installieren

ansible-galaxy install bertvv.bind

GitHub Repository

258 Sterne

184 Forks

50 Offene Issues

Lizenz

other

Downloads

406.9k

Besitzer

Bert Van Vreckem

Hi! My contribs are often related to my job (teaching Linux), but are mostly done in my free time. I can't always respond quickly to PRs and Issues. Sorry!