Schlagwort-Archive: DNS

DNS over HTTPS (DoH) — Was ändert sich für den Nutzer?

Mozilla und Google haben angekündigt, DoH in ihren Webbrowsern Firefox bzw. Chrome zu aktivieren. In diesem Artikel möchte ich allgemeinverständlich erklären, was sich dadurch für Nutzer dieser Programme ändern kann bzw. wird.

Dazu beschreibe ich zuerst in vereinfachender Weise, wie das heutige DNS-System funktioniert und was an diesem System kritisiert wird. Darauf folgt eine Beschreibung von DoH und der Kritik an diesem Protokoll. Der Artikel soll dem Leser helfen, sich eine eigene Meinung zu bilden.

Dieser Artikel richtet sich in erster Linie an (Privat-)Anwender und Nutzer der genannten Programme. Er soll ein grundlegendes Verständnis auch ohne vollständige Kenntnis der Fachterminologie ermöglichen. Den versierten Leser bitte ich daher zu entschuldigen, sollten einige Ausführungen fachlich nicht ganz exakt sein.

Das Domain Name System (DNS)

Das DNS ist einer der wichtigsten Dienste in vielen Netzwerken und quasi das Rückgrat des Internets. Denn es sorgt dafür, dass zu einer Eingabe im Webbrowser wie z.B. https://www.my-it-brain.de oder www.ubuntuusers.de der Server gefunden wird, welcher die entsprechende Seite ausliefern kann. Das DNS funktioniert dabei so ähnlich wie ein Telefonbuch bzw. eine Telefonauskunft.

Wie wird das DNS von (Privat-)Anwendern genutzt?

Um zu veranschaulichen, wie das DNS in den meisten Fällen genutzt wird, stelle man sich folgendes Heimnetzwerk vor, wie es vermutlich in vielen Haushalten existiert.

typical-soho-network
Darstellung eines typischen Heimnetzwerks mit Anbindung an das Internet über einen Internet Service Provider

Endgeräte wie Laptop, Smartphone, Tablet, PC, etc. sind via LAN oder WLAN an den heimischen (W)LAN-Router angebunden. Letzterer erhält vom Internet Service Provider (ISP) eine oder mehrere IP-Adressen mitgeteilt, über welche der Router — vom Internet aus gesehen — erreichbar ist. Darüber hinaus teilt der ISP noch die IP-Adressen seiner DNS-Server mit, welche ebenfalls im (W)LAN-Router gespeichert werden.

Der (W)LAN-Router wiederum weist jedem Endgerät eine IP-Adresse zu, unter welcher dieses Gerät im Heimnetzwerk erreicht werden kann. Darüber hinaus teilt er den Endgeräten eine sogenannte Gateway-Adresse mit. Diese Adresse stellt für die verbundenen Endgeräte quasi das Tor ins Internet dar. Gleichzeitig wird diese IP-Adresse meist auch als DNS-Serveradresse auf den Endgeräten konfiguriert. Erledigt wird dies alles in der Regel über das DHCP-Protokoll, um dem Nutzer die manuelle Konfiguration der beteiligten Komponenten zu ersparen.

Damit sind dann eigentlich auch schon alle Voraussetzungen geschaffen, um mit den Endgeräten im Internet surfen zu können.

Tippt nun ein Nutzer im Webbrowser seines PCs die Adresse https://www.my-it-brain.de ein, wird auf folgendem Weg die IP-Adresse des Servers ermittelt, welcher diesen Blog ausliefert. Das folgende Bild dient der Veranschaulichung der Schritte 1-5.

dns-request-answer-png
Darstellung der zur Namensauflösung durchlaufenden Schritte
  1. PC fragt den (W)LAN-Router nach der gesuchten IP-Adresse
  2. (W)LAN-Router fragt den bzw. die DNS-Server des ISP
  3. Der DNS-Server des ISP fragt ggf. weitere DNS-Server im Internet
  4. DNS-Server des ISP kennt die gesuchte IP-Adresse und teilt sie dem (W)LAN-Router mit
  5. Der (W)LAN-Router teilt die IP-Adresse dem PC mit

Der PC ist mit Kenntnis der IP-Adresse nun in der Lage, die gewünschte Seite beim Server anzufragen und im Webbrowser darzustellen.

