DNS Grundlagen

Es ist immer wieder erstaunlich, wie viel Firmen keine optimale DNS-Auflösung nutzen, obwohl es Microsoft doch sehr einfach macht. Wenn ihre Firma aber größer ist oder die ersten Zukäufe anstehen, dann grübelt doch wieder die Administratoren, wie das genau war mit Primär, Sekundär, Forwarder, Delegation etc. Daher möchte ich dies hier noch mal kurz aufgreifen. DNS-Fehler führen zu anderen Problemen, bei denen die Fehlermeldung sie in die Irre leiten kann und viel Zeit kosten. DNS muss zuverlässig sein.

Namensraum

Niemand gibt eine IP-Adresse im Browser ein sondern einen Namen und mit TLS-Verschlüsselung (HTTPS etc.) ist der Name wichtig, um das korrekte Ziel zu verifizieren. Aber auch die Rückwärtsauflösung einer IP-Adresse zu einem Namen ist nicht nur Kür sondern für die Fehlersuche sehr hilfreich. Mit IPv6 werden Sie immer nur Namen verwenden. DNS löst aber nicht nur Rechner auf IP-Adressen auf, sondern auch Mailserver (MX-Record) und viele andere Funktionen. Stellen Sie sich DNS wie ein weltweites Telefonbuch vor, um aus einem Namen eine Adresse zu machen. Und wir beim Telefonbuch gibt es nicht das eine große Nachschalgewerk, sondern jedes "Ortsnetz" hat sein eigenes Telefonbuch, welches durch den Provider gepflegt wird. Wer die Rufnummer aus einem anderen Ort benötigt musste früher dann die Auskunft bemühen, die viele Telefonbücher hatte aber bei einer Suche im Ausland sie dann doch an die Auskunft im anderen Land verwiesen hat. Klingt einfach und DNS ist sehr ähnlich aufgebaut. Der ganze Namensraum ist ein kleine Partitionen aufgeteilt, die aber als "Zone" bezeichnet werden.

Für jede Zone gibt es mindestens einen autoritativen DNS-Server. In der Regel natürlich mehrere, die sich irgendwie abgleichen und in einer Zone können durchaus mehrere "Domains"  enthalten sein. Da komme ich später noch drauf. Jedes Rechteck in diesem Bild ist eine Zone, d.h. auch "." ist eine Zone, die alle Root-Server betreiben und ".de" ist eine Zone, die vom DENIC gehostet wird. Die "msxfaq.de"-Zonen wird von meinem Provider gehostet.

  • Primäre Zone
    Im klassischen Modell gibt es immer genau einen DNS-Server der für eine Zone der Master ist. Dort erfolgen alle Änderungen durch den DNS-Administrator.
  • Sekundäre Zone
    Um eine Verfügbarkeit zu erreichen, wird eine Zone natürlich auf mehreren DNS-Servern vorgehalten. Dazu wird eine Zone auf den weiteren Servern als "Sekundär" eingetragen. Die Konfiguration enthält dabei die Information, von welchem Server, meist der primäre Server, die Daten geladen werden sollen. Zur Sicherheit können und sollten sie auf dem primären Server hinterlegen, welche anderen DNS-Server eine sekundäre Version bekommen sollen
  • Autoritative Antwort
    Jeder DNS-Server, der eine primäre oder sekundäre Zone hat, gilt als "autoritativ", d.h. die Daten sind zuverlässig. Es gibt auch nicht autoritative Antworten, z.B. wenn Sie einen anderen DNS-Server fragen, der die Daten sich erst besorgt oder aus seinem Cache beantwortet. Alle autoritativen Server sollten als NS-Eintrag in einer Zone enthalten sind.
  • DNS-Replikation
    Die sekundären Server fragen regelmäßig den primären Server nach der aktuellen Versionsnummer, die bei jeder Änderung in der DNS-Zone natürlich erhöht werden muss. Meist wird das Datum in umgekehrter Reihenfolge geschrieben. Anfang haben die sekundären DNS-Server dann immer die komplette Zone übertragen. neuere Implementierungen erlauben eine differenzielle Übertragung oder sogar Push-Benachrichtigungen.
    All diese Daten stehen in einem "SOA-Record" und eine Zone sieht z.B. wie folgt aus:
