linux:bind

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
linux:bind [16.01.2026 13:46. ] – [Theorie] djangolinux:bind [01.02.2026 17:36. ] (aktuell) – [Rolle] django
Zeile 2565: Zeile 2565:
 OK</code> OK</code>
  
-Somit haben wir auch hier alle __vier__ benötigten Zonen-Dateien für die Doamin/Zone **''nausch.org''** fehlerfrei angelegt.+Somit haben wir auch hier alle __vier__ benötigten Zonen-Dateien für die Domain/Zone **''nausch.org''** fehlerfrei angelegt.
  
 Zum Schluß passen wir noch abschließend die User- und Gruppenberechtigungen unserer gerade angelegten Zonen-Dateien an. Zum Schluß passen wir noch abschließend die User- und Gruppenberechtigungen unserer gerade angelegten Zonen-Dateien an.
Zeile 2572: Zeile 2572:
 Somit hat unser Zonen-Verzeichnis aktuell folgende Inhalte. Somit hat unser Zonen-Verzeichnis aktuell folgende Inhalte.
 <code> # ls -l /var/named/zones/*</code> <code> # ls -l /var/named/zones/*</code>
-++++ Ausgabe des Befehlsaufrufes s -l /var/named/zones/* |+++++ Ausgabe des Befehlsaufrufes ls -l /var/named/zones/* |
 <code>-rw-r--r-- 1 named named 2170 Dec 28 19:46 /var/named/zones/e.edmz.nausch.org.db <code>-rw-r--r-- 1 named named 2170 Dec 28 19:46 /var/named/zones/e.edmz.nausch.org.db
 -rw-r--r-- 1 named named 2433 Dec 28 19:48 /var/named/zones/e.edmz.nausch.org.in-addr.db -rw-r--r-- 1 named named 2433 Dec 28 19:48 /var/named/zones/e.edmz.nausch.org.in-addr.db
Zeile 3799: Zeile 3799:
 </code> </code>
 ++++ ++++
- 
 Bei Bedarf können wir natürlich auch den Status unseres Daemons jederzeit abfragen. Bei Bedarf können wir natürlich auch den Status unseres Daemons jederzeit abfragen.
    # systemctl status named.service    # systemctl status named.service
Zeile 5013: Zeile 5012:
 </code> </code>
 ++++ ++++
 +
 +<WRAP center round tip 80%>
 +Die, beim ersten Neustart nach Änderung der Konfiguration für die DNSSEC-Unterstützung, auflaufenden **''error ... could not get zone keys for secure dynamic update''**-Meldungen können erst einmal ignoriert werden, da dies lediglich ein Hinweis ist, dass noch keine Schlüssel existieren und sich der Nameserver um die Schlüsselerstellung selbst noch vornehmen muss. 
 +++++ Errormeldungen in Journal zu fehlendem Schlüsselmaterial |
 +<code>Jan 23 15:17:54 vml000110 named[31230]: 23-Jan-2026 15:17:54.140 general: error: zone omni128.de/IN/intern (signed): could not get zone keys for secure dynamic update
 +Jan 23 15:17:54 vml000110 named[31230]: 23-Jan-2026 15:17:54.144 general: info: zone omni128.de/IN/intern (signed): receive_secure_serial: unchanged
 +Jan 23 15:17:54 vml000110 named[31230]: 23-Jan-2026 15:17:54.144 general: error: zone nausch.org/IN/intern (signed): could not get zone keys for secure dynamic update
 +Jan 23 15:17:54 vml000110 named[31230]: 23-Jan-2026 15:17:54.150 general: info: zone nausch.org/IN/intern (signed): receive_secure_serial: unchanged
 +Jan 23 15:17:54 vml000110 named[31230]: 23-Jan-2026 15:17:54.150 general: error: zone edmz.nausch.org/IN/intern (signed): could not get zone keys for secure dynamic update</code>
 +++++
 +</WRAP>
  
 <WRAP center round important 80%> <WRAP center round important 80%>
Zeile 5158: Zeile 5168:
 <WRAP center round important 70%> <WRAP center round important 70%>
 **Wichtig**: \\ **Wichtig**: \\
-Das **''Ad''**-Flag ist bei unserem authoritativen DNS-Servern **__nicht__** gesetzt! Dieses Flag wird nur bei rekursiven Resolvern wie z.B. bei Verwendung des **[[https://www.nlnetlabs.nl/projects/unbound/about/|Unbound]]** gesetzt, da nur durch diesen die Trust-Of-Chain abgefragt und aufgelöst werden kann!+Das **''Ad''**-Flag ist bei unserem authoritativen DNS-Servern **__nicht__** gesetzt! Dieses Flag wird nur bei rekursiven Resolvern wie z.B. bei Verwendung des **[[https://www.nlnetlabs.nl/projects/unbound/about/|Unbound]]** gesetzt, da nur durch diesen die Trust-Of-Chain abgefragt und aufgelöst werden kann! Der Einrichten eines lokalen DNS-Resolvers mit Unbound unter Arch Linux werden wir uns in einem gesonderten [[linux:unbound|Kapitel]] widmen.
 </WRAP> </WRAP>
  
Zeile 5435: Zeile 5445:
  
 <WRAP center round important 80%> <WRAP center round important 80%>
-**Achtung**: \ Im Moment sind diese Änderungen lediglich im Speicher zur Laufzeit unseres DNS verfügbar. Bei einem Neustart des Systems wäre diese Änderung nicht mehr existent, da diese noch nicht im Zone-File der Zone **''intra.nausch.org''** manifestiert wurde!+**Achtung**: \\ Im Moment sind diese Änderungen lediglich im Speicher zur Laufzeit unseres DNS verfügbar. Bei einem Neustart des Systems wäre diese Änderung nicht mehr existent, da diese noch nicht im Zone-File der Zone **''intra.nausch.org''** manifestiert wurde!
 </WRAP> </WRAP>
  
Zeile 5579: Zeile 5589:
 ===== Orchestrierung - Installation und Konfiguration des BIND9 inkl. der Zonen-Datei-Pflege mit Hilfe von Ansible  ===== ===== Orchestrierung - Installation und Konfiguration des BIND9 inkl. der Zonen-Datei-Pflege mit Hilfe von Ansible  =====
 ==== Aufgabenstellung ==== ==== Aufgabenstellung ====
-Natürlich wird man im Jahr 2024 nicht mehr ernsthaft, manuell Server aufsetzen und betreiben wollen. Vielmehr wird man auf ein Orchestrierungswerkzeug wie z.B. **[[linux:ansible:start|Ansible]]** zurückgreifen. Setzen wir einen neue virtuellen Server unter Arch Linux neu auf, oder wollen wir bei einem bestehenden Host die Konfiguration aktualisieren, verwenden wir wie zuvor schon angeschnitten [[https://www.ansible.com/|Ansible]] als Orchestrierungswerkzeug. So ist sichergestellt dass zum einen all unsere Hosts entsprechend gleich aufgebaut, konfiguriert und betrieben werden, es also keine Bastel-/Frickellösung geben wird. +Natürlich wird man im Jahr 2026 nicht mehr ernsthaft, manuell Server aufsetzen und betreiben wollen. Vielmehr wird man auf ein Orchestrierungswerkzeug wie z.B. **[[linux:ansible:start|Ansible]]** zurückgreifen. Setzen wir einen neue virtuellen Server unter Arch Linux neu auf, oder wollen wir bei einem bestehenden Host die Konfiguration aktualisieren, verwenden wir wie zuvor schon angeschnitten [[https://www.ansible.com/|Ansible]] als Orchestrierungswerkzeug. So ist sichergestellt dass zum einen all unsere Hosts entsprechend gleich aufgebaut, konfiguriert und betrieben werden, es also keine Bastel-/Frickellösung geben wird.  
 + 
 +Betrachten wir kurz die grundlegende Infrastruktur, in der wir eine Lösung für den Netzdienst DNS mit Hilfe von Ansible bauen und verwalten wollen. In dem Beispiel werden wir in diesem Beispiel erst einmal einen ISC Bind aufsetzen der Anfragen lediglich auf den beiden **localhost**-Adressen **''127.0.0.1''** und **''::1''** beantworten soll. In einem **[linux:unbound#orchestrierung_-_installation_und_konfiguration_des_unbound-resolvers_mit_hilfe_von_ansible|zweiten Schritt]]** werden wir dann für die workload der Clients aus den einzelnen Zonen einen **unbound**-Resolver aufsetzen.  
 + 
 +{{ :linux:dns-ueberblick_skizze_nausch.org_.drawio.png?nolink&1024 |Bild: Übersicht der Infrastruktur bei nausch.org, mit den einzelnen Schutzzonen und der Lösung für das Thema DNS}} 
 + 
 +Da wir selbst __keine eigenen__ DNS-Server, die für alle im Internet erreich- und abfragbar sind, wollen wir auch noch dafür sorgen, dass unser Ansible-Playbook nicht nur die internen Zonefiles aus dem Inventory generiert, sondern auch ein "spezielles" Zonefile mit den offiziellen Adressen schreibt, welches wir dann in einem manuellen Schritt bei Bedarf beim **ISP** - in unserem Falle **[[https://www.core-networks.de/|core-networks]]** - hochladen und importieren können.   
 + 
 +Wir werden uns nun nachfolgend die DNS-Server-Installation und -konfiguration genauer betrachten.  
  
-Wir werden uns nun nachfolgend die Server-Installation und -konfiguration genauer betrachten.  
 ==== Lösung ==== ==== Lösung ====
  
Zeile 5590: Zeile 5608:
          -O - | tar -xz --strip-components=1 -C ~/devel/ansible</code>          -O - | tar -xz --strip-components=1 -C ~/devel/ansible</code>
  
-Nach Anpassung der Daten im Inventory kann man anschliessend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**.+Nach Anpassung der Daten im **[[#vorbereitung_-_server-_daten_im_inventory|Inventory]]** kann man anschließend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**.
 </WRAP> </WRAP>
  
 +=== Vorbereitung - (Server-)Daten im Inventory ===
 +Bei unserem Konfigurationsbeispiel hier gehen wir von folgenden Host-Parametern aus:
 +  * **''zone: edmz''**
 +    * **Netzwerkswitch/-device : ''pnc027010''**
 +  * **''zone: idmz''**
 +    * **KVM HOST : ''vml000110''**
 +  * **''zone: intra''**
 +    * **Netzwerkswitch/-device : ''pnc010010''**
 +    * **Workstation : ''pml010068''**
 +  * **''hostname: vml010110''** auf dem der ISC BIND laufen soll. 
  
-21:12 $ pikaur -Ss netaddr+Die Konfigurationsdatei unseres **inventory** in unsere, Ansible-Verzeichnis beinhaltet demnach unter anderem: 
 +   $ vim inventories/production/hosts 
 +++++ inventories/production/hosts |
  
-check: +{{gh> https://gitlab.nausch.org/django/example_bin/-/blob/main/inventories/production/hosts }}
-  * **auf pml010074 einem Host der Zone intra**: +
-    * Adressen aus der Zone **intra**  +
-      * MX-record :OK: +
-      * NS-record :OK: +
-      * IPv4 forward :OK: +
-      * IPv6 forward :OK: +
-      * IPv4 reverse :OK: +
-      * IPv6 reverse :OK: +
-    * Adressen aus der Zone **idmz** +
-      * MX-record :OK: +
-      * NS-record :OK: +
-      * IPv4 forward :OK: +
-      * IPv6 forward :OK: +
-      * IPv4 reverse :OK: +
-      * IPv6 reverse :OK: +
-    * Adressen aus der Zone **edmz** +
-      * MX-record :OK: +
-      * NS-record :OK: +
-      * IPv4 forward :OK: +
-      * IPv6 forward :OK: +
-      * IPv4 reverse :OK: +
-      * IPv6 reverse :OK: +
-    * Adressen aus der Domain **nausch.org** +
-      * MX-record :OK: +
-      * NS-record :OK: +
-      * IPv4 forward :OK: +
-      * IPv6 forward :OK: +
-      * IPv4 reverse :OK: +
-      * IPv6 reverse :OK: +
-    * Adressen aus **fremden** Domains +
-      * MX-record :OK:  +
-      * NS-record :OK: +
-      * IPv4 forward :OK: +
-      * IPv6 forward :OK: +
-      * IPv4 reverse :NOK: <code>no answer!</code> +
-      * IPv6 reverse :NOK: <code>no answer!</code>+
  
 +++++
  
 +Der Beispiel-Hosts aus der Gruppe|Zone **''edmz''** in diesem Inventory beschreibt den Switch der EDMZ.
 +Der Host **''vml000110''** ist in diesem Beispiel unser Server, der die Verbindung zwischen der Zone **''intra''** und der Zone **''idmz''** herstellt. Auf diesem Konten läuft bereits ein **[[linux:ntp|Chrony Timeserver|]]** wie auch eine Firewall auf Basis von **[[https://firewalld.org/|firewalld]]** der eine Zonendefinition **''intra''** besitzt, die die Regeln für diese Zone beinhalten. Sowohl Timeserver wie auch Firewall werden in diesem Beispiel hier nur erwähnt, da in dem Playbook bzw.genauer gesagt im Inventory darauf referenziert wird. 
 +In der Zone **''idmz''** finden wir ferner noch die Beschreibung des Intranet-Switch und eine der Workstations.
  
 +Wir legen uns also nun die Hostdefinitionsdatei für unseren Switch in der Zonme **''edmz''** an.
 +
 +   $ vim inventories/production/host_vars/pnc027010
 +++++ inventories/production/host_vars/pnc027010 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/inventories/production/host_vars/pnc027010  }}
 +
 +++++
 +
 +Als nächstes legen wir die Datei für den KVM-Host, auf dem unser Kea-Daemon laufen soll an und definieren darin die zugehörigen Eigenschaften.
 +  $ vim inventories/production/host_vars/vml000110/kvm_vhost
 +++++ inventories/production/host_vars/vml000110/kvm_vhost |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/inventories/production/host_vars/vml010110/kvm_vhost  }}
 +
 +++++
 +
 +Die für deb **ISC Bind-Daemon** relevanten Konfigurationsparameter legen wir in der Inventory-Datei **''inventories/production/host_vars/vml000110/bind''** ab.
 +   $ vim inventories/production/host_vars/vml000110/bind 
 +++++ inventories/production/host_vars/vml000110/bind |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/inventories/production/host_vars/vml000110/bind }}
 +
 +++++
 +
 +Die für die Domain **nausch.org** relevanten Daten legen wir in der Inventrory-Datei **''inventories/production/host_vars/vml000110/bind_nausch_org''** ab. In dieser Datei ist ein Array definiert, welches die externen Hostnamen/vHosts beschreibt, für die jeweils ein eigener **''A''** und **''AAAA''** Record angelegt werden soll. Diese Parameter werden wir später auch bei der Definition der einzelnen virtuellen Maschinen heranziehen, also 1x Daten vorhalten für Apache-Webserver und auch für das Thema DNS. So brauchen wir nicht n-mal die gleichen Daten definieren! 
 +
 +   $ vim inventories/production/host_vars/vml000110/bind_nausch_org 
 +++++ inventories/production/host_vars/vml000110/bind_nausch_org |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/inventories/production/host_vars/vml000110/bind_nausch_org }}
 +
 +++++
 +
 +Nun brauchen wir noch eine Konfigurationsdatei für den Intranet-Switch und für eine der Intranet-Hosts, die wir nun auch noch anlegen werden.
 +   $ vim inventories/production/host_vars/pnc010010
 +++++ inventories/production/host_vars/pnc010010 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/inventories/production/host_vars/pnc010010 }}
 +
 +++++
 +
 +und
 +
 +++++ inventories/production/host_vars/pnc010068 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/inventories/production/host_vars/pnc010068 }}
 +
 +++++
 +
 +Unser Beispiels-Inventory hat also nunmehr folgenden Aufbau:
 +<code>inventories/production/
 +├── hosts
 +└── host_vars
 +    ├── pml010068
 +    ├── pnc010010
 +    ├── pnc027010
 +    └── vml010110
 +        ├── bind
 +        ├── bind_domain
 +        └── kvm_vhost
 +
 +3 directories, 7 files</code>
 +
 +
 +=== Playbook ===
 +Unser Playbook zum Installieren und Konfigurieren des **ISC Bind**-Daemon ist wie immer schlank, unscheinbar und unspektakulär, beinhaltet aber Hinweise zur Aufgabe und wie es aufzurufen ist.
 +   $ vim playbooks/bind.yml
 +++++ playbooks/bind.yml |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/playbooks/bind.yml }}
 +
 +++++
 +
 +=== Rolle ===
 +Für die Konfiguration des **ISC BIND**-Daemon verwenden wir eine eigene Rolle **''bind''**, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. Hierzu kopieren wir uns zunächst die **[[linux:ansible:playbook_example_08|Mustervorlage]]** **''common''**, welche wir bei der initialen Ansible-Einrichtung angelegt hatten.
 +   $ cp -avr roles/common/ roles/bind
 +
 +++++ Ausgabe von cp -avr roles/common/ roles/bind |
 +<code>'roles/common/' -> 'roles/bind'
 +'roles/common/defaults' -> 'roles/bind/defaults'
 +'roles/common/defaults/.gitkeep' -> 'roles/bind/defaults/.gitkeep'
 +'roles/common/files' -> 'roles/bind/files'
 +'roles/common/files/.gitkeep' -> 'roles/bind/files/.gitkeep'
 +'roles/common/handlers' -> 'roles/bind/handlers'
 +'roles/common/handlers/.gitkeep' -> 'roles/bind/handlers/.gitkeep'
 +'roles/common/library' -> 'roles/bind/library'
 +'roles/common/library/.gitkeep' -> 'roles/bind/library/.gitkeep'
 +'roles/common/lookup_plugins' -> 'roles/bind/lookup_plugins'
 +'roles/common/lookup_plugins/.gitkeep' -> 'roles/bind/lookup_plugins/.gitkeep'
 +'roles/common/meta' -> 'roles/bind/meta'
 +'roles/common/meta/.gitkeep' -> 'roles/bind/meta/.gitkeep'
 +'roles/common/module_utils' -> 'roles/bind/module_utils'
 +'roles/common/module_utils/.gitkeep' -> 'roles/bind/module_utils/.gitkeep'
 +'roles/common/tasks' -> 'roles/bind/tasks'
 +'roles/common/tasks/main.yml' -> 'roles/bind/tasks/main.yml'
 +'roles/common/templates' -> 'roles/bind/templates'
 +'roles/common/templates/.gitkeep' -> 'roles/bind/templates/.gitkeep'
 +'roles/common/vars' -> 'roles/bind/vars'
 +'roles/common/vars/.gitkeep' -> 'roles/bind/vars/.gitkeep'
 +</code>
 +++++
 +
 +Bei Bedarf können wir uns die Struktur die somit angelegt wurde mit nachfolgendem Befehl anzeigen lassen.
 +   $ tree roles/bind/
 +
 +++++ Ausgabe von tree roles/bind/ |
 +<code>roles/bind/
 +├── defaults
 +├── files
 +├── handlers
 +├── library
 +├── lookup_plugins
 +├── meta
 +├── module_utils
 +├── tasks
 +├── templates
 +└── vars
 +
 +10 directories, 0 files
 +</code>
 +++++
 +
 +Wie wir sehen ist die Rolle durchaus überschaubar, im Task **''main.yaml''** verweisen wir lediglich auf die eigentlichen Tasks **''install''**, **''grundkonfig''**, **''zonefiles''**, **''fetchzonefiles''**, **''konfig''** und **''firewalld''**
 +   $ vim roles/bind/tasks/main.yml
 +++++ roles/bind/tasks/main.yml |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/tasks/main.yml }}
 +
 +++++
 +
 +Die Installation des ISC Bind-Servers wird in der ersten Task-Gruppe mit dem tag **''install''** vorgenommen.
 +   $ vim roles/bins/tasks/install.yml
 +++++ roles/bind/tasks/install.yml |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/tasks/install.yml }}
 +
 +++++
 +
 +Für die Grundkonfiguration des ISC BIND-Daemon (rndc-Schlüsselanlage, Definition für die 13 Root-Server und Anlegen der Verzeichnisse) werden die nötigen Schritte in der Task-Gruppe mit dem tag **''grundkonfig''** definiert.
 +   $ vim roles/bind/tasks/grundkonfig.yml
 +++++ roles/bind/tasks/grundkonfig.yml |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/tasks/grundkonfig.yml }}
 +
 +++++
 +
 +Das Anlegen der Zonefiles erfolgt dann mit Hilfe des Task-Gruppe mit dem tag **''zonefiles''** mit den Daten aus dem Inventory konfiguriert.
 +<WRAP center round important 60%>
 +Damit wir uns nicht die Finger brechen bzw. wund tippen speziell bei den Reverse-IPv6-Adressen delegieren wir solch stupide und fehleranfällige Arbeiten an Ansible. Zur Konvertierung der IPv6-Adressen ist hierzu das Paket python-netaddr notwendig, das wir bei Bedarf mit Hilfe des Paketmanagers auf unserem Linux-Ansible-Kontrollnode/-Workstation noch installieren:
 +<code> $ sudo pacman -S python-netaddr</code>.
 +</WRAP>
 +
 +Anschließens generieren wir noch das spezielle Zone-File, welches wir dann später bei unserem ISP einkippen werden.
 +
 +   $ vim roles/bind/tasks/zonefiles.yml
 +++++ roles/bind/tasks/zonefiles.yml |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/tasks/zonefiles.yml }}
 +
 +++++
 +
 +Das zuvor generierte spezielle Zone-File holen wir uns nun auf unseren Linux-Ansible-Kontrollnode/-Workstation, damit wir dieses dann später bei unserem ISP einkippen. Hierzu erstellen wir noch ein entsprechendes Verzeichnis auf unserer lokalen Workstation.
 +   $ mkdir ~/devel/isp/
 +
 +Der Task zum Holen des Zonefiles für den ISP beschränkt sich lediglich auf einen Schritt zum Downloaden der betreffenden Datei.
 +
 +   $ vim roles/bind/tasks/fetchzonefiles.yml
 +++++ roles/bind/tasks/fetchzonefiles.yml |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/tasks/fetchzonefiles.yml }}
 +
 +++++
 +
 +Nun müssen wir unseren ISC Bind noch individuell konfigurieren. Dies erschlagen wir mit der Task-Gruppe **''konfig''**.
 +
 +   $ vim roles/bind/tasks/konfig.yml
 +++++ roles/bind/tasks/konfig.yml |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/tasks/konfig.yml }}
 +
 +++++
 +
 +Zum Schluss konfigurieren wir abschließend noch die Paketfilter-Regeln für unseren Firewall-Daemon **''firewalld''**.
 +   $ vim roles/kea_dhcp/tasks/firewalld.yml
 +++++ roles/kea_dhcp/tasks/firewalld.yml |
 +
 +{{gh> https://gitlab.nausch.org/django/example_kea/-/blob/main/roles/kea_dhcp/tasks/firewalld.yml }}
 +
 +++++
 +
 +Sollte bei der Abarbeitung des Playbook die Konfigurationsdatei **''named.conf''** bzw. bei den Zonefiles unter **''/var/named/zones''** verändert werden, ist natürlich hierbei ein Restart der betreffenden ISC Bind-Daemon notwendig. Hierzu verwenden wir die **[[https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html|Ansible Playbook Handlers]]**. Dieser Handler wird bei den betreffenden Tasks zur Erstellung der Kea-Konfigurationsdateie bze. der Zonesfiles mit Hilfe eines **handler**-Calls aufgerufen, sofern sich die Dateien verändert hat. 
 +
 +Wir brauchen wir noch eine Konfiguration der Aufgaben die bei einem **''notify''** abgearbeitet werden sollen.
 +   $ vim roles/bind/handlers/main.yml
 +++++ roles/bind/handlers/main.yml |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/handlers/main.yml }}
 +
 +++++
 +
 +Für die Erstellung der Konfigurationsdatei **''/etc/named.conf''** brauchen wir nun noch ein **[[https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_templating.html|Jinja2]]** Templates. 
 +   $ vim roles/bind/templates/named.j2
 +++++ roles/bind/templates/named.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/named.j2 }}
 +
 +++++
 +
 +Für die Erstellung der Zone-Files im Verzeichnis **''/var/named/zones''** benötigen wir nun noch jeweils ein **[[https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_templating.html|Jinja2]]** Templates. 
 +   $ vim roles/bind/templates/0.0.10.in-addr.arpa.zone.db.j2
 +++++ roles/bind/templates/0.0.10.in-addr.arpa.zone.db.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/0.0.10.in-addr.arpa.zone.db.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/10.0.10.in-addr.arpa.zone.db.j2
 +++++ roles/bind/templates/10.0.10.in-addr.arpa.zone.db.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/10.0.10.in-addr.arpa.zone.db.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/12.92.217.in-addr.arpa.zone.db.j2
 +++++ roles/bind/templates/12.92.217.in-addr.arpa.zone.db.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/12.92.217.in-addr.arpa.zone.db.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/intra.nausch.org.j2
 +++++ roles/bind/templates/intra.nausch.org.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/intra.nausch.org.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/intra.nausch.org.ip6.j2
 +++++ roles/bind/templates/intra.nausch.org.ip6.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/intra.nausch.org.ip6.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/idmz.nausch.org.j2
 +++++ roles/bind/templates/idmz.nausch.org.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/idmz.nausch.org.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/idmz.nausch.org.in-addr.j2
 +++++ roles/bind/templates/idmz.nausch.org.in-addr.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/idmz.nausch.org.in-addr.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/idmz.nausch.org.ip6.j2
 +++++ roles/bind/templates/idmz.nausch.org.ip6.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/idmz.nausch.org.ip6.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/edmz.nausch.org.j2
 +++++ roles/bind/templates/edmz.nausch.org.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/edmz.nausch.org.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/edmz.nausch.org.in-addr.j2
 +++++ roles/bind/templates/edmz.nausch.org.in-addr.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/edmz.nausch.org.in-addr.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/edmz.nausch.org.ip6.j2
 +++++ roles/bind/templates/edmz.nausch.org.ip6.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/edmz.nausch.org.ip6.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/nausch.org.j2
 +++++ roles/bind/templates/nausch.org.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/nausch.org.j2 }}
 +
 +++++
 +
 +   $ vim roles/bind/templates/nausch.org.ip6.j2
 +++++ roles/bind/templates/nausch.org.ip6.j2 |
 +
 +{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/roles/bind/templates/nausch.org.ip6.j2 }}
 +
 +++++
 +
 +=== Ausführung - Playbooklauf ===
 +Die orchestrierte Variante der Installation und Konfiguration unserer **kea**-Daemon gestaltet sich ab sofort sehr einfach, brauchen wir doch lediglich die Konfigurationswerte im Inventory zu hinterlegen und zu pflegen und letztendlich das Playbook entsprechend aufzurufen, wenn z.B. ein Client im Intranet hinzugefügt, entfernt oder ausgetauscht wird: 
 +   $ ansible-playbook playbooks/kea_dhcp.yml
 +
 +<html><pre class="code">
 +<font style="color: rgb(0, 0, 0)">[15:16:47] Gathering Facts</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 2.06s</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:49] bind : Installation des BIND-Servers.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 33ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:49]     ↳ install: Installation der benötigten bind Paketes.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 4.05s</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:53] bind : Grundkonfiguration des BIND-Servers.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 18ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:53]     ↳ grundkonfiguration: Checken ob es bereits eine Datei /etc/rndc.key gibt.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 737ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:54]     ↳ grundkonfiguration: Individuellen Schlüssel für rndc erzeugen und ablegen.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 767ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:54]     ↳ grundkonfiguration: Berechtigungen der Schlüssel-Datei /etc/rndc.key sicherstellen.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 760ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:55]     ↳ grundkonfiguration: Checken ob es bereits eine Datei /var/named/named.root gibt.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 660ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:56]     ↳ grundkonfiguration: Liste der 13 Root-Nameserver holen und ablegen..</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 746ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:57]     ↳ grundkonfiguration: Sicherstellen dass die Datei named.root existiert.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 683ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:57]     ↳ grundkonfiguration: Liste der zuvor erstellten 13 Root-Name-Server in /var/named/named.root ablegen.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.40s</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:59]     ↳ grundkonfiguration: Sicherstellen dass das Verzeichnis für die Zonendateien existiert.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 649ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:16:59]     ↳ grundkonfiguration: Sicherstellen dass das Verzeichnis für die externen Zonendateien existiert.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 692ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:00] bind : Konfiguration der BIND-Zonen für die Domain nausch.org.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 20ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:00]     ↳ zonefiles_nausch: Zonen Datei für IPv4|6 Forward Auflösung der Zone intra.nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.50s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:02]     ↳ zonefiles_nausch: Zonen Datei für IPv4 Reverse Auflösung der Zone intra.nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.45s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:03]     ↳ zonefiles_nausch: Zonen Datei für IPv6 Reverse Auflösung der Zone intra.nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.56</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:05]     ↳ zonefiles_nausch: Zonen Datei für IPv4|6 Forward Auflösung der Zone idmz.nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.37s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:06]     ↳ zonefiles_nausch: Zonen Datei für IPv4 Reverse Auflösung der Zone idmz.nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.31s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:07]     ↳ zonefiles_nausch: Zonen Datei für IPv6 Reverse Auflösung der Zone idmz.nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.46s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:09]     ↳ zonefiles_nausch: Zonen Datei für IPv4|6 Forward Auflösung der Zone edmz.nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.29s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:10]     ↳ zonefiles_nausch: Zonen Datei für IPv4 Reverse Auflösung der Zone edmz.nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.29s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:12]     ↳ zonefiles_nausch: Zonen Datei für IPv6 Reverse Auflösung der Zone edmz.nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.40s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:13]     ↳ zonefiles_nausch: Zonen Datei für IPv4|6 Forward Auflösung der Zone nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.46s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:14]     ↳ zonefiles_nausch: Zonen Datei für IPv4 Reverse Auflösung der Zone nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.29s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:16]     ↳ zonefiles_nausch: Zonen Datei für IPv6 Reverse Auflösung der Zone nausch.org erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.41s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:17]     ↳ zonefiles_nausch: Zonen Datei für IPv4|6 Forward Auflösung der Zone nausch.org für core-networks.de erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.45s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:19] bind : Konfiguration der BIND-Zone für die Domain omni128.de.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 15ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:19]     ↳ zonefiles_omni128.de: Zonen Datei für IPv4|6 Forward Auflösung Domain omni128.de erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.41s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:20]     ↳ zonefiles_omni128.de: Zonen Datei für IPv4 Reverse Auflösung der Zone omni128.de für core-networks.de erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.45s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:21] bind : Konfiguration der BIND-Zone für die Domain ebersberger-liedersammlung.de.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 26ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:21]     ↳ zonefiles_liedersammlung: Zonen Datei für IPv4|6 Forward Auflösung Domain ebersberger-liedersammlung.de erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.23s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:23]     ↳ zonefiles_liedersammlung: Zonen Datei für IPv4|6 Forward Auflösung der Zone ELS für core-networks.de erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.33s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:24] Konfiguration der BIND-Zone für die Domain wetterstation-pliening.info.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 16ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:24]     ↳ zonefiles_wetterstation: Zonen Datei für IPv4|6 Forward Auflösung Domain wetterstation-pliening.info für die interne view erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.36s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:25]     ↳ zonefiles_wetterstation: Zonen Datei für IPv4|6 Forward Auflösung der Domain wetterstation-pliening.info für core-networks.de erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.22s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:27] bind : Sichern der Zonefiles für externen DNS.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 15ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:27]     ↳ fetchzonefiles: Erstelltes Zonefile für die Domain nausch.org holen.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 710ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:27]     ↳ fetchzonefiles: Erstelltes Zonefile für die Domain ebersberger-liedersammlung.de holen.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 681ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:28]     ↳ fetchzonefiles: Erstelltes Zonefile für die Domain omni128.de holen.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 701ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:29]     ↳ fetchzonefiles: Erstelltes Zonefile für die Domain wetterstation-pliening.info holen.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 658ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:29] bind : Konfiguration des BIND-Servers.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 36ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:29]     ↳ konfiguration: Checken ob es bereits eine Backupdatei named.conf gibt.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 632ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:30]     ↳ konfiguration: Backupdatei der Konfigurationsdatei named.conf erstellen.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 681ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:31]     ↳ konfiguration: Individuelle Konfigurationsdatei named.conf erzeugen und kopieren.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.34s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:32]     ↳ konfiguration: Verzeichnis für die private und public DNSSEC-Schlüssel erstellen.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 703ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:33]     ↳ konfiguration: Caching-Verzeichnis für die verwalteten DNSSEC-Schlüssel erstellen.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 673ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:34]     ↳ konfiguration: Data-Dump-Verzeichnis erstellen.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 706ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:34]     ↳ konfiguration: Sicherstellen, dass der BIND Daemon reboot(-fest) startet.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 673ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:35]     ↳ konfiguration: Logging-Verzeichnis erstellen.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 706ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:36]     ↳ konfiguration: Data-Dump-Verzeichnis erstellen.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 679ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:36] bind : Konfiguration der firewalld-Regeln für den BIND.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 1.18ms</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:36]     ↳ firewalld: Konfiguration der firewalld Regeln in Zone_1 für den BIND-Server.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 7.74s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:44]     ↳ firewalld: Konfiguration der firewalld Regeln in Zone_2 für den BIND-Server.</font>
 +<font style="color: rgb(25, 100, 5)">↳  vml010110 | SUCCESS | 7.82s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:52]     ↳ firewalld: Zum Schluss den aktuellen permanenten Regelsatz final neu laden.</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 979ms</font>
 +<font style="color: rgb(25, 100, 5)">triggering handler | bind : Restart bind</font>
 +<font style="color: rgb(196, 160, 0)">↳  vml010110 | CHANGED | 1.78s</font>
 +<font style="color: rgb(0, 0, 0)">[15:17:54] system</font>
 +<font style="color: rgb(25, 100, 5)">-- Play recap --</font>
 +<font style="color: rgb(196, 160, 0)">vml010110                  </font><font style="color: rgb(0, 0, 0)">: </font><font style="color: rgb(25, 100, 5)">ok=55   </font><font style="color: rgb(196, 160, 0)">changed=32   </font>unreachable=0    failed=0    <font style="color: rgb(3, 99, 84)">skipped=2</font>    <font style="color: rgb(0, 0, 0)">rescued=0    ignored=0</font>
 +</pre>
 +</html>
 +\\
 +<WRAP center round tip 80%>
 +In diesem Beispiel haben wir nach nicht einmal **70 Sekunden** einen voll funktionsfähigen DNSSEC-fähigen Namserver für vier Domains mit sehr umfangreichen **20 Zonefiles** mit bis zu **800 Zeilen** in einem Zone-File, die nun wirklich niemand mehr manuell pflegen will. Die automatisierte Erstellung dieser Zonefiles aus den Daten des Inventories hat unscheinbare Vorteile. Man hat sauber formatierte Zonefiles mit aktuellen Daten und die Fehleranfälligkeit durch manuelles Editieren ist auf ein Mindestmaß begrenzt und es gibt auch keine unterschiedlichen Meinungen mehr im Admin-Team ob nun so ein Zonefile mit TABs oder SPACEes formatiert werden soll! ;)
 +</WRAP>
 +
 +==== Ergebniskontrolle ====
 +Ob die Konfigurationsdateien valide erstellt und auch von den Kea-Daemons erfolgreich geladen worden sind, kontrollieren wir zum Beispiel auf dem Zielhost mit einem Blick in die betreffenden Konfigurationsdateie, mit Prüfung der erstellten Zonefiles und mit Hilfe der **''systemctl status''**-Abfrage des betreffenden named-Daemons.
 +  * **''named-checkconf''** <code> # named-checkconf /etc/named.conf</code>
 +  * **''named-checkzone''** <code> # root@vml000110:~# named-checkzone edmz.nausch.org /var/named/zones/edmz.nausch.org.db
 +zone edmz.nausch.org/IN: loaded serial 2026011201
 +OK</code>
 +  * **''systemd''** <code> # systemctl status named.service</code>
 +  * **''dig''** <code> # dig @::1 AAAA zerberus.nausch.org
 +
 +; <<>> DiG 9.20.18 <<>> @::1 AAAA zerberus.nausch.org
 +; (1 server found)
 +;; global options: +cmd
 +;; Got answer:
 +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46659
 +;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
 +
 +;; OPT PSEUDOSECTION:
 +; EDNS: version: 0, flags:; udp: 4096
 +; COOKIE: 82f5ba9ac8a044cb010000006978ca1cbafbbb0f05e54c11 (good)
 +;; QUESTION SECTION:
 +;zerberus.nausch.org. IN AAAA
 +
 +;; ANSWER SECTION:
 +zerberus.nausch.org. 3600 IN AAAA fd00::3:10:0:0:9a37
 +
 +;; AUTHORITY SECTION:
 +nausch.org. 3600 IN NS ns1.nausch.org.
 +
 +;; ADDITIONAL SECTION:
 +ns1.nausch.org. 3600 IN AAAA fd00::3:10:0:0:110
 +ns1.nausch.org. 3600 IN A 10.0.0.110
 +
 +;; Query time: 0 msec
 +;; SERVER: ::1#53(::1) (UDP)
 +;; WHEN: Tue Jan 27 15:22:20 CET 2026
 +;; MSG SIZE  rcvd: 166
 +
 +# dig @ns1.core-networks.de AAAA zerberus.nausch.org
 +;; BADCOOKIE, retrying.
 +
 +; <<>> DiG 9.20.18 <<>> @ns1.core-networks.de AAAA zerberus.nausch.org
 +; (2 servers found)
 +;; global options: +cmd
 +;; Got answer:
 +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59294
 +;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 +;; WARNING: recursion requested but not available
 +
 +;; OPT PSEUDOSECTION:
 +; EDNS: version: 0, flags:; udp: 1232
 +; COOKIE: 40e0ff3f34e893d5010000006978cbcfd0cf510e49133631 (good)
 +;; QUESTION SECTION:
 +;zerberus.nausch.org. IN AAAA
 +
 +;; ANSWER SECTION:
 +zerberus.nausch.org. 3600 IN AAAA 2003:a:e0d:7600:5054:ff:fe3d:9a37
 +
 +;; Query time: 13 msec
 +;; SERVER: 2001:1bc0:d::fffe#53(ns1.core-networks.de) (UDP)
 +;; WHEN: Tue Jan 27 15:29:35 CET 2026
 +;; MSG SIZE  rcvd: 104
 +</code>
  
-  * **auf vml000110 selbst**: 
-    * Adressen aus der Zone **intra**  
-      * MX-record :OK: 
-      * NS-record :OK: 
-      * IPv4 forward :OK: 
-      * IPv6 forward :OK: 
-      * IPv4 reverse :OK: 
-      * IPv6 reverse :OK: 
-    * Adressen aus der Zone **idmz** 
-      * MX-record :OK: 
-      * NS-record :OK: 
-      * IPv4 forward :OK: 
-      * IPv6 forward :OK: 
-      * IPv4 reverse :OK: 
-      * IPv6 reverse :OK: 
-    * Adressen aus der Zone **edmz** 
-      * MX-record :OK: 
-      * NS-record :OK: 
-      * IPv4 forward :OK: 
-      * IPv6 forward :OK: 
-      * IPv4 reverse :OK: 
-      * IPv6 reverse :OK: 
-    * Adressen aus der Domain **nausch.org** 
-      * MX-record :OK: 
-      * NS-record :OK: 
-      * IPv4 forward :OK: 
-      * IPv6 forward :OK: 
-      * IPv4 reverse :OK: 
-      * IPv6 reverse :OK: 
-    * Adressen aus **fremden** Domains 
-      * MX-record :NOK: <code>no answer!</code> 
-      * NS-record :NOK: <code>no answer!</code> 
-      * IPv4 forward :NOK: <code>no answer!</code> 
-      * IPv6 forward :NOK: <code>no answer!</code> 
-      * IPv4 reverse :NOK: <code>no answer!</code> 
-      * IPv6 reverse :NOK: <code>no answer!</code> 
  
-  * **auf vml000210 selbst**: +====== Links ====== 
-    * Adressen aus der Zone **intra**  +  * **[[linux:ansible:detail|zurück zum Kapitel "Ansible - Erweiterte Konfigurationsbeispiele"]] <= ** 
-      * MX-record :OK: +  * **=> [[linux:unbound|weiter zum Kapitel "Lokalen DNS-Resolver mit Hilfe von Unbound unter Arch Linux einrichten und nutzen"]] <= ** 
-      * NS-record :OK: +  * **[[linux:start#ansible|Zurück zur "Ansible"-Übersicht]]** 
-      * IPv4 forward :OK: +  * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]** 
-      * IPv6 forward :OK: +  * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
-      * IPv4 reverse :OK: +
-      * IPv6 reverse :OK: +
-    * Adressen aus der Zone **idmz** +
-      * MX-record :OK: +
-      * NS-record :OK: +
-      * IPv4 forward :OK: +
-      * IPv6 forward :OK: +
-      * IPv4 reverse :OK: +
-      * IPv6 reverse :OK: +
-    * Adressen aus der Zone **edmz** +
-      * MX-record :OK: +
-      * NS-record :OK: +
-      * IPv4 forward :OK: +
-      * IPv6 forward :OK: +
-      * IPv4 reverse :OK: +
-      * IPv6 reverse :OK: +
-    * Adressen aus der Domain **nausch.org** +
-      * MX-record :OK: +
-      * NS-record :OK: +
-      * IPv4 forward :OK: +
-      * IPv6 forward :OK: +
-      * IPv4 reverse :OK: +
-      * IPv6 reverse :OK: +
-    * Adressen aus **fremden** Domains +
-      * MX-record :NOK: <code> ;; communications error to fd00::3:10:0:0:110#53: timed out</code> +
-      * NS-record :NOK: <code> ;; communications error to fd00::3:10:0:0:110#53: timed out</code> +
-      * IPv4 forward :NOK: <code> ;; communications error to fd00::3:10:0:0:110#53: timed out</code> +
-      * IPv6 forward :NOK: <code> ;; communications error to fd00::3:10:0:0:110#53: timed out</code> +
-      * IPv4 reverse :NOK: <code> ;; communications error to fd00::3:10:0:0:110#53: timed out</code> +
-      * IPv6 reverse :NOK: <code> ;; communications error to fd00::3:10:0:0:110#53: timed out</code>+
  
  • linux/bind.1768571172.txt.gz
  • Zuletzt geändert: 16.01.2026 13:46.
  • von django