Oftmals verfügen die in vorstehender Abbildung dargestellten Geräte über einen Zwischenspeicher für erfolgreich ausgeführte DNS-Abfragen, den sogenannten Cache. So muss bei einer wiederholten Anfrage einer bereits erfolgreich aufgelösten IP-Adresse nicht erneut die komplette Kette durchlaufen werden. Die Anfrage kann stattdessen aus dem Cache beantwortet und somit Zeit eingespart werden. Das folgende Code-Beispiel soll dies verdeutlichen. Dabei ist es nicht wichtig, jede einzelne Zeile interpretieren zu können. Der Befehl dig my-it-brain.de versucht den Namen ‚my-it-brain.de‘ in eine IP-Adresse aufzulösen. Die mit ‚Query time‘ beginnende Zeile gibt die Verarbeitungsdauer der Anfrage an.

user@X201:~$ dig my-it-brain.de

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> my-it-brain.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55873
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;my-it-brain.de.			IN	A

;; ANSWER SECTION:
my-it-brain.de.		3600	IN	A	136.243.44.163

;; Query time: 68 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Sep 26 15:45:15 CEST 2019
;; MSG SIZE  rcvd: 59

user@X201:~$ dig my-it-brain.de

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> my-it-brain.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55400
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;my-it-brain.de.			IN	A

;; ANSWER SECTION:
my-it-brain.de.		3590	IN	A	136.243.44.163

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Sep 26 15:45:24 CEST 2019
;; MSG SIZE  rcvd: 59

user@X201:~$

Die Beantwortung der ersten DNS-Abfrage dauerte noch 68 ms. Die zweite Anfrage konnte direkt aus dem Cache meines Laptops in 0 ms beantwortet werden. Dabei ist anzumerken, dass alle Anwendungen von diesem Cache profitieren können, sofern sie alle den Cache des Betriebssystems oder ggf. auch den des nachgelagerten (W)LAN-Routers nutzen können.

Kritik

Die Kommunikation über das DNS-Protokoll ist nicht verschlüsselt. Jeder Teilnehmer in einem Netzwerk, der eine DNS-Abfrage zu sehen bekommt, kann deren vollständigen Inhalt lesen. So kann z.B. der ISP sehen, welche Seiten wie oft von seinen Kunden aufgerufen werden. Wobei über die Häufigkeit wiederholter Seitenaufrufe keine genaue Aussage getroffen werden kann, wenn im Heimnetzwerk des Nutzers DNS-Caches verwendet werden.

Der DNS-Client, welcher einen Namen in eine IP-Adresse auflösen möchte, hat keinerlei Möglichkeit zu prüfen, ob die zurückgelieferte IP-Adresse wirklich dem Inhaber der gewünschten Seite gehört. Im Prinzip kann jeder, der eine DNS-Anfrage sieht, eine Antwort senden. Das Endgerät akzeptiert in der Regel die Antwort, die es als erstes erreicht als gültig.

Dadurch bestehen vielfältige Angriffsformen, welche meist das Ziel verfolgen, DNS-Teilnehmer durch Manipulation auf falsche Webseiten zu lenken, um anschließend Passwörter, PINs, Kreditkartennummern usw. zu ergaunern. Darüber hinaus können Manipulationen auch für Zwecke der Zensur verwendet werden.

Die erwähnten Gefahren für Angriffe bzw. Zensur möchte ich mit zwei kurzen Beispielen verdeutlichen.

Beispiel 1: Phishing mit Hilfe von Cache Poisoning

cache-poisoning
Skizzierte Darstellung eines Angriffs mittels Cache Poisoning

Beim Cache Poisoning wird der DNS-Cache des (W)LAN-Routers manipuliert. In der Folge werden Aufrufe von z.B. Gmail, Amazon, eBay oder Online-Banking-Webseiten auf sogenannte Phishing-Webseiten umgeleitet. Diese sehen den echten Seiten meist zum Verwechseln ähnlich und sollen den Nutzer dazu verleiten, seine Zugangsdaten zu diesen Diensten preiszugeben.

Als Anwender gibt es nicht viel, was man tun kann, um sich vor diesen Angriffen zu schützen. Es bleibt lediglich:

  • Verfügbare Sicherheitsupdates für alle vorhandenen Geräte zeitnah zu installieren
  • Beim Besuch von Webseiten skeptisch zu prüfen, ob es Anomalien gibt, die auf Phishing-Versuche hindeuten können

