Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:bind [26.01.2026 14:54. ] – [Lösung] django
+++ linux:bind [01.02.2026 17:36. ] (aktuell) – [Rolle] django
@@ Zeile 5608: / Zeile 5608: @@
          -O - | tar -xz --strip-components=1 -C ~/devel/ansible</code>
-Nach Anpassung der Daten im **[[#vorbereitung_-_server-_daten_im_inventory|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>
@@ Zeile 5614: / Zeile 5614: @@
 Bei unserem Konfigurationsbeispiel hier gehen wir von folgenden Host-Parametern aus:
   * **''zone: edmz''**
-    * **Netzwerkdevice : ''pnc027042''**
+    * **Netzwerkswitch/-device : ''pnc027010''**
   * **''zone: idmz''**
-    * **VM : ''vml000110**''
+    * **KVM HOST : ''vml000110''**
   * **''zone: intra''**
-    * **Netzwerkkomponente : ''pnc010067''**
+    * **Netzwerkswitch/-device : ''pnc010010''**
-    * **Workstation : ''pml010069''**
+    * **Workstation : ''pml010068''**
   * **''hostname: vml010110''** auf dem der ISC BIND laufen soll.
@@ Zeile 5630: / Zeile 5630: @@
 ++++
-Die beiden Beispiel-Hosts aus der Gruppe|Zone **''intra''** in diesem Inventory symbolisieren folgende unterschiedlichen Knoten.
+Der Beispiel-Hosts aus der Gruppe|Zone **''edmz''** in diesem Inventory beschreibt den Switch der EDMZ.
-  * Der Host **''pnc010007''** steht exemplarisch für einen Client im Intranet. In dessen Inventory-File **''inventories/production/host_vars/pnc010007''** sind die ihn beschreibenden Dateien enthalten.
+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.
-  * Der Host **''vml010110''** ist in diesem Beispiel unser Server, der die Verbindung zwischen der Zone **''intra''** und der Aussenwelt 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 im SOHO an.
+Wir legen uns also nun die Hostdefinitionsdatei für unseren Switch in der Zonme **''edmz''** an.
-   $ vim inventories/production/host_vars/pnc010007
-++++ inventories/production/host_vars/pnc010007 |
-{{gh> https://gitlab.nausch.org/django/example_kea/-/blob/main/inventories/production/host_vars/pnc010007  }}
+   $ 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/vml010110/kvm_vhost
+  $ vim inventories/production/host_vars/vml000110/kvm_vhost
-++++ inventories/production/host_vars/vml010110/kvm_vhost |
+++++ inventories/production/host_vars/vml000110/kvm_vhost |
-{{gh> https://gitlab.nausch.org/django/example_kea/-/blob/main/inventories/production/host_vars/vml010110/kvm_vhost  }}
+{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/inventories/production/host_vars/vml010110/kvm_vhost  }}
 ++++
-Die für die beiden **kea-Daemon** relevanten Konfigurationsparameter legen wir in der Inventrory-Datei **''inventories/production/host_vars/vml010110/kea''** ab.
+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/vml010110/kea
+   $ vim inventories/production/host_vars/vml000110/bind
-++++ inventories/production/host_vars/vml010110/kea |
+++++ 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_kea/-/blob/main/inventories/production/host_vars/vml010110/kea  }}
+{{gh> https://gitlab.nausch.org/django/example_bind/-/blob/main/inventories/production/host_vars/pnc010068 }}
 ++++
@@ Zeile 5662: / Zeile 5688: @@
 ├── hosts
 └── host_vars
-    ├── pnc010007
+    ├── pml010068
+    ├── pnc010010
+    ├── pnc027010
     └── vml010110
-        ├── kea
+        ├── bind
+        ├── bind_domain
         └── kvm_vhost
-directories, 4 files</code>
+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
+directories, 0 files
+</code>
+++++
-FIXME **''21:12 $ pikaur -Ss netaddr''** FIXME
+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 ===
@@ Zeile 5805: / Zeile 6057: @@
 </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>
+====== Links ======
+  * **[[linux:ansible:detail|zurück zum Kapitel "Ansible - Erweiterte Konfigurationsbeispiele"]] <= **
+  * **=> [[linux:unbound|weiter zum Kapitel "Lokalen DNS-Resolver mit Hilfe von Unbound unter Arch Linux einrichten und nutzen"]] <= **
+  * **[[linux:start#ansible|Zurück zur "Ansible"-Übersicht]]**
+  * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]**
+  * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**