@   IN   SOA   dns1.msxfaq.de dnsadmin\.msxfaq.de (
      2023010305      ; serial  Laufende Seriennummer, die bei jeder Aenderung inkrementiert wird
      300             ; refresh Alle 300 Sekunden = 5 Min sollen die sekundaeren auf Aenderugen pruefen
      60              ; retry   Gelingt dies nicht, sollen sie dann alle Minute es wieder versuchen
      864000          ; expire  Wenn 10 Tage kein Check/Update erfolgt, geben die sekundaeren keine Information mehr 
      120             ; negative Caching, fuer nicht auflösbare Eintraege
)
@     IN   NS  dns1.msxfaq.de
@     IN   NS  dns2.msxfaq.de
dns1  IN   A   192.168.1.11
dns2  IN   A   192.168.1.12

Der SOA (State of Authority) nennt den primären DNS-Server, die Mailadresse des Verwalters ohne "@". Die weiteren Zahlen steuern die sekundären Server. Das @ ist als Platzhalter für die Domain reserviert.

Normalerweise gibt es nur genau eine Version einer Zone. Wer allerdings im Internet als auch im LAN den gleichen Namen nutzt, wird mittels Split-DNS dann doch zwei gleichnamige Zonen aber unterschiedlichen Inhalten betreiben.

Besonderheit Windows AD

Bei den meisten Unix-basierten DNS-Servern liegen die Informationen einfach in einer Datei pro Zone vor. Mit Windows 2000 kann der Microsoft DNS-Server die Zonen auch im Active Directory hinterlegen. Das hat durchaus den Vorteil, dass dann das AD die Inhalte als "Multi-Master-Replikation" verteilen kann und Sie nicht lange mit Primary/Secondary-Konfigurationen rumhantieren müssen. Auch bei der Sicherheit von dynamischen Updates ist die Konfiguration sehr einfach.

Wenn Sie im Active Directory eine Domain als Teil eines neuen oder bestehenden Forests anlegen, dann bietet ihnen DCPROMO auch an, gleich die DNS-Konfiguration vorzunehmen und den Domain Controller auch gleich zum DNS-Server zu machen. Das ist für die meisten Fällen eine gute Idee, denn DNS gehört ebenso wie NTP (Zeitdienste) und natürlich die Verzeichnisdienste zur Infrastruktur und müssen einfach funktionieren. Seit Windows 2003 werden Sie danach feststellen, dass der DNS-Server aber mindestens zwei Zonen hat:

  • <domain>
    Diese Zone ist ihre primäre Zone zur Ablage der Servernamen etc.
  • _msdsc.<domain>
    Diese Subdomain war mit Windows 2000 noch ein "Unterordner" in der <domain>-Zone aber ist mittlerweile in eine eigene Zone verlagert worden

Diese Trennung erlaubt es ihnen, einfach die <domain> auf einem anderen DNS-Server zu hosten aber die für das Active Directory essentiellen Einträge in einer eigenen Zonen-Datei zu belassen und z.B. auch die sicheren Updates zu nutzen.

Reverse Zonen

Bei den meisten Firmen sind die "Reverse-Zonen" eher schlecht gepflegt. Das sollten Sie aber ändern und es ist auch nicht wirklich schwer, damit sie nicht nur aus eine Namen eine IP-Adresse machen können sondern auch umgekehrt zu einer IP-Adresse einen Namen auflösen können. Das machen DNS-Server nämlich nicht alleine anhand der Forward-Lookup Zonen. Schließlich kann es ja sein, dass Sie zwar für eine Domain zuständig sind aber Verantwortung für die IP-Adressen bei einem anderen DNS-Server liefen.

