DNS-Fehler finden: Auf was Sysadmins öfter mal ein Auge werfen sollten

Das Domain Name System gehört zu den stilleren Diensten im Netzwerkbetrieb — bis es einmal ausfällt. Viele Probleme, die als Anwendungsfehler beginnen, landen letztlich bei einer nicht richtig gepflegten Zonendatei. Wer Server verwaltet, kommt deshalb kaum umhin, sich mit den typischen Schwachstellen im DNS zu befassen. Der folgende Überblick nennt drei Bereiche, in denen Fehlkonfigurationen in der Praxis besonders gern vorkommen und welche Maßstäbe zur Beurteilung herangezogen werden können.

Warum kleine Fehler in der Zonendatei nicht gleich ins Gesicht springen

DNS-Fehler zeigen sich oft erst zeitverzögert. Ein Paradebeispiel ist der fehlende Rundlauf zwischen A- und PTR-Record. Laut RFC 1912, in dem seit 1996 die häufigsten DNS-Konfigurationsfehler beschrieben sind, sollte jeder ansprechbare Host sowohl eine Vorwärts- als auch eine Rückwärtsauflösung liefern. Anderenfalls verweigern manche Mailserver oder Dienste gleich die Anbindung. Besonders problematisch sind auch CNAME-Einträge, die zugleich auf andere Ressourcentypen wie z.B. MX verweisen; diese Kombination nennt die gleiche RFC sogar ausdrücklich als Ursache für ausbleibende Mailzustellung.

Zum Beispiel regelmäßige check dns decken derartige Inkonsistenzen auf, bevor sie zu supportanfragen oder mailzustellungsproblemen führen. Bei diesen Abgleichen werden Einträge vom Typ A, AAAA, MX, TXT und NS mit der tatsächlichen Konfiguration des Servers verglichen, und lassen sich sehr gut in die bestehenden Wartungsroutinen einpflegen. Ebenfalls sehr häufige Stolpersteine sind auch zu lange oder zu kurze TTL-Werte: zu hohe TTLs verzögern die Wirksamkeit einer Migration um Stunden oder Tage, während zu niedrige die Last auf den authoritativen Servern und damit die Antwortzeiten der Clients erhöhen.

Verwaiste Subdomains als Einstiegspunkt für Angreifer

Ein gerne unterschätztes Risiko in der Praxis sind sogenannte dangling DNS-Records, CNAME-Records, die noch auf einen Cloud-Dienst zeigen, der längst abgeschaltet wurde, z.B. auf einen gelöschten S3-Bucket, eine nicht mehr existierende GitHub-Pages-Seite oder einen gekündigten Azure-Dienst. Laut den MDN Web Docs kann ein Angreifer in bestimmten Fällen einen ungenutzten Dienst neu registrieren und dadurch die Kontrolle über die entsprechende Subdomain übernehmen. Mit dem Zugang zu einer vertrauenswürdigen Subdomain können Phishing-Webseiten erstellt, Sitzungscookies gestohlen oder Sicherheitsrichtlinien für Inhalte umgangen werden.

Um sich wirkungsvoll zu schützen, ist die Reihenfolge der durchgeführten Schritte entscheidend. Beim Einrichten eines Dienstes sollte zuerst der Hostname auf der gewünschten Plattform reserviert werden, gefolgt von der Einrichtung des DNS-Eintrags. Bei der Deaktivierung sollte die Reihenfolge umgekehrt werden: Zuerst den DNS-Eintrag entfernen und dann die Ressource ausschalten. Für diejenigen, die mehrere Dutzend oder sogar Hunderte von Subdomains verwalten, ist es unerlässlich, regelmäßig eine dokumentierte Überprüfung der Zonendatei durchzuführen.

DNSSEC und die Frage der Vertrauenswürdigkeit von Antworten

Ein weiterer Aspekt ist DNSSEC und die damit verbundene Vertrauenswürdigkeit von Antworten. Das traditionelle DNS überprüft nicht, ob eine Antwort tatsächlich von dem autoritativen Server stammt. Die Schwäche wurde 2008 durch Dan Kaminsky und dessen Cache-Poisoning-Methode bekannt und löste eine umfassende Diskussion über die Verbesserung der Sicherheit des Protokolls aus. DNSSEC schließt diese Sicherheitslücke, indem es DNS-Antworten digital signiert und dadurch eine Vertrauenskette vom Root-Server bis zur spezifischen Domain etabliert. Laut der BSI-Leitlinie zur Implementierung von DNSSEC ist es wichtig, Key-Signing-Keys und Zone-Signing-Keys getrennt zu verwalten und regelmäßig zu erneuern. Auf der Seite der Resolver ist es ebenfalls von Bedeutung, die DNSSEC-Validierung aktiv im Blick zu behalten, denn eine fehlerhafte Schlüsseländerung könnte dazu führen, dass eine legitime Domain als nicht vertrauenswürdig angesehen wird und damit für Benutzer unzugänglich wird.

Strukturierte Prüfverfahren anstelle von Einzelmaßnahmen

Das BSI-Grundschutzmodul APP.3.6 für DNS-Server fordert unter anderem eine kontinuierliche Überwachung der Server, den Besitz eines dokumentierten Notfallplans sowie eine regelmäßige Analyse der Logdateien auf sicherheitsrelevante Vorfälle. Im Alltag bedeutet dies, dass Zonendateien versioniert und Änderungen klar dokumentiert werden sollten. Die TTL-Werte müssen überprüft werden, insbesondere vor umfangreichen Migrationen. Zudem sollten nicht mehr aktiv genutzte Subdomains aus der Zone entfernt und nicht nur deaktiviert werden.

Wer diese Prüfroutinen in regelmäßigen Abständen, beispielsweise vierteljährlich oder nach größeren Änderungen in der Infrastruktur, festlegt, verringert das Risiko stiller Fehlkonfigurationen erheblich. Die Kombination aus technischer Prüfung und dokumentierten Prozessen unterscheidet letztendlich eine dynamische Zonendatei von einer, die zu einem Sicherheitsrisiko werden kann.