Beispiel 2: Zensur durch den ISP

Eure DNS-Anfragen müssen in jedem Fall bei eurem ISP vorbei. Entweder, weil ihr die DNS-Server eures ISP verwendet, oder weil sie dessen Netz auf dem Weg zu eurem DNS-Provider passieren. In jedem Fall kann euer ISP die Pakete identifizieren und ihren Inhalt lesen. Damit ist euer ISP auch in der Lage, die Anfrage bzw. Antwort zum Zwecke der Zensur zu manipulieren.

Das Risiko der Zensur ist je nach Land und verwendetem ISP bzw. DNS-Provider unterschiedlich zu bewerten. Als Nutzer könnt ihr der Zensur evtl. entgehen, indem man VPN-Tunnel nutzt, um mit vertrauenswürdigen DNS-Providern zu kommunizieren. Dies funktioniert jedoch nur, sofern die VPN-Protokolle vom ISP nicht identifiziert und ebenfalls blockiert werden können.

DNS over HTTPS (DoH)

DNS over HTTPS (DoH) ist ein Protokoll zur Durchführung einer DNS-Auflösung über das HTTPS-Protokoll. Das Ziel ist es, die Privatsphäre und Sicherheit der Benutzer zu erhöhen, indem das Abhören und Manipulieren von DNS-Daten durch Man-in-the-Middle-Angriffe verhindert wird.[1] Neben der Verbesserung der Sicherheit sind weitere Ziele von DNS über HTTPS, die Leistung zu verbessern und DNS-basierte Zensurmaßnahmen zu verhindern. DNS over HTTPS wurde am 19. Oktober 2018 als RFC 8484 standardisiert.[2]

https://de.wikipedia.org/wiki/DNS_over_HTTPS

Was ändert sich für (Privat-)Anwender?

Bei Verwendung dieses Protokolls wird zur Auflösung von Namen in IP-Adressen nicht mehr die Infrastruktur eures Heimnetzwerks oder die eures ISP genutzt. Anwendungen wie z.B. Mozilla Firefox oder Google Chrome implementieren vorkonfigurierte DNS-Server-Adressen, welche zukünftig die Namensauflösung übernehmen. Wie dies aussehen kann, wird in folgender Skizze dargestellt.

dns-over-https
Darstellung zweier DNS-over-HTTPS-Verbindungen

Die Skizze zeigt Verbindungen zwischen verschiedenen Anwendungen und verschiedenen DNS-Diensten im Internet. Die Kommunikation erfolgt über das HTTPS-Protokoll und ist damit verschlüsselt. Die Verschlüsselung der DNS-Kommunikation soll vor Manipulation schützen. Ganz nach dem Motto: „Was man nicht sieht, kann man nicht manipulieren bzw. blockieren.“

Der Anwender selbst hat nichts weiter zu tun. Sein Internet funktioniert weiterhin, ohne etwas ändern zu müssen. Die in den obigen Beispielen beschriebenen Probleme scheinen gelöst, oder? Ja, aber …

Kritik an DoH

DoH verhindert effektiv Zensur durch den ISP. Dieser kann die in HTTPS versteckten DNS-Anfragen nicht von anderem HTTPS-Datenverkehr unterscheiden. Einzig vorstellbare Gegenmaßnahme ist die Blockade sämtlichen HTTPS-Datenverkehrs.

Cache Poisoning sollte keinen Einfluss mehr auf die Anwendungen haben, da diese die vorhandene Infrastruktur nicht mehr nutzen und die Anwendungen (hoffentlich) nur Antworten von den konfigurierten DNS-Services akzeptieren.

Tatsächlich fallen mir noch einige weitere Angriffsvektoren wie z.B. DNS-/IP-Spoofing und Man-in-the-Middle-Angriffe auf HTTPS ein, doch mögen diese durch Maßnahmen auf Anwendungsseite mitigiert worden sein. Daher gehe ich hier nicht weiter darauf ein. Sollte ich neue Erkenntnisse hierzu gewinnen, werde ich diese in einem folgenden Artikel thematisieren.

Statt dem eigenen ISP bzw. dem selbst gewählten DNS-Server zu vertrauen, liegt das Vertrauen nun bei den in den Anwendungen konfigurierten DNS-Providern. Warum ich diesen mehr Vertrauen sollte als meinem ISP, erschließt sich mir persönlich nicht.