In einer flachen Umgebung mit einem AD-Forest und einer Domain ist es wohl am einfachsten, auch für jedes Subnetz eine Reverse-Zone anzulegen. Machen Sie das möglichst früh, damit die MMC bei der Anlage neuer manueller DNS-Einträge auch die Reverse-Einträge addieren kann.

Achten Sie aber darauf, dass eine IP-Adresse nur einmal eingetragen werden kann. Ich nutze daher immer den "echten Hostname", auch wenn es weitere sekundäre Namen geben kann.

Verkettung der Server

Sie wissen nun, dass es ganz viele DNS-Server gibt, die aber immer nur eine Teilnehmer des gesamten DNS-Namensraums kennen. Daher müssen Sie die verschiedenen Dienste entsprechend miteinander verketten, damit der Client letztlich alle Namen irgendwie erreichen kann.

  • Client zum Server
    Ein Client bekommt meist per DHCP und seltener statische einen DNS-Dienst zugewiesen. In Firmen ist die meist ein DNS-Server, der schon die lokalen Informationen liefern kann. Ein DNS-Server muss nicht zwingend auch Zone halten. Dann ist es einfach nur ein DNS-Forwarder oder Proxy. Im Homeoffice übernimmt meist der DSL-Router die Rolle, DNS-Anfragen der Clients an einen Upstream-Server weiter zu reichen.

Wichtig: Wenn in einem Windows Client mehrere Client konfiguriert sind, dann fragt zumindest ein Windows Client immer zuerst den ersten Server und schwenkt auf den zweiten Server nur, wenn der erste Server nicht reagiert. Es findet keine Lastverteilung seitens des Client statt und auch eine Zweitanfrage, wenn der erste Server ein "nicht gefunden" liefert. Alle Server müssen daher immer alle die gleiche Information liefern können.
Das ist auch der Grund, warum ein DHCP-Server bei der Antwort die Reihenfolge der DNS-Server verändern sollte.

Wenn ein DNS-Server die angefragten Namen nicht selbst beantworten kann, dann hat er mehrere Optionen mit der Anfrage umzugehen.

  • Conditional Forwarder
    Dieser Weg wird gerne genutzt, wenn ein anderer interner DNS-Server, z.B. einer verbundene Firma die Informationen zu der angefragten Zone hat, aber sie keine Kopie dieser Zone als sekundäre Zone einrichten dürften. Der DNS-Server fragt dann gezielt den DNS-Server und bekommt auch nur die Antwort aber keine weiteren Informationen aus der Zone.
  • Forwarder
    Wenn Sie eine hierarchische Struktur nutzen, dann kann der DNS-Server rekursiv die Anfrage an seinen übergeordneten DNS-Server weiter reichen, der die Antwort beschaffen muss. Das ist eine gängig Konfiguration, wenn z.B. die Firewall oder der Provider einen DNS-Service für externe Namen bereitstellt, so dass der interne DNS-Server, der oft zugleich auch Domaincontroller ist, nicht direkt ins Internet kommuniziert.
  • Root-Server
    Ohne konfigurierten Forwarder fragt der DNS-Server in der Regel die "Root-Server". Dazu muss der DNS-Server natürlich diese Server erreichen können. Die Root-Server werden meist nicht die Antwort selbst geben. Deren Aufgabe ist nur ein "Verweis" zum richtigen Server für de Zone. Wenn Sie also einen Root-Server nach "msxfaq.de" fragen, dann wir der Server daraus mit einem Verweis aus die DNS-Server der ".de"-Zone antworten. Der DNS-Server fragt dann diese DNS-Server die aber ebenfalls mit einem Verweis auf den DNS-Server der "msxfaq.de"-Zone beim Provider antworten.
    Letztlich braucht ihr DNS-Server also in dem Fall drei Anfragen, bis er das Ergebnis an den Client zurückliefern kann.
  • Refer
    Bei der Kommunikation zwischen Client und Server ist es eher ungewöhnlich, dass der DNS-Server die Anfrage Client selbst mit einem Verweis auf einen besseren DNS-Server antwortet. Aber auch das ist möglich, wenn Sie in ihrem DNS-Server z.B. eine Stub-Zone anlegen, um den Client zu verweisen.

