Schlagwort-Archive: DNS

DNS-Konfiguration mit Ansible

Um neue Linux-VMs mit einer funktionierenden und zu unserer Umgebung passenden DNS-Konfiguration zu provisionieren, habe ich mir eine kleine Ansible-Rolle namens resolv.conf erstellt, welche ich im Folgenden vorstellen möchte.

Die Rolle resolv.conf

# tree roles/resolv.conf
roles/resolv.conf
├── handlers
│   └── main.yml
├── tasks
│   └── main.yml
└── templates
    └── resolv.conf.j2

Die Rolle kommt sehr minimalistisch daher und umfasst nur die zwingend erforderlichen Verzeichnisse und Dateien.

tasks/main.yml

---
- name: make sure line 'dns=none' is set in /etc/NetworkManager/NetworkManager.conf
  ini_file:
    path: /etc/NetworkManager/NetworkManager.conf
    state: present
    no_extra_spaces: yes
    section: main
    option: dns
    value: none
    owner: root
    group: root
    mode: 0644
    backup: yes
  notify:
  - reload NetworkManager

- name: deploy resolv.conf template
  template:
    src: roles/resolv.conf/templates/resolv.conf.j2
    dest: /etc/resolv.conf
    owner: root
    group: root
    mode: 0644
    backup: yes
  notify:
  - reload NetworkManager

Um die Datei /etc/resolv.conf mit Ansible verwalten zu können, habe ich zuerst dem NetworkManager abgewöhnt, diese Datei zu anzufassen. Dazu habe ich das Ansible-Modul ini_file verwendet, welche die benötigte Option dns=none in der Sektion [main] setzt.

Der zweite Task nutzt das Modul template, um aus der Datei unter roles/resolv.conf/templates/resolv.conf.j2 die Zielkonfiguration in der Datei /etc/resolv.conf auf dem Zielsystem zu erstellen. Aktuell enthält mein Template statischen Text und ich hätte auch das Modul copy nutzen können, um diese Datei auf das Zielsystem zu bringen. Ich verwende jedoch das template-Modul, um mir die Möglichkeit offen zu halten, durch Verwendung von Variablen den Inhalt dynamisch erstellen zu lassen.

Mit dem Parameter notify: wird an zwei Stellen ein Handler namens ‚reload NetworkManager‘ benachrichtigt. Auf diesen gehe ich im nächsten Abschnitt ein.

handlers/main.yml

Mit den Ansible Handlers lassen sich Aktionen auslösen, welche nur dann ausgeführt werden sollen, wenn durch einen Task Änderungen auf dem Zielsystem durchgeführt wurden. Die Handler werden erst am Ende eines Playbooks abgearbeitet und nur einmal ausgeführt, auch wenn Sie von mehreren Tasks über Änderungen benachrichtigt wurden.

# cat resolv.conf/handlers/main.yml 
---
  - name: reload NetworkManager
    service:
      name: NetworkManager
      state: reloaded

Bei dem in diesem Text beschriebenen Beispiel führt der Handler mit dem Namen ‚reload NetworkManager‘ den darunter definierten Task aus. Jedoch nur dann wenn einer der beiden Tasks (oder beide) aus tasks/main.yml zu einer Änderung auf dem Zielsystem geführt hat.

Es gilt zu beachten, dass Handler erst dann ausgeführt werden, wenn alle Tasks erfolgreich ausgeführt wurden. Dies kann in einigen Fällen die Fehlersuche etwas erschweren. Ich habe dazu ein Beispiel in Ansible: Up and Running von Rene Moser und Lorin Hochstein gefunden, welches ich hier gerne wiedergeben möchte. Stellt euch vor, euer Playbook hat folgenden Ablauf:

  1. Ihr führt ein Playbook aus
  2. Einer der Tasks verwendet notify bei Änderungen
  3. In einem folgenden Tasks tritt ein Fehler auf, welcher zum Abbruch der Verarbeitung führt
  4. Ihr behebt das Problem und führt das Playbook erneut aus

Der Task aus Schritt 2 hat seine Änderungen bereits erfolgreich durchgeführt. Bei der erneuten Ausführung des Playbooks wird sein Status daher OK und nicht CHANGED sein. Der Handler wurde jedoch nicht ausgeführt, da die Verarbeitung zuvor abgebrochen wurde. Auch bei der erneuten Ausführung des Playbooks wird der Handler nicht mehr ausgeführt, da der dazu erforderliche Task zu keiner Änderung im Zielsystem mehr führt.

Hochstein schreibt, dass Handler meist genutzt werden, um Dienste neuzustarten oder deren Konfiguration neu zu laden. Dies kann selbstverständlich auch erreicht werden, wenn man auf den Einsatz von Handlern verzichtet und einen Dienst am Ende des Playbooks explizit neustartet. Welches der bessere Weg ist, möge jeder für sich selbst entscheiden.

Fazit

