Unter Administratoren gibt es die halb ernst gemeinte Regel, dass es am Ende immer das DNS war. Der Grund für diese Erfahrung ist einfach: Namensauflösung und Adressvergabe sind die Voraussetzung für fast jeden anderen Dienst, fallen aber selten vollständig aus. Sie versagen teilweise, sporadisch und für einzelne Geräte – und die Meldung, die dann eintrifft, lautet nicht „DNS gestört“, sondern „die Warenwirtschaft ist langsam“ oder „ich komme nicht auf das Laufwerk“.
Beide Dienste gelten als banal und werden entsprechend behandelt: eingerichtet beim Aufbau der Domäne, danach nicht mehr angesehen. Der Baustein APP.3.6 des BSI setzt an dieser Stelle an und beschreibt die Gefährdungen, die speziell für DNS-Server bestehen, mit Blick auf Verfügbarkeit und auf die Unverfälschtheit der ausgelieferten Informationen. Beides sind Betriebseigenschaften, keine Einrichtungsschritte.
Der interne Namensraum ist eine Einbahnstraße
Die erste Entscheidung fällt beim Aufbau und lässt sich später nur mit erheblichem Aufwand zurücknehmen: Wie heißt das interne Netz? Bewährt hat sich eine Unterdomäne einer Domain, die dem Unternehmen tatsächlich gehört – etwa eine eigene Zone unterhalb der Firmendomain, die nur intern aufgelöst wird. Damit sind Überschneidungen mit öffentlichen Namen ausgeschlossen, Zertifikate lassen sich sauber ausstellen, und eine spätere Zusammenführung mit einem zugekauften Unternehmen scheitert nicht am Namen.
Zwei verbreitete Varianten sind dagegen problematisch. Die Endung „.local“ ist durch RFC 6762 für Multicast DNS belegt: Namen, die darauf enden, gelten ausdrücklich nur auf dem lokalen Netzabschnitt, und Abfragen werden nicht an einen DNS-Server, sondern an eine Multicast-Adresse geschickt. Wer eine Domäne so benennt, erzeugt auf Geräten, die Multicast DNS unterstützen, unzuverlässige Auflösung – mit Fehlerbildern, die je Betriebssystem anders aussehen. Die Registrierung der Special-Use-Namen bei der IANA führt „local“ mit genau diesem Verweis; als Alternative für den Heimbereich ist dort „home.arpa“ verzeichnet.
Die zweite Variante ist eine frei erfundene Endung, weil sie im Moment nirgends vergeben ist. Das ist eine Wette auf die Zukunft: Wird die Endung später öffentlich delegiert, konkurriert der interne Name mit einem echten. Die Umbenennung eines etablierten Verzeichnisdienstes ist anschließend ein Projekt mit Auswirkungen auf Zertifikate, Anmeldungen, Fachanwendungen und Endgeräte – deutlich teurer als die zehn Minuten, die die richtige Wahl am Anfang kostet.
Redundanz heißt zwei Server an zwei Orten
Ein einzelner DNS-Server ist ein Einzelfehlerpunkt für die gesamte IT. Zwei Server sind der Mindeststandard – allerdings nur dann wirksam, wenn sie nicht dieselbe Grundlage teilen. Zwei virtuelle Maschinen auf demselben Virtualisierungshost, in demselben Schrank, an derselben Stromschiene sind zwei Server auf dem Papier. Die Trennung sollte so weit gehen, wie die Umgebung es zulässt: anderer Host, anderer Schrank, andere Stromversorgung.
Für DHCP gilt dasselbe, mit einer Besonderheit. Zwei Server müssen sich über die vergebenen Adressen verständigen, entweder über einen Abgleich zwischen beiden oder indem der Adressbereich aufgeteilt und jedem Server ein Teil zugewiesen wird. Beides ist unkompliziert, wird aber häufig ausgelassen – mit der Folge, dass nach dem Ausfall eines Servers in einem Segment schlicht keine Adressen mehr vergeben werden. Wo Segmente getrennt sind, kommt die Weiterleitung der Anfragen hinzu: Jedes Segment braucht einen Router oder Switch, der DHCP-Anfragen an die Server weitergibt.
Ein Fehler verdient besondere Erwähnung, weil er so häufig ist: Als zweiter Namensserver wird ein öffentlicher Dienst eingetragen. Das sieht nach Ausfallsicherheit aus und ist in einer Domänenumgebung das Gegenteil. Fragt ein Gerät den öffentlichen Server, erhält es für interne Namen keine Antwort – nicht falsch, sondern gar nichts. Die Folge sind sporadische Fehler, die sich beim zweiten Versuch von selbst erledigen und deshalb monatelang niemandem zugeordnet werden. Interne Geräte gehören ausschließlich auf interne Resolver; diese wiederum leiten unbekannte Anfragen nach außen weiter.
Kurze Laufzeiten machen Änderungen steuerbar
Die Laufzeit einer DHCP-Zuweisung bestimmt, wie lange ein Gerät seine Adresse und die mitgelieferten Angaben behält – darunter Standardgateway und Namensserver. Sie ist damit der Hebel, mit dem sich eine Änderung im Netz überhaupt umsetzen lässt. Wer die Laufzeit auf mehrere Tage stellt, bekommt nach dem Austausch einer Firewall Geräte, die noch tagelang auf das alte Gateway zeigen. Die Gegenbefürchtung, kurze Laufzeiten belasteten Server und Netz, trifft in Netzen mittlerer Größe nicht zu: Eine Erneuerung ist ein kurzer Austausch von zwei Nachrichten, und die Geräte erneuern ihre Zuweisung ohnehin lange vor deren Ablauf.
Ein Beispiel als Orientierung, nicht als Norm: In Gäste- und WLAN-Bereichen mit wechselnden Geräten sind wenige Stunden angemessen, damit Adressen frei werden, wenn Besucher gehen. In Büronetzen genügt etwa ein Tag. Geräte, die immer dieselbe Adresse brauchen – Drucker, Kameras, Maschinen –, erhalten eine feste Zuordnung über den DHCP-Server statt einer im Gerät eingetragenen Adresse; so bleibt die Vergabe an einer Stelle nachvollziehbar. Vor einer geplanten Umstellung wird die Laufzeit vorübergehend abgesenkt und nach der Umstellung wieder erhöht.
Die gleiche Überlegung gilt im DNS für die Gültigkeitsdauer der Einträge. Sie bestimmt, wie lange andere Systeme eine Antwort zwischenspeichern. Wer den Umzug eines Dienstes plant, senkt die Gültigkeitsdauer der betroffenen Einträge einige Tage vorher ab, führt die Umstellung durch und setzt sie danach wieder hoch. Ohne diesen Schritt erreichen einzelne Nutzer den alten Server noch lange nach der Umstellung – und niemand kann erklären, warum es bei den meisten funktioniert.
Typische Fehlerbilder
- Ein zweiter DHCP-Server im Netz, meist ein mitgebrachter Heimrouter oder ein Router in einer Maschine: Geräte erhalten wahllos Adressen aus dem falschen Bereich, und der Fehler wandert.
- Erschöpfter Adressbereich: Im Gästesegment bekommen neue Geräte keine Adresse mehr, weil abgelaufene Zuweisungen zu lange gehalten werden.
- Karteileichen im DNS: Einträge abgeschalteter Server bleiben stehen, weil die automatische Alterung und Bereinigung nie aktiviert wurde; Anwendungen laufen dann in Zeitüberschreitungen.
- Fehlende Rückwärtsauflösung: Protokolle enthalten nur Adressen statt Namen, und manche Serverdienste antworten merklich langsamer.
- Ein Gerät mit im Betriebssystem festgeschriebener Adresse, die innerhalb des automatisch vergebenen Bereichs liegt: ein Adresskonflikt, der erst Wochen später auftritt.
- Verschlüsselte Namensauflösung im Browser: Das Programm fragt einen Dienst im Internet und umgeht den internen Server – interne Adressen sind dann nicht erreichbar und Filtermechanismen wirkungslos. Diese Funktion gehört in verwalteten Umgebungen per Richtlinie abgeschaltet.
- Abweichende Uhrzeit auf den Servern: In Domänenumgebungen führt sie zu Anmeldefehlern, die wie ein Namensproblem aussehen.
Protokollierung: die Brücke zwischen Adresse und Gerät
Nach einem Sicherheitsvorfall lautet die erste Frage regelmäßig: Welches Gerät hatte am Dienstag um 14 Uhr diese Adresse? Beantworten lässt sie sich nur mit den Aufzeichnungen des DHCP-Servers. Ohne sie bleibt eine Adresse aus einem Firewall-Protokoll eine Zahl. Ebenso wertvoll sind die Abfrageprotokolle des DNS-Servers: Ein Gerät, das wiederholt Namen von Steuerservern für Schadsoftware auflöst, fällt dort auf, bevor Daten abfließen.
Damit diese Aufzeichnungen nutzbar sind, braucht es drei Festlegungen. Erstens werden die Protokolle auf ein zentrales System übertragen, weil ein Angreifer auf dem betroffenen Server auch die lokalen Aufzeichnungen erreicht. Zweitens wird eine Aufbewahrungsdauer bestimmt, die lang genug für die Nachverfolgung und mit den datenschutzrechtlichen Vorgaben abgestimmt ist; bei Protokollen mit Personenbezug gehören Zweck, Dauer und Auswertung vorab geregelt, gegebenenfalls unter Beteiligung der Mitbestimmung. Drittens muss jemand die Protokolle ansehen – sei es über eine automatische Benachrichtigung bei auffälligen Mustern oder über eine regelmäßige Durchsicht.
Drei Fragen reichen aus, um den Stand im eigenen Haus einzuschätzen. Wie viele interne Namensserver gibt es, und laufen sie auf getrennter Grundlage? Ist ein öffentlicher Dienst bei Endgeräten als Namensserver eingetragen? Und lässt sich für einen beliebigen Tag der vergangenen Wochen sagen, welches Gerät eine bestimmte Adresse hatte? Wer alle drei Fragen beantworten kann, betreibt die beiden unauffälligsten Dienste im Netz mit der Aufmerksamkeit, die ihrer Bedeutung entspricht.
Verwandte Themen: Wer hier weiterdenkt, liest bei WLAN, Gastnetz und strukturierte Verkabelung weiter.