ich rate aber davon ab, einen Client per REFER zu einem anderen DNS-Server zu leiten, den er vielleicht nicht erreicht. Fehler sind hier sehr schwer zu analysieren. Ihr DNS-Server sollte die zentrale Auskunftsstelle für Namen sein.

  • "Nicht gefunden"-Antwort
    Wenn der Server keine Antwort auf die gestellte Anfrage finden kann, dann liefert er dem Client eine "NotFound"-Meldung zurück.

Dynamische Updates

Jede Windows Client versucht seinen Namen auch dynamische im DNS zu registrieren, nachdem er per DHCP einen DNS-Server bekommen hat. Das funktioniert natürlich nur, wenn die entsprechenden Forward-Lookup-Zone bzw. Reverse-Lookup-Zone auch für dynamische Updates zugelassen ist:

Ich rate davon ab, diese Einstellung auf "Nonsecure and secure" zu stellen.

Bei unsicheren Updates könnte jeder Client einen beliebigen Namen registrieren. Vor allem sind die so angelegten Objekte nicht durch ACLs gegen Veränderungen geschützt während bei sicheren Updates natürlich der Computer in der ACL eingetragen wird.

Denken Sie daran aber, wenn Sie später einmal einen neuen Computer mit dem gleichen Namen in die Domain aufnehmen. Sie sollten vorher die Einträge des alten Computers löschen alte Konten, die sich nicht mehr aktualisieren, mit der Funktion "Scavening" (Siehe DNS im Netzwerk) bereinigen.

Caching

Da sich die IP-Adresse zu einem Namen meist nicht dauern ändert, macht es keinen Sinn jede Anfrage immer komplett aufzulösen. Daher gibt es mehrere Cache-Instanzen bei DNS. Die ersten Stelle ist der DNS-Client, der einen einmal aufgelösten Namen aber auch nicht aufgelöste Namen in einem lokalen Cache vorhält. Den Cache können Sie per Kommandozeile "ipconfig /displaydns" und noch besser per PowerShell "Get-DNSClientCache" anzeigen:

Wichtiger ist aber noch der Cache des DNS-Servers, der ja von vielen Clients gefragt wird. Wenn er so das erste Mal eine Auflösung erfolgreich oder erfolglos durchgeführt hat, merkt sich der DNS-Server die Antwort für nachfolgende Fragen. Allerdings gibt der Zonen-Inhaber vor, wie lange die Werte maximal im Cache gehalten werden dürfen. Über den "Time to Live (TTL)"-Wert am Eintrag können sie erkennen, wie lange der Eintrag noch gültig ist. Jede Sekunden wird der Wert um 1 erniedrigt. In den Anfangszeiten des Internets mit schwachen und teils instabilen Leitungen waren Stunden oder gar Tage durchaus nicht ungewöhnlich. Heute sind es eher Minuten und in einigen Fällen sogar Sekunden oder 0. So können Änderungen z.B. bei einem RZ-Ausfall für einen Failover sehr schnell publiziert werden. Allerdings führt dies auch zu häufigeren DNS-Anfragen und ein empfindlicheres Verhalten bei Störungen.

Mittels einer normalen DNS-Anfrage können Sie den DNS-Server befragen.

Eine lokale Anzeige mit "Get-DNSClientCache" liefert aber meist niedrigere Werte, da die Anfrage schon länger her sein kann. Wenn Sie mit "PING" o.ä. eine Namensauflösung machen, dann bekommen Sie die Antwort aus dem Cache. NSLOOKUP oder Resolve-DNSName fragt direkt den DNS-Server.