Dies war eine meiner ersten Ansible-Rollen überhaupt. Ob dies der geschickteste Weg ist, die DNS-Konfiguration herzustellen, oder ob es noch elegantere Ansätze gibt, mag ich nicht abschließend beurteilen. Zumindest scheint auch diese Lösung robust zu sein und hat mich bisher nicht im Stich gelassen.

Falls ihr Fragen oder Anregungen habt, hinterlasst gern einen Kommentar. Ich freue mich stets neue Lösungswege kennen zu lernen.

Installation eines Secondary DNS Servers

Vor kurzen haben wir unsere Domaindaten wie Owner, Admin-C, Tech-C und Zone-C, für unsere Domains, aktualisieren lassen. Nun sind auch unsere neue Adresse und Telefonnummern hinterlegt.

Im nächsten Schritt stand die Installation eines Secondary DNS Server an. Der Primary DNS Server ist ein Windows 2003 Server. Wäre dieser Server gleichzeitig ein Domain Controller wär die Sache ziemlich einfach. In diesem Fall installiert man einen zweiten Server, stuft ihn zum DC hoch und fügt ihn dabei der vorhandenen Domain hinzu. Die DNS Zonen werden in diesem Fall automatisch auf den neuen DC repliziert.

Da es sich in diesem Fall jedoch nicht um einen DC handelt sieht das Vorgehen etwas anders aus. Zuerst benötigen wir einen zweiten DNS-Server. In unserem Fall habe ich mich für einen Windows Server 2008 R2 entschieden und auf diesem die DNS-Rolle hinzugefügt. Prinzipiell hätte ich auch einen Linux Server mit Bind verwenden können, doch das wollte ich mir nicht antun.

Ist der neue Server up-and-running müssen nun noch die Zonen auf diesen Server übertragen werden. Hierzu werden die folgenden Schritte ausgeführt.

  1. Man öffnet den DNS-Manager aus dem Menü Start->Verwaltung. In diesem ist bisher nur unser frisch installierter Server zu sehen.
  2. Nach einem Rechtsklick auf das Wurzelelement „DNS“ wählt man den Punkt „Mit DNS Server verbinden…“. Im sich öffnenden Dialogfenster gibt man die IP oder den FQDN des Masterservers ein und bestätigt mit „OK“. Der Masterserver ist der Server, auf dem die Zonen bereits existieren.
  3. Man öffnet die Struktur des Masterservers bis die einzelnen Forward-Lookupzonen angezeigt werden. Die folgenden Schritte müssen für jede Forward-Lookupzone ausgeführt werden, die auf dem Secondary DNS Server verwaltet werden soll.
  4. Im linken Teil des Fensters wird ein Rechtsklick auf die entsprechende Forward-Lookupzone ausgeführt und der Punkt „Eigenschaften“ aus dem Kontextmenü gewählt. Im sich öffnenden Dialogfenster wechselt man auf die Registerkarte Zonenübertragungen.
  5. Auf dieser Registerkarte setzt man den Haken wie im Screenshot zu sehen.
  6. Über die Schaltfläche Bearbeiten fügt man nun den gerade neu aufgesetzten Server hinzu. Es ist wichtig, dass der FQDN des neuen Servers korrekt aufgelöst werden kann. Durch diese Einstellung ist der neue Secondary DNS Server berechtigt Zoneninformationen vom Masterserver abrufen zu dürfen.
  7. Jetzt öffnen wir die Baumstruktur unsers neuen DNS Servers im DNS-Manager und führen einen Rechtsklick auf den Punkt „Forward-Lookupzonen“ aus. Ein Klick auf „Neue Zone…“ startet den Assisstenten zum hinzufügen neuer Zonen.
  8. Im zweiten Schritt des Assistenten wählen wir „Sekundäre Zone“ aus und klicken auf Weiter. Jetzt muss der Zonenname angegeben werden. Diesen können wir entweder direkt eingeben oder über die Schaltfläche „Durchsuchen“ , wie in einem Explorer, zur gewünschten Forward-Lookupzone navigieren.
  9. Damit die Zone korrekt aufgelöst werden kann wird im nächsten Schritt die IP des Masterservers eingeben. Dies ist der bereits existierende DNS Server, welcher die ausgewählte Zone bereits verwaltet.
  10. Am Ende wird der Assistent mit einem Klick auf „Fertig stellen“ abgeschlossen. Der neu aufgesetzte Secondary DNS Server holt sich nun die DNS Informationen dieser Zone vom Masterserver und kann DNS Anforderungen entsprechend auflösen.

Mit den oben genannten Schritten haben wir jetzt eine Forward-Lookupzone auf dem neuen Secondary DNS Server hinzugefügt. Die genannten Schritte sind so für jede Zone erneut auszuführen, die vom neuen DNS Server verwaltet werden soll. In meinem Fall waren 16 Zonen zu bearbeiten, was eine entsprechende Fleissarbeit darstellt.

Damit die DNS-Konfiguration sauber ist, ist darauf zu achten, dass der neue Server auch in jeder Zone, die er verwaltet, als Nameserver eingetragen ist. Dies sollte zum Abschluss dringend kontrolliert werden, da sich so unnötige Fehler vermeiden lassen.