Ansible KIT Nameserver-Konfiguration: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „= DNS-Server Konfiguration mit Ansible = Dieser Artikel zeigt wie man mehrere DNS-Server (bind9) automatisiert mit Ansible konfiguriert…“) |
|||
| Zeile 153: | Zeile 153: | ||
<pre> | <pre> | ||
| − | zone " | + | zone "it{{ fw_xx }}.int" { |
type master; | type master; | ||
| − | file " | + | file "it{{ fw_xx }}.int"; |
}; | }; | ||
Version vom 7. April 2026, 13:47 Uhr
DNS-Server Konfiguration mit Ansible
Dieser Artikel zeigt wie man mehrere DNS-Server (bind9) automatisiert mit Ansible konfiguriert. Wir verwenden eine Ansible-Rolle die bind9 installiert, alle Zonen-Dateien erstellt und die Konfiguration automatisch prüft.
Voraussetzung ist der Artikel Ansible Grundlagen.
Voraussetzungen
- Ansible ist auf dem Control-Node installiert (Ansible Grundlagen)
- Alle DNS-VMs sind erreichbar (SSH über die DMZ-IP)
- User
kitist auf allen VMs vorhanden und hatsudo NOPASSWD-Rechte - SSH-Schlüssel ist hinterlegt
- Die Firewall-VMs sind bereits konfiguriert (Ansible Firewall Konfiguration)
Variablen
| Variable | Bedeutung | Beispiel |
|---|---|---|
fw_xx |
Teilnehmernummer (201–213) | 212
|
fw_y |
Klassensaal (1–16) – wird beim Ausführen mitgegeben | 16
|
fw_yist bewusst nicht im Inventory
Da der Klassensaal von Tag zu Tag wechseln kann, wird er beim Ausführen des Playbooks als Extra-Variable übergeben:
ansible-playbook site.yml -e "fw_y=16"
Der Standardwert in roles/dns/defaults/main.yml ist fw_y: 1 und greift wenn man die Variable vergisst.
Projektstruktur
ansible-dns/
├── ansible.cfg
├── site.yml
├── inventory/
│ └── hosts.ini
└── roles/
└── dns/
├── defaults/
│ └── main.yml
├── tasks/
│ └── main.yml
├── handlers/
│ └── main.yml
└── templates/
├── named.conf.options.j2
├── named.conf.local.j2
├── forward.zone.j2
├── reverse.zone.j2
└── resolv.conf.j2
Inventory
Die DNS-Server liegen im DMZ-Netz (10.88.XX.21). Jeder Host bekommt seine eigene fw_xx-Variable.
[dns] ns201 ansible_host=10.88.201.21 fw_xx=201 ns202 ansible_host=10.88.202.21 fw_xx=202 ... ns213 ansible_host=10.88.213.21 fw_xx=213 [dns:vars] ansible_user=kit ansible_become=true ansible_become_method=sudo
ansible.cfg
[defaults] inventory = inventory/hosts.ini remote_user = kit host_key_checking = False [privilege_escalation] become = True become_method = sudo
Playbook
---
- name: DNS-Server konfigurieren
hosts: dns
gather_facts: false
roles:
- dns
Rolle: dns
defaults/main.yml
Standardwert für den Klassensaal – wird überschrieben wenn man -e "fw_y=16" mitgibt:
--- fw_y: 1
Tasks
Die Rolle führt folgende Schritte aus:
- Hostname setzen (
ns.it2XX.int) - bind9 installieren
- named stoppen
named.conf.optionskonfigurierennamed.conf.localkonfigurieren- Forward-Zonendatei erstellen
- Reverse-Zonendatei erstellen
- Konfiguration prüfen (
named-checkconf) - Forward-Zone prüfen (
named-checkzone) - Reverse-Zone prüfen (
named-checkzone) - named aktivieren und starten
resolv.confkonfigurieren
- Automatische Prüfung
Die Tasks führen named-checkconf und named-checkzone aus bevor named gestartet wird.
Schlägt die Prüfung fehl bricht Ansible ab – so wird verhindert dass ein fehlerhafter named gestartet wird.
Templates
named.conf.options
Der Forwarder zeigt auf den DNSGW des jeweiligen Klassensaals (192.168.Y.88).
Die allow-recursion-Regel erlaubt nur den eigenen Netzen rekursive Anfragen.
options {
directory "/var/cache/bind";
forwarders { 192.168.{{ fw_y }}.88; };
allow-query { 0.0.0.0/0; };
allow-recursion { 10.88.{{ fw_xx }}.0/24; 172.26.{{ fw_xx }}.0/24; 10.{{ fw_xx }}.1.0/24; 127.0.0.1; };
allow-transfer { 127.0.0.1; };
dnssec-validation no;
listen-on-v6 { none; };
listen-on { any; };
};
named.conf.local
Definiert die Forward- und Reverse-Zone für den jeweiligen Teilnehmer:
zone "it{{ fw_xx }}.int" {
type master;
file "it{{ fw_xx }}.int";
};
zone "{{ fw_xx }}.88.10.in-addr.arpa" {
type master;
file "{{ fw_xx }}.88.10.in-addr.arpa";
};
Forward-Zone
Enthält alle A-Records der Domäne it2XX.int:
$TTL 300
@ IN SOA ns.it2{{ fw_xx }}.int. technik.it2{{ fw_xx }}.int. (
2025062501 ; serial
14400 ; refresh
3600 ; retry
3600000 ; expire
86400 ; minimum
)
NS ns.it2{{ fw_xx }}.int.
MX 10 mail.it2{{ fw_xx }}.int.
fw IN A 10.88.{{ fw_xx }}.1
ns IN A 10.88.{{ fw_xx }}.21
sftp IN A 10.88.{{ fw_xx }}.3
proxy IN A 10.88.{{ fw_xx }}.4
ntp IN A 10.88.{{ fw_xx }}.17
dhcp IN A 172.26.{{ fw_xx }}.2
smb IN A 10.{{ fw_xx }}.1.2
ldap IN A 10.{{ fw_xx }}.1.3
Reverse-Zone
Enthält die PTR-Records für das DMZ-Netz (10.88.XX.0/24):
$TTL 1
@ IN SOA ns.it2{{ fw_xx }}.int. technik.it2{{ fw_xx }}.int. (
2025062501 ; serial
14400 ; refresh
3600 ; retry
3600000 ; expire
86400 ; minimum
)
IN NS ns.it2{{ fw_xx }}.int.
1 IN PTR fw.it2{{ fw_xx }}.int.
21 IN PTR ns.it2{{ fw_xx }}.int.
3 IN PTR sftp.it2{{ fw_xx }}.int.
4 IN PTR proxy.it2{{ fw_xx }}.int.
17 IN PTR ntp.it2{{ fw_xx }}.int.
Ausführen
- Alle Hosts (Saal 16)
ansible-playbook site.yml -e "fw_y=16"
- Nur einzelne Hosts zum Testen
ansible-playbook site.yml -e "fw_y=16" --limit ns212,ns213
- Trockenlauf
ansible-playbook site.yml -e "fw_y=16" --check
Finaler Test
Nach dem Ausführen kann man die Zonen direkt auf dem DNS-Server prüfen:
- Forward-Zone
dig @127.0.0.1 it2213.int -t axfr
- Reverse-Zone
dig @127.0.0.1 213.88.10.in-addr.arpa -t axfr
- Logs
journalctl -fu named