Überwachen

Da die Funktion der DNS-Dienste im Netzwerk essentiell ist, sollten Sie nicht nur im Fehlerfall mit NSLOOKUP und "Resolve-DNSName" umgehen können, sondern die Funktion überwachen. Mehrere Ansätze sind hier denkbar.

  • Läuft der Dienst
    Das ist sicher der einfachste und direkte lokale Test, den schon der Servermanger macht. Der "Windows DNS-Server" steht in der Regel auf "automatisch" und sollte auch gestartet sein
  • Anzahl der DNS Anfragen
    Ob der Server genutzt wird, können Sie über Performance Counter ermitteln. Über den Tag und die Woche hinweg sollten Sie im Wesentlichen die gleichen Abrufwerte sehen können. Viel höhere Werte könnten auf eine Fehlkonfiguration oder Angriffe hindeuten. Deutlich niedrigere Weg könnten zwar ein Feiertag sein aber genauso ein Netzwerkproblem aufzeigen, z.B. dass der DHCP-Server die falschen Server ausliefert oder der Server nicht mehr erreichbar ist.
  • Erreichbarkeit über 53/UDP und 53/TCP
    Fast alle Überwachungstools können synthetische DNS-Anfragen anstellen. Damit lässt sich auch von anderen Orten aus die Erreichbarkeit und Reaktion des DNS-Servers prüfen
  • Korrekte Werte
    Aufwändiger aber durchaus interessant ist die Analyse der Antworten. Eine Überwachung der Antworten auf Sinnhaftigkeit hilft primär dabei, fehlende Einträge frühzeitig zu erkennen.

Was passiert wann?

Nehmen wir uns nun einen Clients, der statisch oder per DHCP einen DNS-Server zugewiesen bekommen hat und eine Anfrage stellt. Abhängig von der Konfiguration des DNS-Servers passiert dann das folgendes:

DNS-Konfiguration Ergebnis

Server hat primäre Zone

Der DNS-Server beantwortet die Anfrage aus seiner lokalen Datenbank. Wenn es den Eintrag nicht gibt, dann bekommt der Client ein "Nicht gefunden" zurück. Der Client fragt dann nicht mehr weiter

Server hat sekundäre Zone

Der DNS-Server beantwortet die Anfrage aus seiner lokalen Datenbank. Wenn es den Eintrag nicht gibt, dann bekommt der Client ein "Nicht gefunden" zurück. Der Client fragt dann nicht mehr weiter

Server AD-Integrierte Zone

Der DNS-Server beantwortet die Anfrage aus seiner lokalen Datenbank. Wenn es den Eintrag nicht gibt, dann bekommt der Client ein "Nicht gefunden" zurück. Der Client fragt dann nicht mehr weiter

Server hat Stub-Zone

Der DNS-Server beantwortet die Anfrage aus seiner lokalen Datenbank mit einem REFER, d.h. der Client wird zu den im NS-Record aufgeführten DNS-Servern geleitet und fragt dort weiter. Die Auswertung beginnt wieder oben

Server hat selectiven Forwarder

Der DNS-Server fragt nacheinander die im selektiven Forwarder spezifizieren Upstream Server. Ohne Antwort liefert er dem Client auch ein "NotFound". Ansonsten gibt er die erhaltene Antwort weiter. Der Client fragt nicht mehr weiter

Server hat generischen Forwarder

Der DNS-Server fragt nacheinander die im selektiven Forwarder spezifizieren Upstream Server. Ohne Antwort liefert er dem Client auch ein "NotFound". Ansonsten gibt er die erhaltene Antwort weiter. Der Client fragt nicht mehr weiter

Server hat nur Rootserver

Der DNS-Server fragt einen Root-Server und läuft die Rekursion durch, bis er eine Antowrt für den Client hat. Der Client selbst fragt nicht weiter

Weitere Links