In einer Welt, in der Google als Datenkrake verschrien ist, gebe ich diesem Unternehmen nur ungern auch noch meine DNS-Anfragen und würde diese lieber bei meinem ISP belassen. Nun lebe ich in einem Land, wo die ISPs noch nicht negativ durch Zensur aufgefallen sind. Wer hier das kleinere Übel darstellt, muss jeder für sich selbst beurteilen.

Stand heute ist mir nicht bekannt, ob die zu verwendenden DNS-Server in den Anwendungen (wie z.B. Firefox und Chrome) konfiguriert werden können oder man mit den Voreinstellungen leben muss. Möchte man die Vorgabe ändern, hat man nun definitiv mehr Arbeit als früher. Beim klassischen DNS lässt man einfach neue DNS-Server-Adressen über DHCP an seine Endgeräte verteilen und ist fertig. Bei DoH ist diese Konfiguration pro Anwendung und pro Endgerät durchzuführen. Ich fände es schon ärgerlich, wenn zukünftig jede Anwendung mit ihrem eigenen DNS-Resolver daherkommt und einzeln angepasst werden muss.

DoH geht an den im Heimnetzwerk existierenden Caches vorbei. Dies bedeutet entweder langsamere DNS-Abfragen oder erhöhten Bedarf an Arbeitsspeicher auf den Endgeräten, wenn alle Anwendungen nun ihren eigenen Cache implementieren.

Und wenn nun ein oder zwei dieser großen Dienste, auf die alle DNS-Anfragen konzentriert werden, ausfällt? Dann müssen unter Umständen eine Vielzahl von Anwendungen einzeln umkonfiguriert werden, um einen anderen DNS-Provider zu nutzen. Und das auf jedem Endgerät!

Fazit

Das bisherige DNS ist nicht perfekt. Es hat Stärken und Schwächen. Die Schwächen wurden oben bereits benannt. Zu einer der Stärken zählt, dass das DNS hierarchisch aufgebaut ist und dezentral betrieben wird. So ist es recht unwahrscheinlich, dass das DNS als Ganzes ausfallen bzw. kontrolliert werden kann. Fällt das DNS des ISP oder des gewählten DNS-Providers aus, kann man mit verhältnismäßig geringem Aufwand einen anderen DNS-Server verwenden und den Dienst weiterhin nutzen.

Mir persönlich gefällt das Konzept von DoH aus den oben genannten Gründen nicht. Ich hoffe und wünsche mir, dass sich auch in zukünftigen Versionen der verschiedenen Anwendungen DoH deaktivieren und die vorhandenen DNS-Resolver des Betriebssystems bzw. des Heimnetzwerks nutzen lassen.

Auch wenn ich selbst von DoH nicht überzeugt, geschweige denn begeistert bin, wird die Marktmacht von Mozilla und Google sicher ausreichen, um das Protokoll dauerhaft zu etablieren. Hoffentlich lassen die Anwendungshersteller uns Anwendern die Freiheit, die Anwendung nach unseren Wünschen zu konfigurieren.

Doch nun genug der Schmähkritik. Ich möchte hier nicht mit einem negativen Ausblick schließen, bietet DoH doch auch Chancen. Steigt mit der Zeit die Anzahl der verfügbaren DoH-Endpunkte, hat der Anwender in Zukunft evtl. eine ebenso große Auswahl wie heute bei den DNS-Servern. Und vielleicht unterstützen zukünftig auch die Resolver des Betriebssystems und der heimischen (W)LAN-Router DoH und können wie heute von den jeweiligen Anwendungen genutzt werden. All dies bleibt abzuwarten. Bis dahin wird das Internet für den normalen Anwender wohl auch weiter funktionieren, nachdem Firefox und Chrome DoH aktiviert haben.

Ich hoffe, ich konnte euch das DNS und DoH etwas näherbringen. So dass ihr die Eingangsfrage für euch selbst beantworten könnt. Solltet ihr Fragen haben oder über die beiden hier besprochenen Protokolle diskutieren wollen, nutzt gern die Kommentarfunktion dazu.

Weiterführende Quellen und Links

Dieser Beitrag darf gerne geteilt werden.

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.